On Tue, 27 Jan 2004, Bruce Bertrand wrote: > Till Kamppeter wrote: > > > I recommend that you post this on the SANE mailing list > > (http://www.sane-project.org/), as this is a scanning problem. I am > > CCing this posting to there. > > > > AFAIK noone has written a driver for scanner buttons yet (also not for > > other scanner models). The scanner probably sends a certain signal > > through the USB which is caught by a background process under Windows. > > This process then starts a program to do the scan. The best way to > > write a similar program under Linux is to use a USB sniffer to analyze > > how the signal looks like and then write a daemon which listens for > > such signals. > > > > Till > > If this is the case, then it would only take one sniffer for all > scanners that operate in this manner. Sort of like those universal > "learning" remotes, where you hold up an existing remote to the learning > remote, hit a "listen" button and then press a button on the old one, > assigning whatever signal it receives to some function on the learning > remote. > Bruce
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 > > -- "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
