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
