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
