HAL and scanners

[abel deuring]

Hi all,

David Zeuthen wrote:

> 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. Eventually, the question, how many hardware details should be
available to HAL and where this information is located, is anyway
decided by the package maintainers of the various Linux
distributions. Keeping the fdi file (or even better, only the
generator script and some callouts) in Sane minimzes bureaucracy.

Johannes Meixner (from Novell/Suse) came up on the Sane mailing list
with the question, how conficts can be avoided, if we have more than
one fdi file. For example, Epson distributes its own Sane backend.
Any recommendations for fdi file names and locations in
/usr/share/hal/fdi ?

>>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.

>From a different dicussion I understand that Étienne intends to keep
the gnomescan API "open enough" to be able to integrate other
low-level scanner APIs. So it might make sense to optionally add
gnomescan. But this is a question we can leave to the Gnome developers.

> 
>>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.

OK. There were some discussions, if a key like
"scanner.is_supported" or "scanner.sane.sane.is_supported" makes
sense; meanwhile I think that this is redundant: The namespace
"scanner.sane" should only be populated, if a device is supported.
Similary, scanner.api should only get the entry "sane", if a backend
is available. So I'll drop the value "unsupported"
scanner.sane.supportstatus.

>>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.

OK; if some "equivalent" of "scanimage -L" is run, we'll get the
"real" vendor/model information. In this case, only

BTW: If such a callout exists, couldn't the vendor/model information
for supported scanners be removed from the fdi file, or are there
use cases for HAL, where this data could be used, when a specific
device is not present? The fdi file has even today (without most
SCSI scanners) a size of 300 kB...

>>>>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.). 
> 

I believe meanwhile that the decision could be passed to
distribution maintainers: Whatever you do, include the cameras or
not, users may complain or may be confused...

> 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.

Yup ;)

Abel