cbagwell@sprynet.com wrote:
>
> Hi,
>
> I'm interested in improving USB support inside of SANE since I have a USB scanner (Acer 640BU). I'd like to see if anyone else is currently working in this area. I must admit I have only looked at version 1.0.3 (not CVS) and only about a months worth of the mailing list archive.
>
> I see three main problems effecting current USB scanners in SANE. First, there is no generic support for USB like there is for SCSI (ie sanei_scsi.c). This means that we can not override these functions to always return failure on platforms that do not support USB. At the least, this should mean that any USB scanner drivers will fail to compile on non-Linux platforms when USB kerenl functions are called.
(disclaimer: Up to now I had never anything to do with USB devices under
Linux, so I might be going to write nosense...) What about to introduce
something like sanei_usb.c ? This way, it would at least be possible to
write dummy functions for other operating systems than Linux. And
perhaps the folks working on *BSD have also done some work for USB
support. Newer Macintoshes have a USB interface, and perhaps somebody
will port Sane to MacOS X.
>
> Next, there needs to be enhanced support in the sanei_config2.c files. They understand a SCSI keyword in config files and will search a /proc directory to find it. The same should be implemented for USB.
>
> Lastly, most of the scanner drivers are SCSI oriented and support placing just a device name in the config like like /dev/scanner. The problem here is that we do not do any error checking inside of scsi open() functions to make sure its actually a SCSI device. We also immediately start doing SCSI related ioctl() calls. Since /dev/scanner is a generic link, on systems with USB scanners we start doing SCSI ioctl()'s during scans to see whats out there. This tends to lock up the current versions of the USB kernel code (well, it takes minutes for it to time out anyways).
Interesting. Without knowing, where exactly and why this time out
occurs, I'd suggest the following:
A better error check in sanei_scsi_open could be done by calling stat(2)
and readlink(2) for "/dev/scanner" (or whichever device file name),
before the device file is actually opened. Another option would be to
extend the "else"-part (line 1175) of the "if (0 == ioctl(fd,
SG_GET_VERSION_NUM, &sg_version))" (line 1105). There, another SG
specific ioctl-call like SG_GET_TIMEOUT could be inserted, just to check
if it is successful: If it is not, the device file should be closed, and
sanei_scsi_open returns an error.
> I'd like to address these 3 issues. Is it OK for me to start hacking the sanei directory or should I discuss some designs with someone?
As already said, I don't know much about USB, I'm just wondering about
the following: If a scanner has fairly similar commands in a USB version
and in a SCSI version, one could think of something roughly similar to
the ide-scsi driver (not necessarily as a kernel module; perhaps
sanei_scsi.c could be modified to support "SCSI over USB". Another
option would be to introduce another layer between the backend and
sanei_scsi.c resp. sanei_usb.c, which simply calls either sanei_scsi_cmd
or sanei_usb_cmd and friends, and which could handle the detection, if a
SCSI or USB scanner is present). This would keep the backend source code
simple.
Abel
-- 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 : Wed Oct 11 2000 - 10:20:26 PDT