Update on DeviceKit

David Zeuthen david at fubar.dk
Wed May 7 10:41:31 PDT 2008


On Wed, 2008-05-07 at 19:32 +0200, Étienne Bersac wrote:
> Hi,
> 
> > Where do you expect callouts and addons are needed?
> 
> See hal-scanner i submitted on this list. SANE driver allow to poll
> registers in order to receive event like "paper-in", "scan", "cancel"
> from hardware button and much more. Some device allow to configure scan
> from the device (e.g. using wheel).

So for this use case, I'd actually propose instead to write a small
desktop session daemon. It would export an interface

 org.fd.ScannerButtons.Listener

with a simple interface to inhibit listening for button events.

Anyway, then your scanner access library would inhibit that daemon
whenever it needs access to the device (USB devices are single opener
only). For proper multi-user support, I'd listen to ConsoleKit signals
in the daemon to stop hogging the device when the session is inactive. 

The reason I think a small session daemon is better, is that a) you can
use things like gconf to retrieve settings about what programs to launch
when buttons are pressed etc. (so it's easy to write a configuration
applet); b) you can interact with the user asking him what program to
launch etc.

(Maybe you'd want to standardize this name/interface so all desktop
environments can provide their own implementation of this service. E.g.
perhaps KDE wants a version that uses KDE libraries / Qt.)

> >From callouts, i except to have the SANE device name as device property.
> Without that, frontend needs to "probe" scanners which mean loading
> every SANE backends and ask them to loop each port for an existing
> driver. This process takes a looong time (compared to printer listing
> with cups).

You'd do the callouts via OS-specific interfaces. On Linux that would be
udev. The values you set via udev rules are available as properties via
the DeviceKit service.

      David




More information about the hal mailing list