HAL and scanners

[Richard Hughes]

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

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

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.

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

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

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

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

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

I don't think so.

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

Hope this helps,

Richard.