Hi Chris,
I am all for your proposed changes. I have both a scsi (umax1220s) and a USB
scanner (Agfa snapscan 1212u_2). I don't know if you have read the latest
proposals, but there is a sourceforge site being setup to work on the
snapscan backend. This work involves integrating the usb patch into current
source code in a manner which you describe. Your assistance would be greatly
appreciated. I expect that the announcement of the sourceforge site being
ready will happen some time this week. The intention is to get the snapscan
backend into shape and tested for a variety of scanners so that the code can
be integrated back into the sane source stream.
=======================================================
Lawrence Glaister VE7IT email: lg@jfm.bc.ca
1462 Madrona Drive http://jfm.bc.ca
Nanoose Bay BC Canada
V9P 9C9
=======================================================
----- Original Message -----
From: <cbagwell@sprynet.com>
To: <sane-devel@mostang.com>
Sent: Wednesday, October 11, 2000 8:00 AM
Subject: SANE and general USB support
> 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.
>
> 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).
>
> 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?
>
> Thanks,
> Chris
>
>
> --
> Source code, list archive, and docs: http://www.mostang.com/sane/
> To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
>
-- 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:30:41 PDT