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

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

perhaps it would be ok. cant see all the implications at this second...

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

to be technically accurate, all usb communications start at the host. that 
said, it is possible if the device supports it, to sometimes setup an 
interrupt pipe between the host and the device to 'automatically' request 
data from the device at certain time intervals. some scanners work this 
way. many do not.

 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?

yes, it seems that many more scanners, especially ones that use an 
existing parallel or scsi model with usb grafted onto them, just store a 
bitmask of sensor statuses (stati?) until a timer runs out (3 secs on 
fujitsu) or until the backend requests the current status.

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

that would work for trivial cases, and only for certain events.

for more complex situations: ie: the 
stock fujitsu windows software will read the status of the hopper paper 
sensor, and begin scanning the papers without any button press. if you 
want to emulate this, then your 'scanmonitor' frontend would have to 
report that event and exit. but, if your wrapper script does not care 
about paper insertion, then it will never get the button press, cause 
scanmonitor has already exited. so your wrapper would have to handle this 
by restarting the scanmonitor on any unknown events. which is fine, except 
that re-loading the backend again can be time consuming and can clear the 
status of any buttons, meaning that the button pressed right after the 
paper was inserted, gets lost.

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

among other things, this is a concern, yes.

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

ok, lets talk about that idea. any backend that has button support could 
open a fifo and print 'events' to that as they happen. so all you need is 
either a flag to the frontend to constantly call a function in the backend 
that will do this, or a flag to the backend that causes it to while(1) in 
one of the early sane_* functions.

now you still need some way for your bash wrapper to signal the 
frontend/backend to stop watching the device so that you can fire-up a 
specific program. that would be alot easier if bash wrapper was not 
involved, and instead your monitor front-end was smart enough to read a 
config file of programs to run, and it could perhaps 'control' the backend 
a bit better.

and, even better than that, the frontend could perhaps handle some of the 
events internally, so it would not have to disconnect the backend, just to 
have another front-end re-load it.

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

that last one is tough to do via this whole bash script thing, unless you 
have the backend buffer the button presses for a couple seconds to see if 
anymore happen (like 3 button mouse emulation). much easier to get a 
scanner with more inputs. fujitsu has a user-setable seven-element led 
char and two scan buttons, making for 20 possible combinations.

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

depends entirely on the scanner.

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

depends entirely on the scanner, hell even on different firmware revsion 
of the same scanner it can change. hence why this needs to be handled in 
the backend.

> 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