Scanners in HAL

Kay Sievers kay.sievers at vrfy.org
Mon Aug 28 08:52:21 PDT 2006


On Mon, 2006-08-28 at 17:43 +0200, Marcus Meissner wrote:
> On Mon, Aug 28, 2006 at 05:35:35PM +0200, Étienne Bersac wrote:
> > I wonder how does hal know a device is a camera, a printer, etc. Is that
> > only a matter of .fdi files ? Do we have to maintain a vid/pid list like
> > udev libsane.rules ?
> 
> Correct.

Yeah, please.

> For libgphoto2 we have an extractor which loads our camera libraries and
> dumps a FDI file to have them marked up.
>  
> > > Once you have this you can hand-out permissions for libusb access
> > > from userspace. SUSE does this with "resmgr".
> > 
> > Seems that ubuntu use udev rules to handle permissions.
> 
> This is the current way, but as I understand Kay it will move
> to be responsibility of hal.

Definitely. It's completely crazy to put 500+ rules into udev just to
assign a scanner to local group. Udev is totally the wrong
infrastructure to do this. Also local groups without login-tracking are
the wrong way to do such a thing.

> > > Once you can export the list, you can have easy listener daemons.
> > 
> > So the daemon won't use sane_get_devices but just sane_open on a device
> > id provided by HAL (e.g. id field in a sane namespace).
> 
> This would be the best.

You would probably want libsane to accept HAL device identifier (udi) to
open a device.

> > > - Extract list of usb ids, possible automatically from sane build.
> > >   
> > >   => Find out scanner
> > 
> > Does that mean i have to investigate SANE source code in order to write
> > a tool that extracts vid/pid to write rules for HAL ?
> 
> I guess you should suggest this to the SANE developers first.

Yes please, let them provide a fdi file for HAL to classify a scanner
and deprecate the crazy udev rules file.

> > > - sane based listener that injects DBUS events (there are some related
> > >   projects already).
> > 
> > Does that mean a scannerd as dbus service ? Can you point me the
> > "related projects" ?
> 
> Perhaps someone else can, it was just a wild idea.

You probably just want a HAL add-on, that is instantiated when such a
device shows up, and not just another weird stand-alone daemon.

Kay



More information about the hal mailing list