[sane-standard] SANE 2 driver suggestion

[Donald Straney]

> I doubt, if it makes much sense to call HAL from sane_get_devices.
> While it might save a few processor cycles, because not all known
> backends need to be tried, it might lead to difficult
> interdependency problems: A HAL callout, invoked when a scanner is
> connected to the machine, might actually call sane_get_devices, in
> order to get additional information about the device.

Ok, as long as programs can easily get a scanner list through HAL (and
if sane_get_device_list is used more by callouts and other system
stuff than by xscanimage, for example).

> If you means the functions send_usb_command, recv_usb_command etc
> from an older mail: I do not understand, what advantages these
> functions would have, in comparision with Sane's current approach as
> implemented in sanei_scsi and sanei_usb.

No, I was talking about adding objects to /sys through some kind of
kernel support for userspace drivers.

> If you are thinking about the famous "aunt Tillie", it really does
> matter ;) Why should users switch on their parport scanner together
> with the computer? But I think that Sane's current version handles
> this case just fine, provided that the right backend is enabled in
> dll.conf (disclaimer: I don't have any first-hand experience with
> parport scanners, but I assume that parport scanners do not behave
> that much different than parport printers).

Good point. ;)  Of course parallel port scanner detection works fine
now, I'm just trying to figure out how it would fit into a model based
on HAL or something similar.  I guess only a few drivers would need to
probe the parallel port and it would be really fast, so doing it each
time a program wanted to get a device list (and then adding any new
ones to HAL?) would probably be the best way to do it.

Donald Straney