Update on DeviceKit
david at fubar.dk
Wed May 7 15:08:35 PDT 2008
On Wed, 2008-05-07 at 21:29 +0200, Étienne Bersac wrote:
> > 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.
> That's exactly org.freedesktop.Hal.Device.Scanner iface. See HAL
> scanner. Did you review hal-scanner ?
> http://lists.freedesktop.org/archives/hal/2008-March/011175.html I ship
> a tiny documentation in PDF.
Cool, so it should be somewhat easy to port.
> > For proper multi-user support, I'd listen to ConsoleKit signals
> > in the daemon to stop hogging the device when the session is inactive.
> Very interesting, thanks.
> Another issue : is it possible to launch the session wide service only
> if at least one scanner is up ?
Don't think so, not easily.
What we need is some kind of "reverse" activation meaning the ability to
run code when one or more well-defined events happen. I'm not exactly
sure where the best place for this is; it's something you need both in
the session (e.g. gnome-session) and in the system (e.g. init).
(And ideally the session process leader and the system processes leader
would share a lot of code since they do a lot of similar things.)
I don't know.
> > you can use things like gconf to retrieve settings about what programs
> > to launch when buttons are pressed etc.
> Well, gnome-volume-manager already handle scanner hotplug using HAL, but
> not for scanner signal.
(FWIW, g-v-m is in the process of being deprecated.)
> > You'd do the callouts via OS-specific interfaces.
> Ah. This mean that firmware loading won't be done by HAL anymore ? Sad,
> i built isight-firmware load using HAL callout in order to be more
> portable (accross distro, but also accross *NIX).
I think HAL will be around in distros for at least a couple of years.
But as Matthew says this really belongs in an udev rule on Linux.
More information about the hal