[sane-devel] Re: How to link the Scan Button of CX3100 to a
m. allan noah
Tue, 27 Jan 2004 16:01:48 -0500 (EST)
On Tue, 27 Jan 2004, Christopher Marshall wrote:
> > not so simple as that. for machines with adf, you will usually have a
> > couple other sensors like paper thickness, input or output hopper
> > empty/full, cover open, lamp warm, etc. if the scanner sends all those as
> > a bitmask in one packet, then the user doing a button-press might show up
> > as a dozen different codes, based on those other flags. your 'generic'
> > button monitor would have to know a whole lot more about each individual
> > model than you would want (esp when things like which usb endpoint to use
> > and bulk v/s interrupt are taken into account)
> > all-in-all this sort of thing (reading the raw output from the scanner)
> > belongs in the backend, with suitable abstraction that a frontend could
> > use. finding that abstraction is more problematic...
> > allan
> How about adding a front-end switch that instead of requesting a scan, requests the backend to sit
> and listen for button events and write them out to stdout? The format of the message written
> could vary by backend.
> For example, the command
> scanimage -d plustek:libusb:001:004 -report-button
> would wait for the next button press. Pressing a button would cause the command to exit and write
> a text description of the button pressed to stdout.
> This would allow the user to write bash scripts to respond to the button presses. This style of
> interaction is close to how xmessage works when invoked with -print.
> button=$(scanimage -d plustek:libusb:001:004 -report-buttons)
> if [ "$button" == "copy" ] ; then
> # scan and print
> scanimage -d plustek:libusb:001:004 > image.pnm
> pnmtops iamge.pnm > image.ps
> lpr print.ps
> elif ...
> echo "unrecognized button"
> exit 1
> This scheme might not solve all problems but it would be a big step up from no support at all.
you could have a flag to a front-end that told it to load the backend, but
instead of scan, constantly check the option descriptor for a button's
status. the front-end could print this, or even take a series of command
line switches that tell it what to do in case of a particular event. but
in all cases, this front-end would have to disconnect from the scanner, so
that the second front-end could load the backend and connect. but, it
would have to still run, so that it could re-connect and continue
monitoring. unless, you wanted to re-start it from your script.
but you definately dont want backends printing.
> Chris Marshall
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free web site building tool. Try it!
"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