HAL and scanners

[abel deuring]

Richard Hughes wrote:
> On Wed, 2006-12-27 at 23:48 +0100, abel deuring wrote:

>>Obviously, an .fdi file with scanner information can be useful for
>>HAL, and the Sane source code contains files that describe supported
>>and some unsupported scanners, so I wrote a little converter script
>>that generates an .fdi file from these files. At present, Sane's
>>scanner description (*.desc) files contain only the USB vendor and
>>product IDs, but not things like SCSI vendor/model strings, so the
>>result is not really comprehensive. The fdi file generated by the
>>script describes nevertheless 325 supported USB-scanners nd some 200
>>unsupported USB scanners.
> 
> 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."

So I think that "make install" for sane-backends could generate the
fdi file and place it into /usr/share/hal/..., if HAL is installed.
This ensures that the correct version of Sane's scanner fdi file is
being used. The maintainers of the Linux distributions might have
another opinion, how to deal with a scanner fdi file: It might be
useful to have a scanner fdi file available even without Sane being
installed, in order to present an desktop dialog window like "you
just plugged in a scanner, but no scanner software is installed. Do
you want to install the packages Sane-backends and XSane and... now?"

> 
>>A single device description looks at present like this:
>>
>>  <device>
>>    <match key="usb.vendor_id" int="0x05da">
>>      <match key="usb.product_id" int="0x009a">
>>        <merge key="info.capabilities"
>>               type="strlist">scanner</merge>
>>        <merge key="scanner.drivertype" type="string">sane</merge>
>>        <merge key="scanner.sane.backend"
>>               type="strlist">microtek2</merge>
>>        <merge key="scanner.vendor" type="string">Microtek</merge>
>>        <merge key="scanner.model" type="string">SlimScan C6</merge>
>>        <merge key="scanner.sane.supportstatus"
>>               type="string">complete</merge>
>>      </match>
>>    </match>
>>  </device>
>>
>>A quick test with a USB scanner and a SCSI scanner (for the latter,
>>with a manually edited fdi file) showed that lshal lists the
>>scanners just fine.
>>
>>I can't claim to know much about HAL and the things that might be
>>useful for projects like Gnome and KDE, so I am not sure, if the
>>entries for the "scanner" name space really make sense from the
>>viewpoint of an application developer. Comments for additions /
>>changes etc are welcome.
> 
> I think this is fine. You might want to append the capability "scanner"
> rather than merge, in case the device already has another capability.

uuhh, yes "append" is of course better than "merge" for the
capabilities.

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.

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

>>Problems/questions/remarks regarding my current approach:
>>
>>1. For some USB vendor/product IDs, the Sane *desc files list more
>>than one supported scanner model. As I understand it, the last entry
>> "wins", if these devices are described by <merge> tags. Can I
>>simply replace all affected <merge> tags with <append> tags? (The
>>word "append" suggests that a thingy must exist before another
>>thingy can be appended ;)
> 
> Yes, the last entry wins. You'll need to use a strlist (string list) if
> you want to use append, but I would argue that maybe the "best" entry
> should be chosen, rather than give all the options.

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.

I don't have any first-hand experience with these scanners, so I
don't know, if perhaps the user must be asked, which scanner model
is actually being used.

If it is indeed a problem to have longer lists of possible scanners
models for one USB vendor/product ID, we may need to ask the
maintainers of the affected Sane backends how to fix it.

>>2. For some scanners, more than one Sane backend exists.
> 
> See above.
> 
>>3. Scanners may have more than one host interface; some Fujitsu
>>scanners for example can connect to the SCSI and the USB bus. Do
>>these scanners need more than one <device>...</device> description,
>>or is there something like a
> 
> No or, you need multiple device tags. You can nest these without
> breaking out of </device>. For example, see the video-pm files in
> hal-info for how to optimize these.

So something like the following would be useable?

  <device>
    <match key="usb.vendor_id" int="0x04c5">
      <match key="usb.product_id" int="0x10e0">
        <merge key="info.capabilities"
               type="strlist">scanner</merge>
        <merge key="scanner.drivertype" type="string">sane</merge>
        <merge key="scanner.sane.backend"
               type="strlist">fujitsu</merge>
        <merge key="scanner.vendor" type="string">Fujitsu</merge>
        <merge key="scanner.model" type="string">fi-5120C</merge>
        <merge key="scanner.sane.supportstatus"
               type="string">good</merge>
      </match>
    </match>
    <match key="scsi.vendor" string="FUJITSU">
      <match key="scsi.model" string="fi-5120Cdj">
        <merge key="info.capabilities"
               type="strlist">scanner</merge>
        <merge key="scanner.drivertype" type="string">sane</merge>
        <merge key="scanner.sane.backend"
               type="strlist">fujitsu</merge>
        <merge key="scanner.vendor" type="string">Fujitsu</merge>
        <merge key="scanner.model" type="string">fi-5120C</merge>
        <merge key="scanner.sane.supportstatus"
               type="string">good</merge>
      </match>
    </match>
  </device>

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

>>5. Does it make sense to list unsupported scanners in the fdi file?
> 
> I don't think so.

Sorry, my question was a bit terse. People ask more or less regulary
on the Sane mailing list questions like "I bought the scanner XYZ
made by company ABC. I tried to connect it to my Linux box but I
can't use it. What should I do?" Unfortunately, the answer is quite
often "sorry, this scanner is not supported by Sane. Somebody
already tried to ask the vendor for developer documentation, but got
no response." It could make sense to give a user an idea what can be
done or not done, if s/he plugs in an unsupported scanner. But this
is a policy question (and anyway at present pure theory -- I don't
know about any "end-user visible" hotplugging functions for scanners
under Gnome or KDE, comparable to opening a file browser when a
memory stick is plugged into a USB port), so I'll just add an option
like "--include-unsupported" to the fdi generator script.

>>6. What information would be needed for parallel port scanners, and
>>for the IEEE-1394 interface in order to identify them?
> 
> You mean to do probing? DavidZ suggested a way to do this for serial
> ports on the list a few months ago, although nothing has been done yet.
> See the thread here:
> http://lists.freedesktop.org/archives/hal/2006-September/006086.html
> 
> I'm sure we can help you with this, as it will be very common with
> serial probing. Does the parallel port return a device specific ID? if
> it does, you could <match> on this.

I have no idea -- to be honest: my "scanner knowledge" is mostly
limited to SCSI devices. We'll need input from the Sane developers
who know more about parallel port scanners.

Abel