[sane-devel] Re: [PATCH] generate hal fdi file

[David Zeuthen]

On Tue, 2007-03-20 at 13:03 -0400, m. allan noah wrote:
> > > > i would rather see a more general, non-linux specific method of
> > > > handling buttons. how about a daemon that runs, gets the sane device
> > > > list in the normal way, and then monitors each of the found devices
> > > > for button presses as regular sane options.
> >
> > That's essentially what I propose to do except that monitoring of each
> > scanner happens in a separate sub process (which you want to do anyway
> > since it's more robust) and it integrates into the standard device model
> > offered by HAL, e.g. D-Bus signals and so on.
> 
> ok, i am having trouble wrapping my mind around all these
> HAL/dbus/Gnome things, so forgivemy ignorance. 

Oh, that's fine - it _is_ pretty complicated unless you're an expert
with HAL and I don't blame you for not being :-)

> i have copied part of
> an older mail below:
> 
> ==========================
> 1. User attaches USB scanner [0]
>  2. kernel notices USB device
>  3. udev creates device nodes; sends event to HAL
>  4. HAL figures out (via the fdi file that is now in) that the USB
>    device is a scanner supported by SANE
>  5. HAL launches an add-on [1] to monitor button presses; this would
>    pretty much be like sanebuttonsd, only it would emit D-Bus events
>    via HAL when buttons are pressed
>  6. The desktop environment (e.g. GNOME, KDE and others) would be able
>    to catch this signal and launch an app for scanning that is using
>    libsane
>  7. App using libsane starts up and figures out what device to use. When
>    it finds a device it calls sane_open() as usual.
>  8. /usr/lib/libsane.so is patched so sane_open calls the D-Bus method
>    InhibitMonitoring() on the HAL addon just before it calls into the
>    backend. This makes the addon close the device so the back-end can
>    actually use it. I suppose this can be done in backends/dll.c?
>  9. sane_close() in /usr/lib/libsane.so calls AllowMonitoring() on the
>    HAL addon right after it returns from the backends sane_close().
>    This make the addon resume button monitoring. [2]
> 
> ==========================
> 
> i do not see why #5 and #6 are required. if HAL-started process can
> monitor buttons on the device, then why can it not handle the child
> process as well? think of all the places linux is used that dont have
> a GUI. what am i missing?

I'm not sure I understand your question... you need _some_ kinda of
process to monitor the device. My proposal is to launch that process by
HAL, that's #5. It's essentially just sanebuttonsd just reworked to work
as an HAL addon. The process in #6 would be a session-based daemons with
access to the X display - for GNOME this would be gnome-hardware-manager
(which is gnome-volume-manager just renamed).

The reason that #5 and #6 needs to be separate is that HAL is a
system-wide process and don't have access to the users display. In fact,
there may be zero (think server), one (think personal workstation,
laptop) or more users (think fast-user-switching, remote XDMCP sessions
and multi-seat) logged in at the same time. It also runs with privileges
that the admin might not want to grant to a user.

This is also nice as many distros are moving away to starting daemons
that are rarely used by an initscript. E.g. HAL will only launch the
addon if there is actually a scanner attached.

Hope this clarifies, otherwise just ask! Thanks.

      David