HAL and scanners

[David Zeuthen]

On Fri, 2006-12-29 at 15:57 +0100, abel deuring wrote:
> > This sounds like this would belong in hal-info, but that's a final
> > technicality. If there are a lot of devices, we will probably want an
> > --disable-scanners option for stuff like n770 and OLPC.
> 
> I believe it would be better to put the generator script into the
> directory "tools" of the Sane backends source code. The list of
> supported and known-but-unspported scanners changes quite often;
> even the "packaged" Sane source code can be a bit out of date. As an
> example, Gerhard Jäger, the author of Sane's Plustek backend, writes
> on his home page (http://www.gjaeger.de/scanner/plustek/): "The
> status in the table [of (un)supported scanners, AD] refers to the
> latest backend version available on this page.  For a list of
> scanners supported in the current official SANE release, see the
> SANE backend list."

Yea, I think this is nicest too and, for the record, what gphoto2 does
as well. So if the user upgrades the SANE package [1] on their system
then the .fdi files are updated and the right thing happens the next
time they use their scanner.

> OK, so here is a simple draft for the name space "scanner":
> 
> scanner.api [instead of scanner.drivertype in the example above]:
> strlist; tells hal for which APIs drivers are available. Other
> useful values might be "vuescan" (a commercial scanner application)
> or "gnomescan", for the Gnome scanner API currently developed by
> Étienne Bersac.

As discussed other places in the thread this gnomescan==scan as
gnomescan is a wrapper for SANE.

> scanner.vendor: string; a scanner's vendor name
> 
> scanner.model: string; a acanner's model name
> 
> scanner.sane: sub-namespace describing Sane specific details
> 
> scanner.sane.backend: strlist; names of Sane backends that support a
> scanner.
> 
> scanner.sane.supportstatus: strlist; "quality" of support of a
> scanner/backend combination. possible values: "untested", "minimal",
> "basic", "good", "complete", "unsupported", "unknown". (the first
> six values are defined in the specification of Sane's *.desc files;
> I added "unknown" to deal with a *desc file that does not provide a
> status value. Regarding "unsupported", see below.)

Looks good to me.

> Many USB vendor/product IDs identify a chipset which is used by by
> different vendors in sometimes quite different models. Figuring out
> the "best" entry would require in many cases at least a callout that
> uses something like "scanimage -L". Gerhard Jäger lists for example
> three different scanners that share the USB vendor/product IDs
> 0x07b3/0x0017, and there are many more similar cases.

Right, for such problematic USB vendor/product pairs use a callout to
further investigate the device. 

That's just adding an entry to info.callouts.add that runs a program
where you can modify the properties you've already merged.

> >>4. Aside from backends for "usual" scanners, Sane has also backends
> >>for a few cameras, and the *desc files provide information for
> >>"non-devices" like the net backend. Does it make sense to include
> >>data about some or all of these in an fdi file?
> > 
> > Not in the scanner namespace in my opinion.
> 
> yes and no ;) Of course, from an end user's viewpoint it is a bit
> strange to list a webcam under "scanners", but the fdi file provides
> also information how to access a device -- and a useful API would be
>  Sane for some webcam.

I think this makes sense; we need to enable as much hardware as possible
even if it got a weird driver (e.g. a camera with a driver written for a
scanner framework or vice versa.). 

Btw, if it's truly a camera, but has a SANE driver, then perhaps some
day a gphoto2 driver will surface and then, if you have both drivers,
the user will be able to access it as both a scanner and a camera. How
the GNOME and KDE's of the world is going to deal with *that* is going
to be interesting but if they don't support it, it's probably their bug
and we can fix that later.

     David