HAL and scanners

[David Zeuthen]

On Wed, 2006-12-27 at 23:48 +0100, abel deuring wrote:
> Hi all,
> 
> I am a (though in the last time not-very-active) Sane developer.

Thanks for posting this; it's very useful!

> During a recent discussion on the sane-devel mailing list about the
> question, if/how the Sane team can/will be able to work on a new
> version of the Sane API, Étienne Bersac and Martin Owens suggested
> that Sane should somehow provide HAL support or integrate HAL or
> whatever. Details on how this integration or support should look
> like remained quite vague, so I thought to address this question
> from a practical viewpoint. Starting with something that is quite
> easy to implement, might lead to a better cooperation ;)

Sounds good!

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

So, for situations where a single (VID,PID) pair describes more than one
model I'd do this

 <device>
  <match key="usb.vendor_id" int="0x1234">
   <match key="usb.product_id" int="0x5678">
    <append key="info.callouts.add" type="strlist">sane-hal-probe</merge>
   </match>
  </match>
 </device>

where sane-hal-probe is run just before the device is added to HAL. 

Then you can investigate the device and adjust the properties as
appropriate. Initially you can just run this every time you see a
scanner but ideally you only run it when you have drivers that supports
multiple models sharing the same (VID,PID) pair.

> 2. For some scanners, more than one Sane backend exists.

It's not super necessary to make the hal properties reflect that there
is more than one backend; that can be delayed until the frontend using
the SANE driver runs right?

> 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 an "or expression" for the <match> tags?

Yes, you will need one for each interconnect I think.

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

Yes, I think it makes sense to include fdi files for all devices that
can be attached to the system. For networked backend's, I don't think it
makes sense to store that in HAL...

> 5. Does it make sense to list unsupported scanners in the fdi file?

Sure, if you know it's a scanner but currently don't have a driver it
makes sense I think. At least the UI can display "No driver for your
scanner" instead of just "No driver for your hardware".

> 6. What information would be needed for parallel port scanners, and
> for the IEEE-1394 interface in order to identify them?

Parallel port (and serial port) support isn't really in HAL; for
Firewire, I believe you can match on existing bus properties provided by
HAL (though with krh's new firewire stack that might change a bit).

       David