On Thursday,  3. May 2001 10:51, you wrote:
> In a message dated 5/3/2001 3:19:34 AM EST, [EMAIL PROTECTED] 
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

_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to