In a message dated 5/3/2001 4:52:31 AM EST, Oliver.Neukum@lrz.uni-muenchen.de
writes:
> Our disagreement seems to be rather in the type of scanners that should
> appear as scsi devices to user space.
> If I understand Ed correctly, to him that would be all of them.
That's correct - but I'd make it a generic scsi->usb driver that
could easily be modified to add support for other usb peripherals
that encapsulate scsi over usb.
The reason USB is so messed up on Linux is that too many people
took the easy way out instead of planning for the future. For instance,
whoever wrote the scanner.c driver didn't even add the capability to
ask the device what it's VID/PID is or to allow reading the interrupt
channel. As a result, there are a slew of barely working drivers
for scanners, and even these are kludges that are poorly tested
(i.e. the HP5300 driver doesn't work with the Scan Dual II).
The right way to handle USB scanners in the kernel is a single
device driver that does scsi->usb translation.
> Firewire is a better design. There is no question about that.
> USB has no common protocol for transfering SCSI commands.
> In fact I know of _six_ incompatible protocols to do that.
These are the ones I know of:
1) HP/Epson (read/write bulk endpoints)
2) Avision
3) Acer/AGFA SnapScan
4) Nikon LS-40
5) Microtek (actually at least 2 different types)
6) Canon FB-series
For #1, the driver needs to emulate the scsi INQUIRY
command based on the VID/PID, but this is only a few
lines of code.
> The attempt to unify them leads to a monster like usb-storage.
> I wanted to add the microtek protocol to usb-storage, but Matt vetoed that.
It's open source - you can add what you want to whatever you
want. Working code (if it's more elegant than the code it replaces) rules.
> I could trivially merge microtek and hp5300 to a common driver.
> However there would still be the generic driver (scanner.c) and
> the two drivers currently under development for even stranger scanners.
The only thing remaining for scanner.c is Epson and HP, and
these are better done in the single scsi->usb driver.
> Reducing the number of drivers from 5 to 4 isn't IMHO worth the trouble.
> Unless you go to one, you need to look it up anyway, thus simplicity in
> kernel is more important.
Yes, going to one scsi->usb driver is the way to go (including
storage).
> As for configuration, loading a driver for your usb scanner is the same
> trouble as loading a driver for the controller your scsi scanner is
attached
> to.
The problem is that there's too much user-configuration that needs
to be done. A user should just run a scanner program, and the
scanner program should determine what scanners are connected
to the system.
> After that for microtek and hp5300 then you can probe as for conventional
> scsi. Generic usb scanners are a problem though.
They're only a problem because the user-mode interface to the
usb subsystem is so primitive on Linux, and you can't even get
the VID/PID of a scanner from user space.
> For generic scanners you _could_ go the easy route.
> Emulate INQUIRY based on a table of vend./prod. ids and
> map read/write over usb to SCSI_READ/SCSI_WRITE.
Yes, this is what I do in VueScan on Windows and Mac OS.
It works quite nicely. Just run VueScan on Windows, Linux
or Mac OS with any USB scanner and turn on the log file (a
dump of the scsi commands) and you'll see this. VueScan
works with scanner.c on Linux, but you have to tell it the
device name, the VID and the PID. It doesn't work with
Avision scanners (Scan Dual II, 5300C, 7400C) on Linux
because scanner.c doesn't allow reading the interrupt
pipe.
> It can be done. Even the unusual scanners could be handled with vendor
> specific commands. However at some point you end up with a scsi
interpreter
> in kernel.
It's all very simple table-driven, finite state machine stuff.
Regards,
Ed Hamrick
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
This archive was generated by hypermail 2b29 : Thu May 03 2001 - 13:07:48 PDT