> I wasn't sure what to do about the USB code when I updated the snapscan driver for
> colour correction. Iwanted to merge everyone's latest goodies, but I had no way to
> test them. I merged the parts of the USB which go into the other files, and the
> transparency patch, since they were pretty minor, and made sense in relation to
> the rest of the driver. If you find the whole thing runs acceptably with a 620UT
> its probably time to stuff the remaining elements of the USB update - the actual
> USB interface itself - into CVS.
The code works for me. It isn't bullet proof and still has a lot of problems
related to it. The main problem I recognize is that it requires a lot of
(1) modify code (or supply an option during compilation)
(2) fiddle with kernel modules
(3) upload firmware.
(1) prevents the code from being usable in binary distributions,
(2) may change with kernel 2.4 and more wide-spread USB,
(3) would require some smart algorithm that recognises the scanner and uploads
the apropriate firmware file.
The USB code itself is pretty simple, as far as I can see. It more or less
sends the raw SCSI commands to the USB interface. As far as I know this is also
done in other backends (hp?), so maybe it would make sense to have a common
sane USB layer. This would probably solve (1).
As far as firmware is concerned I don't know if other backends need firmware
uploads as well. If so a common solution would probably make sense.
However, as a first step I think it would make sense to put all USB related
files (snapscan-usb.*, acerfirm, agfafirm) into CVS so that people who want to
try USB don't have to get them from 3 different sources.
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail firstname.lastname@example.org
This archive was generated by hypermail 2b29 : Sun Jul 30 2000 - 05:08:45 PDT