[sane-devel] Sane and HAL

[abel deuring]

Hi,

Johannes Meixner wrote:
> We use HAL in Suse Linux 10.1 and in openSUSE 10.2 to set
> access permissions for normal users.
> In Suse Linux 10.1 only for USB scanners and in
> openSUSE 10.2 for USB and SCSI scanners.
> Therefore I have a tiny experience in taming the udev->HAL beast.
> 
> What happens is:
> When a device becomes detected by the kernel and when there
> is a udev event (which doesn't happen in any case), then HAL
> is notified by udev and then HAL adds it to its device list
> so that it will be listed in the "lshal" output.
> Furthermore HAL looks up its fdi files if something special
> is to be done for this device.
> If an entry in a fdi file matches to how it is listed in the
> "lshal" output, HAL would do the action specified in the
> fdi file but again there are some (unexpected) constraints:
> For example HAL may kill a program which was started as the
> action specified in the fdi file after a short timeout
> (I guess to avoid too long delays).

If timeouts turns out to be a serious problem, we'll need to consult
the HAL developers. An optional timeout parameter for callouts might
fix it.

> 
> 
>>The minimum we can (and IMO should) do is to provide an XML file (or
>>".fdi file" in HAL terminology) that describes the scanners
>>supported by Sane, and optionally the unsupported scanners.
> 
> Have a look at
> https://bugzilla.novell.com/show_bug.cgi?id=160899
> in particular my bash script in
> https://bugzilla.novell.com/show_bug.cgi?id=160899#c20

So the Suse team is already doing basically the same as I proposed.
Seems that I am a bit too late ;) But I think it makes sense to add
information like the sane backend(s) that are "useful" for a
specific scanner to the data in the fdi file.

> For some already known problems have a look at
> https://bugzilla.novell.com/show_bug.cgi?id=218393#c19
> starting at comment #19

I think this is a HAL problem; hald might need some way to re-read
the fdi files, when it receives a signal.

> and
> https://bugzilla.novell.com/show_bug.cgi?id=226044
> The latter may be in particular useful to show an example
> how to debug a problematic case.

That's a problem with the SCSI bus: At least its simple variants, as
used by scanners, are not hotplugging-aware, so there is no way to
detect if a device is powered on or off. (BTW, better avoid to
(dis-)connect SCSI devices while any device on the bus is powered
on: this can destroy the driver transistors, no joke. And _never_ do
this with NCR5380 SCSI bus chips. For these chips, fortunately quite
old ones and today not often found in use, it is a safe bet that
they are broken after hotplugging ;)

A simple solution would be to restart hald from a script like
rescan-scsi-bus -- but some fully automatic automatic detection of
device removal/addition on a SCSI bus is not possible. But I think
this is not a big problem, because most of todays scanners are USB
devices.

>>... "interested" applications
>>can use this data to find a scanner and a suitable Sane backend and
>>launch for example xsane or access the scanner directly.
> 
> This does not work if a special setup for firmware upload
> is required.
> Therefore a firmware related entry would also be needed in
> the desc files and the in the fdi file.

Adressing the firmware question(s) would indeed be the next step.
(Note: this is a "backseat driver" comment: I don't have any
scanners that need firmware files, and I don't intend to buy one and
to start work on supporting it ;)

> My personal opinion is that I do not like it when my computer
> launches whatever program it thinks to be useful for me
> automatically (perhaps I don't want to use any graphical
> frontend at all or I prefer xscanimage).

I agree -- but the automatic start of an application seems to become
quite fashionable: When I plug in a USB memory stick, KDE starts a
file browser.

> 
> Furthermore it becomes tricky if more than one backend works
> for a particular model (e.g. epson versus epkowa backend).
> Perhaps it is o.k. to simply activate all matching backends
> but more than one backend might confuse an unexperienced user?

Right -- but this is also the case, if you start a Sane frontend
manually: If you have more than one scanner (or one scanner with
more than one backend), frontends either ask you, which
backend/device should be used (like xsane), or they use the first
one they find, like scanimage.

But if we have a unique combination of scanner and backend, HAL can
be used by a desktop enviroment to not bother the user with
unnecessary questions, when a scan program is started.

> 
> 
>>Another option would be another meta-backend named "udi", but I
>>believe that this would be overkill.
> 
> I think SANE should not depend on udev/HAL (i.e. it should
> still work even without any udev/HAL running or installed).
> Perhaps therefore another meta-backend named "udi" might be
> not a bad idea to keep the udev/HAL stuff strictly seperated?

Absolutely. Sane should not _depend_ on HAL, but it should IMHO
_support_ HAL. I was perhaps a bit terse: I wanted to suggest to add
another way to specify a Sane device, without breaking any existing
stuff.

At present, we have strings like "gt68xx:libusb:001:002" or
"net:hostname:fujitsu:libusb:003:004" . The dll "meta-backend" takes
the text before the first ':' as the name of the backend to load,
and passes the text after the first ':' to the function sane_open of
the loaded backend. Hence it would be straightforward to load a
meta-backend named "udi" -- but this new meta-backend would only
replace the UDI parameter with another device string like
"gt68xx:libusb:001:002", and then either call sane_open in the dll
backend again, or replicate all the work done by the dll backend.

The alternative would be to include this device string substitution
in dll.c -- of course properly enclosed in something like "#ifdef
HAVE_HAL ... #endif". Seems a bit easier to me ;)

>>HAL might be a way to integrate the permission handling
>>for parport scanners into the general "permission management" of a
>>Linux distribution.
> 
> Yes!

What I forgot to mention in my first mail: I asked also on the HAL
mailing list for comments about HAL support by Sane
(http://lists.freedesktop.org/archives/hal/2006-December/006826.html).
 Today, David Zeuthen writes over there: "Parallel port (and serial
port) support isn't really in HAL". So we should probably put
parport support aside for the moment.

> For example we use "resmgr" for our permission management
> and since openSUSE 10.2 the udev->HAL-resmgr chain works
> without any patches in SANE, see our RPM changelog:
> ------------------------------------------------------------------
> - disable-resmgr-support.patch disables the resmgr support in SANE
>   which is no longer needed in SANE because resmgr works now
>   outside of SANE via ACLs for the scanner device nodes.
> ------------------------------------------------------------------
> Since openSUSE 10.2 I can recommend resmgr for such kind of
> permission management. Before I was not happy about how it works
> because it required that the software was patched so that
> third-party packages would have worked different than our
> patched packages.
> 
> Note that in our scanner related fdi files there is no "resmgr"
> mentioned. All what is done via the scanner related fdi files
> is to mark a HAL device udi to be a "scanner" and then via well
> seperated resmgr related fdi files (with fixed content) the
> permissions are set for those HAL devices which are a "scanner".
> 
> I.e. it is independent to tell HAL which device is a scanner
> and what a distribution or an application may like to do with
> this information.

Right, we should include only strictly device-specific and
sane-specific stuff in the fdi file. And even if a distribution
wants to add some special things to this file -- there are XML tools
like xslt that make this quite easy.

Abel