[sane-devel] Buttons, SANE2, scanbuttond, and other such rambling

m. allan noah anoah at pfeiffer.edu
Fri Feb 17 14:08:00 UTC 2006

there is another option. modify the fujitsu backend to act like avision or 
whatever other backend the button daemon supports. i have not looked at 
that closely enough to say if it is possible. research from you in that 
area would be welcome.

at this point- i am about half-way thru a major rewrite of the fujitsu 
backend, but the option handling code will stay the same. so you should be 
able to play with that.


On Fri, 17 Feb 2006, Charles Duffy wrote:

> While waiting for the USB issue impacting Fujitsu fi-4120C2s to be resolved, I'm
> looking into the steps necessary to run a (scripted) scan of whatever documents
> may be in the ADF when the "scan" button on the front panel is pressed.
> I've noticed the "startbutton" property exposed by the Fujitsu scanner -- but
> also that it's not available from any other driver. I've also found the
> availability of scanbuttond (which *doesn't* presently support fujitsu
> scanners), and the plans to eventually expose button state as a bitfield within
> SANE2.
> Regarding SANE2 -- is there any plan to allow a driver to expose a list of names
> (ideally taken from standardized suggestions where possible) which map to
> members of the button-state bitfield? This would allow the bitfield interface
> (which is a good one) while also allowing buttons to be named by the backend
> (which from what I've read appears to be a popular request).
> Now, for the immediate case -- would 'yall suggest writing a SANE frontend that
> polls the startbutton property and exits and launches scanadf when the button is
> pressed, adding an option to scanadf to wait for startbutton to be true before
> starting a scan, or extending startbuttond to know how to talk to Fujitsu's
> scanners? Any of these seems to me to be a legitimate option, although the
> scanadf option and SANE frontend would be Fujitsu-specific (as no other frontend
> exposes that option), making it less likely for the scanadf patch to work its
> way upstream.
> (I've written a simple libusb-based driver before, so I shouldn't be
> *completely* lost working on scanbuttond -- but it seems like such a shame to go
> write a completely separate reimplementation of the button-querying code when
> the SANE driver already has such support).
> Thoughts?

"so don't tell us it can't be done, putting down what you don't know.
money isn't our god, integrity will free our souls" - Max Cavalera

More information about the sane-devel mailing list