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