> > Subject: Re: HP 7400c info / Minolta Scan Dual II
> > Date: Thu, 3 May 2001 16:16:38 EDT
> > From: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> >
> > In a message dated 5/3/2001 4:52:31 AM EST, [EMAIL PROTECTED]
> >
> > 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.
That seems excessive/extreme ... or were you only talking "scanner.c" ??
> > For instance,
> > whoever wrote the scanner.c driver didn't even add the capability to
> > ask the device what it's VID/PID is
Hmm, this problem cuts two ways. There are two basic ways to
view a USB scanner: generic USB device, or /dev/... scanner device.
The "scanner.c" driver connects those two views, but there's currently
no user-visible linkage between them.
One way to address this has been prototyped for printers: let the
hotplug subsystem tell the scanner subsystem about device types,
since it's already got that data available:
http://marc.theaimsgroup.com/?l=linux-usb-devel&m=98639571912668&w=2
That does the job for "printer.c" ... perhaps the right solution is
to merge that into the kernel, and teach scanner.c about the same
sort of stuff.
Or, it could go the other way around. If you're scanning /dev/...
nodes, add a corresponding ioctl to find which USB device is
involved, and then use the existing USB support to find VID/PID.
And there's also Alan's suggestion, to do scanner drivers entirely in
usermode, focussing development work on usbdevfs and APIs to it.
(I think the Java USB API is more powerful than libusb, but that can
just be a hacker challenge ... :)
- Dave
> > 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).
>
> Hmm. Well, if there we get concensus that this is true, are you
> willing to take a stab at creating a example implementation that does
> things more optimally? If not, than if you would itemize the changes
> you think would be needed, then someone else on in the USB development
> community might be willing to make those changes.
>
> Cheers,
> Miles
>
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
