Re: generate hal fdi file

On 3/20/07, David Zeuthen <davidfubar.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"

-- 
sane-devel mailing list: sane-devellists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/sane-d
evel
Unsubscribe: Send mail with subject "unsubscribe
your_password"
             to sane-devel-requestlists.alioth.debian.org

On Tue, 2007-03-20 at 13:51 -0400, m. allan noah wrote:
> ok, i think i understand the distinction between 5 and
6, you cross
> the system to gui gap using dbus signals between two
processes?

That's correct.

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

All devices - some are ignored by HAL though since we
haven't made good
abstractions for those.

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

That it can plug into the HAL framework - udev doesn't know
per se that
some USB device is a scanner; there's no standardized way to
query udev
for this unlike HAL where you can do a 

 libhal_manager_find_device_by_capability (hal_ctx,
"scanner");

Udev is also the wrong approach for this; of course I'm a
bit biased
here (since I'm the HAL maintainer) but fwiw Kay Sievers
(udev
maintainer, HAL developer) thinks so too. Also, if you went
the udev way
you'd need to do your own IPC and connection tracking; not
necessarily
hard but I think it's more elegant just using D-Bus that is
already
available, API stable and so on and so on.

That and also..  udev is Linux specific. HAL is part of
OpenSolaris at
this point and since they use GNOME too I'd expect them to
pick up all
this as well. Same goes for FreeBSD although I must admit I
haven't
tried FreeBSD with HAL yet (but I plan to). There would be
nothing
Linux-specific about the HAL addon shipped with SANE if this
is what we
decided to do.

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

So this would work because libsane would be patched to open
private
connection to the system message bus daemon (e.g. D-Bus) so
it can call
into the HAL addon. If that process dies then the system
message bus
notices and sends out a NameOwnerChanged signal that we
catch it HAL.
This way of "connection tracking" is standard for
D-Bus using apps, many
use it (e.g. the screensaver, power management daemon and so
forth).

     David



-- 
sane-devel mailing list: sane-devellists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/sane-d
evel
Unsubscribe: Send mail with subject "unsubscribe
your_password"
             to sane-devel-requestlists.alioth.debian.org