[sane-devel] Re: How to link the Scan Button of CX3100 to a linux application?

[m. allan noah]

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 ...
> else
>    echo "unrecognized button"
>    exit 1
> fi
> 
> 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.

allan

> 
> Chris Marshall
> 
> 
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free web site building tool. Try it!
> http://webhosting.yahoo.com/ps/sb/
> 
> 

-- 
"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