HAL and scanners

[Martin Owens]

Hello,

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

The problem comes when there are very few properties you can search
for in order t further identify a device, in such cases it might be
wise to provide a plug-able feature (this includes passive ports too)
where the list of possible identifications is recorded and it's made
clear that the user can't use the device until it's been 'pluged-in'
on the computer software side as much as on the hardware side. HAL
could handle this in a very elegant way, providing not only the
potential options but a way to let the client program know it's a
'undecided' device or port.

The way in which choices are held against the device would have to be
done by port, passive or usb port which hal knows to an extream level.
then at least the user choices wouldn't be lost on reboot.

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

Indeed, even though it is quite important to design a framework for
passive devices; I am quite suprised the task has been put aside for
so long.

Kind Regards, Martin Owens