Am Mittwoch 19 November 2008 schrieb m. allan noah: > On Wed, Nov 19, 2008 at 12:52 PM, Wilhelm Meier <wilhelm.meier at fh-kl.de> wrote: > > Am Mittwoch 19 November 2008 schrieb m. allan noah: > >> On Wed, Nov 19, 2008 at 10:15 AM, Wilhelm Meier > > > > <wilhelm.meier at fh-kl.de> wrote: > >> > Hi, > >> > > >> > does anybody know if the scanbuttond project ist still active? > >> > >> I dont think so. > >> > >> > Why is this project using different backends? > >> > >> because that is how the author decided to do it, it is not part > >> of SANE. Lately, SANE has begun to add support for buttons, but > >> not all backends do it yet, and the 'frontend' daemons (in our > >> 'experimental' tree) likely will need some work. > > > > Ok, I've begun some work on this. > > > > The daemons in the experimental tree miss some features: > > > > 1) they can't coexist with saned because they hold the devices > > open while polling and don't "know" about saned > > correct. I suppose you could have them connect to saned instead of > directly.
well, I don't think this will work (but I did not test it), because if the button-daemon uses saned to poll the devices, the device also remains opened via saned. So, saned forks a new child for the button-daemon and this child holds the device open. If another scan request (say scanimage via net-backend) arrives, saned forks a new child, which tries to open the same device and the gets device-busy. So the same situation as before. The algorithm must give saned sort of priority over the polling. My proposal is to stop the polling of the button-daemon, if saned gets called via the network. To be not too intrusive to the saned-code, I made a wrapper for saned: this wrapper is called from inetd, then sends signal to the button-daemon to stop polling, forks the saned and waits for it, and then reactivates the polling. > > > 2) they lack a hal/dbus interface > > correct. there was some discussion of this (search the archives) > but I don't recall if any code was produced for this or not. Ok, found the discussion but no code ;-( > > > Actually I have 1) functional and I'm working on 2). > > > > The problem right now is, that there are only few backends, which > > enumerate the buttons as sane-options. I have access to an epson > > 1670, an avision av122 and a fujitsu fi-6130 for testing, but the > > only one I can read the buttons as option is the fi-6130. Is > > there any further work on this on the backend side? > > The fujitsu backend is probably the most complete regarding > buttons. It is a fairly new part of the draft sane standard > however, so it will take some time for other backends to implement > support. > > allan -- Wilhelm
