It's me again (the guy with the Acer 320U ;-). I've been hunting through the
code, trying to see if I can something that might help me, and I ran across
something interesting. I don't think it has anything to do with my particular
problem, but I thought I'd pass it along...
When I run xscanimage with SANE_DEBUG_SNAPSCAN set to 255, this is a bit of
the output I get:
[snapscan] inquiry: pixels per scan line = 308
[snapscan] inquiry: bytes per scan line = 924
[snapscan] inquiry: number of scan lines = 256
[snapscan] inquiry: effective buffer size = 31416 bytes, 122 lines
[snapscan] inquiry: expected total scan data: 236544 bytes
If the effective buffer size is 31416 bytes and there are 924 bytes per line
shouldn't the buffer be 34 lines, not 122? I looked at the code in
snapscan-scsi.c and the lines that produce this output (starting at 441) are:
"%s: effective buffer size = %lu bytes, %lu lines\n",
(u_long) (pss->buf_sz ? pss->buf_sz / pss->lines : 0));
It looks like the number of lines in the buffer is being calculated by
dividing the effective buffer size by the number of lines in the scan instead
of by the number of bytes in a line (i.e. pss->bytes_per_line).
Unless of course the numbers are correct and the labels are ambiguous?
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail email@example.com
This archive was generated by hypermail 2b29 : Sat Dec 09 2000 - 19:59:08 PST