Hello, On Jan 1 23:16 abel deuring wrote (shortened): > a happy new year to you all!
A happy new year to you too! 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). > 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 For some already known problems have a look at https://bugzilla.novell.com/show_bug.cgi?id=218393#c19 starting at comment #19 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. > ... "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. 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). 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? > 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? > HAL might be a way to integrate the permission handling > for parport scanners into the general "permission management" of a > Linux distribution. Yes! 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. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: jsm...@suse.de 90409 Nuernberg, Germany WWW: http://www.suse.de/