[sane-standard] SANE 2 driver suggestion

[abel deuring]

m. allan noah wrote:
> [SNIP Re: in-kernel drivers]
>> It's too bad, though, since there's no way to take advantage of the
>> 2.6 kernel's great hardware system without that, and as I said before,
>> duplicating it in userspace with a daemon and a list of bus IDs
>> compiled from the drivers and everything seems inefficient and
>> inconsistent, definitely not the right solution.
> 
> inconsistent only as compared to linux, but very consistent as compared to
> other platforms, which sane devels must keep in mind.

exactly.

>> Maybe the kernel
>> needs a standard way for userspace drivers to register hardware in
>> /sys, create device nodes in some way that works well with udev, and
>> automatically load the right library (from userspace, of course) when
>> the hardware's present, but that's a whole different matter...
> 
> this i think is the best solution. a shim inside the kernel, and the
> bulk of
> the code outside.

Would the advantage(s) of using sysfs (as I understand it, that's
basically better button handling for daemons and perhaps easier
backend/driver detection) compared to the "software layers" we use
currently really be big enough to design a specialized Linux version
of Sane? And before we discuss this in greater depth, we should ask
the kernel developers, what they think about special support for
scanners. If they don't like it, we're only producing hot air...

> theoretically, using the description files, sane should be able to map a
> specific usb id to a specific backend. scsi is more difficult, pp is almost
> impossible. i dont know enough about how things get into /sys to go any
> further. must do more research.

The "hardware registration" suggested by Donald can easily be done
via hald -- we only need to transform Sane's *desc files into *fdi
files for hald. I have already tested this -- I mainly need to
replace my prototype Python script that creates the fdi files with a
patch/new output mode for sane-desc.c . I also played a bit with a
hald callout for scanners; this callout can give some additional
information.

SCSI scanners are not a problem for hardware detection by hald: We
just need to add a new tag like ":scsiid" to the *desc files, which
specifies the vendor and model string. OK, this does not fix the
problem that a SCSI scanner must be powered on, when the kernel
scans the SCSI bus for devices -- but this is a limitation of the
SCSI bus.

Abel