On Thursday, 3. May 2001 10:51, you wrote:
> In a message dated 5/3/2001 3:19:34 AM EST, moitinho@civil.ist.utl.pt
writes:
> > I have read the arguments in favour of different drivers, you don't need
> > to try to explain, but I still don't understand why (for instance) the
> > usb-storage driver doesn't work (at least id didn't). Just my problem of
> > thinking that I understand what I don't.
>
> There's no good reason why a single driver shouldn't serve
> as a scsi->usb device driver for all devices that need to look
> like a scsi device to higher level routines.
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.
> Oliver claims this would be too hard to write, but I've done it
> on Windows and Mac OS and it isn't hard. The upper levels
> of VueScan think they're working with SCSI scanners, and
> at the lowest level I translate scsi commands to USB
> commands. The trick is to design the driver to do this from
> the start. This works today on Windows and Mac OS with
> HP, Epson, Avision, Acer, and AGFA USB scanners. I did
> the same thing with Firewire scanners on Windows, since
> they also encapsulate scsi commands on Firewire (SBP2
> protocol). Someone already did a generic scsi->firewire
> driver on Linux, and a similar scsi-usb driver is all that's needed.
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.
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.
> Note that the advantage of using generic scsi->usb and
> scsi->firewire drivers is that there isn't any need to set
> up configuration files specifying which scanners (and
> what type of scanners) are on the system. The nice
> part of scsi is that it's possible to poll each device to find
> out what kind of device it is, instead of depending on the
> user to set this up (this is a lot more user-friendly). This
> is how VueScan works.
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.
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.
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.
After that for microtek and hp5300 then you can probe as for conventional
scsi. Generic usb scanners are a problem though.
> This driver the kind of thing I'd assign a college intern or
> beginning programmer to do - it's not hard. If nobody on
> this list has any kernel programming experience, I'll do it
> myself in a month or two as soon as I finish some higher
> priority tasks in VueScan. However, if I write it, I plan to
> sell it (it won't be open source). If someone wants to
> write it and make it open source, I'd be happy to provide
> them the technical assistance they'd need to get it working
> with a wide range of usb scanners.
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.
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.
The resulting driver would end up much more complicated than generic scanner,
which is beautifully simple.
I am quite convinced that it would not be accepted into the kernel, even be
it open source.
What we need to solve is the problem of identifying usb device with a device
node with IMHO a generic ioctl. And someone should sacrifice his keyboard for
fixing autoloading for scanner.o
Regards
Oliver
-- 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 - 02:42:50 PDT