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

[m. allan noah]

On 3/20/07, David Zeuthen <david at fubar.dk> wrote:
> 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.

ok, i think i understand the distinction between 5 and 6, you cross
the system to gui gap using dbus signals between two processes?

1. does udev signal HAL on every change to any device in the system,
or only certain devices?

2. what is the advantage to using a HAL 'addon' vs having udev spawn a daemon

3. what if the scanning app dies without signalling the addon to
re-start button monitoring?

allan

-- 
"The truth is an offense, but not a sin"