Nathan J. Williams writes:
 > Well, it's duplicating what ugen does. The man page for uscanner(4)
 > says that it's for compatibility with a Linux driver, but the Linux
 > folks punted it ages ago (and it's been suggested that we follow
 > along). So I would suggest not putting more resources into anything
 > but ensuring that we can punt it as well. One such resource would be
 > using your scanner with ugen(4) instead uscanner(4) and confirming
 > that it works.

Yes, there are two drivers that purport to do the same thing.  In
fact, though, I started by trying ugen and libusb.  That does not work
for this scanner.  For more details, see my recent posts to the SANE
mailing list.  Indeed, there has been a long discussion on the libusb
mailing list about various issues with timeouts and so on.  The
problem I had with ugen/libusb was that the communication protocol
would not complete due to timeouts.  Thus, I think this issue is
rather fundamental to libusb and may not get resolved soon, as no
clear solution is emerging.

In contrast, using the uscanner driver directly works fine.  The
scanner is detected, SANE can identify the scanner (with the ioctl I
implemented), all the communication with the scanner works fine, and I
can make scans successfully.  This is currently not functionality that
is available via the ugen/libusb interface, nor is it likely to be
available via that route anytime soon.

Chris Ross writes:
 >    Cool.  Fair enough.  If the hope/plan is to punt that driver,
 > than I agree nothing else should be added to it to continue
 > it's use...

So how is someone supposed to use scanners that do not work with the
ugen/libusb combination?

I appreciate your desire to streamline the set of drivers that are
available.  On the other hand, we have a driver that works and I am
suggesting the most minor addition.  Indeed, the ability to obtain
information about what device the driver is servicing seems like a
fundamental prerequisite for _any_ driver, regardless of its long-term
fate.

Furthermore, this is not a dead driver.  As recently as a few months
ago support for more scanners was added, and there is a long history
of development to the code.  This suggests that there is interest in
the driver not going away immediately.

Overall, then, it seems that this would be a valuable addition to the
uscanner driver.  I hope others come to feel the same way and will
commit the added ioctl support.

Thank you very much.

Cheers,
Brook