On Sun, 2007-03-18 at 20:16 +0100, Étienne Bersac wrote: > Hi, > > This is a true problem i don't really know how to solve. Luckily, SANE > people have just commited fdi generator to SANE CVS. So we should have > proper device detection in the next release.
Right, it was actually committed today http://lists.alioth.debian.org/pipermail/sane-devel/2007-March/018764.html http://lists.alioth.debian.org/pipermail/sane-devel/2007-March/018763.html http://lists.alioth.debian.org/pipermail/sane-devel/2007-March/018851.html I'll add the docs + other things to HAL so the 'scanner' capability is defined. Note that HPLip etc. needs some work too since they are their own little HAL-ish implementation... (I'll spare you for my thoughts on HPLip - they aren't nice) > However, this does not > solve sharing and button event handling. > > The problem with addon is : to bind to SANE or not to bind ? SANE has > already several backends and tons of device supported. Including buttons > handling. Imho, writing several backends just for button handling is > waste. > > However, the problem with linking to SANE is the locking of device. If > HAL own the device, xsane, kooka, gnome-scan won't be able to use it. > > scannerbuttonsd from SANE CVS use libusb for buttons handling, would be > nice to have it as an hal add-on. Yeah. Suppose we have a halified scannerbuttonsd (e.g. running as an addon, emitting D-Bus signals etc.), would it know to give up access to the device (e.g. close the file descriptor) when libsane wants to use it? David _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
