Linux Sense buffer (was: sane 0.71 and microtek E3)

Sean Reifschneider (jafo@tummy.com)
Sun, 29 Mar 1998 16:36:45 -0700

I've finally gotten a chance to even LOOK at SANE. I ran into the
discussion of the Microtek scanners not working with the latest
versions of SANE. There was speculation that it was a problem with
the AHA drivers. I loaded it and tried it here and found that my
NCR 53c8xx and DPT controllers were doing the same thing.

I sent a query to Leonard Zubkoff asking for his opinion, and he
says that the code appears to work that way. I haven't had a chance
to try it with the BusLogic drivers that he authors yet though. It
looks like the:

if (req->cdb.hdr.result == 0 && (req->cdb.hdr.sense_buffer[0] & 0x7f) == 0)

needs to be changed to:

if (req->cdb.hdr.result == 0)

for SANE to work on NCR, DPT, and some AHA systems.

Also, are most SANE folks working with the SG_BIG_BUFF increased from the
stock size? I found that if I scan something in higher resolution that
SANE core dumps. I tracked it down to a segement where it's reading from
the device and it looks like the buffer is being over-blown. I hope to
track this down and have a fix for it over the next couple of weeks.

I did some testing a few years ago, and didn't really notice any performance
improvement between the stock buffer and the max size. It didn't take too
long before I realized that I was wasting more time with building new
kernels and other dorking around, than I was *EVER* going to save in scan
times. Also, since there's no real way to query the buffer size from the
software (that I found at that time anyway), doing "production builds" with
a bigger buffer just would mean that it would crash on most users systems.

In the last 3 years and hundreds of copies of our software on Linux, I don't
recall even ONE complaint about the scanning speed.

An even less important consideration is our "status bar". We have one of
those progress meters during scanning. Using the larger buffer resulted
in a much less pretty (and useful :-) updating of the meter since I update
it after each read.

Anyway, that's my two cents worth...

Enjoy,
Sean

-- 
 "Sometimes Omaha can't be avoided."
                 -- Howard Borden the navigator, Bob Newhart Show
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
URL: <http://www.tummy.com/xvscan> HP-UX/Linux/FreeBSD/BSDOS scanning software.



--
Source code, list archive, and docs: http://www.mostang.com/sane/
To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com