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

[Christopher Marshall]

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

Is there a problem with restarting it from a script?  That seems a natural way to me to separate
mechanism from policy and I can imagine a lot of nice uses of what I described.

I had assumed that when you pushed a button on a usb scanner, it send a message over the usb that
the backend, if it was listening, would get.  The way you describe it, the scanner sets a flag
internally, meaning something like "button 1 pushed", and the flag stays in that state until the
backend asks for its button status, then tells it to reset the status back to "button 1 unpushed".
 Is that correct?

Assuming I've got it, then I think what you described is the way to go.  Have the front-end
disconnect and exit, printing out a message as to which button was pressed.  The script could then
invoke scanimage again to scan an image and print the result (if the script author wants to
interpret the pressed button that way).

You seem to be worried about what would happen if the user pressed a button twice, and the second
button press was missed because the controlling script had exited the first front-end invocation
and began another to scan.  I take it the second button press would be either be dropped, or you
wouldn't be able to process it until after the first scan finished, which would mean you couldn't
use one of the buttons as a "cancel" button to cancel the scan in progress.

If not being able to implement a cancel button bothers you, then how about this?  Have another
front-end flag that lets you name a file you want button events written to that occur during a
scan.  Then you could implement the cancel button by specifying a fifo for the file argument, and
having a background process read lines from the file, interpret them, and kill the scan in
progress in the event of a cancel button push.  That's very straight forward in bash.

Even without the ability to implement a cancel button, I would love to be able to map scanner
buttons to mean things like "scan low res, gray, and write to a spool directory", "scan high res,
color, to a spool directory" and "print the next scan".  That's assuming I have 3 buttons to work
with, of course.  So if I want to do a low res scan and have it printed, I hit button 3, wait a
second, then hit button 1.  If I didn't want it printed, I'd just his button 1 or 2.

Hmmm.  Would it be possible to push-and-hold button 1, then push-and-release button2, and then
release button 1, and have the backend tell the difference from push-and-release 1 followed by
push-and-release 2?

What exactly generates an event (usb message sent device-to-host) in the case of button presses
and releases?  Does anyone know?

Chris Marshall


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