On Mon, Oct 12, 1998 at 08:53:41AM -0500, Brian E. Bothwell wrote:
> On Wed, 7 Oct 1998, Bernd Schroeder wrote:
[...]
> > One thing you could try is to call xscanimage directly with
> >
> > xscanimage microtek2:/dev/sgd (this was the device, IIRC)
> >
> > I think, that the frontend then skips the whole sane_get_devices()
> > function, that causes the hang.
> >
> > Bernd
> >
>
>
> I tried that and actually got the scanner to do something!! Yeah!! Turns
> out that "scanimage" causes the hang, but not "xscanimage" (I had being
> soing all the tests when I wasn't in X, so I used "scanimage")
>
> The first time I tried " xscanimage microtek2:/dev/sgd", the Xscanimage
> window came up, I clicked on Scan, an it began to scan, but then stopped
> at about 1/2 way up the page. I then tried a few other settings (12-bit
> grey, getting a preview first, etc) The preview on the 12-bit gray
> completes the full scanner-pass, but seems to crash xscanimage before it
> is done. (All of the *.pnm files it writes to disk are solid black)
>
>
> Here is the tail end of the debug output that might be the real clue as to
> what is wrong:
>
> ------------tons of hex output snipped------------------
> [microtek2] scsi_wait_for_image: ms=0x80faf88
> [microtek2] scsi_read_image_status: ms=0x80faf88
> [microtek2] dump_area2: readimagestatus
> [readimagestatus]
> 28008300600000000000
> [dll] get_parameters(handle=0x80f25b8,params=0x80c2148)
> [microtek2] sane_get_parameters: handle=0x80faf88, params=0x80c2148
> [microtek2] sane_get_parameters: format=1, last_frame=1, lines=1008
> [microtek2] sane_get_parameters: depth=8, ppl=611, bpl=1833
> [dll] set_io_mode(handle=0x80f25b8,nonblocking=1)
> [microtek2] sane_set_io_mode: unsupported
> [dll] read(handle=0x80f25b8,data=0x80ba110,maxlen=32768,lenp=0xbfffedcc)
> [microtek2] sane_read: handle=0x80faf88, buf=0x80ba110, maxlen=32768
> [microtek2] sane_read: transferlength=31212, lines=17, linelength=1836,
> real_bpl=1833, srcbuf=0x811ced8
This looks more or less reasonable. I suspect, that you have still some
SCSI problems. From the backend's point of view, there is no big difference,
whether it is called by scanimage or xscanimage, and the fact that a scan
hangs at different distances also points into this direction.
But even, if a scan succeeds there might be a problem in the backend.
I would have expected, that in this case 'linelength' equals
3 * ppl + 1 = 1834, but it is 1836. The backend skips the first two bytes
of the scanline, so the colors *might* be wrong. This has nothing to do with
the transfer of the data from the scanner, but with the way, how the
backend processes the data.
So you can try to scan only a small portion of the document (to avoid that
the device hangs) and tell us, whether the colors are ok or not.
> I attach a full dump of on of the tests I ran.
These are some lines of this trace:
[setwindowbody]
0000004800480000000000000000000013ec000020d08000800508000080001000000000000000000080ff8080000080ff8080000080ff8080000080ff
[microtek2] scsi_read_image_info: ms=0x80faf88
[microtek2] dump_area2: readimageinfo
[readimageinfo]
28008000000000001000
[microtek2] dump_area2: readimageinforesult
[readimageinforesult]
0000009000000120000000ee0000f8a0
[microtek2] scsi_read_image_info: ppl=144, bpl=288, lines=238, remain=63648
The "set window" command corresponds to a 24-bit color scan with default
settings, but the result of the "read image info" looks like
the leftover settings of a previously interrupted 12-bit grayscale scan.
My experience is, that the initialization of a new scan (with the "set window"
command) is silently ignored, if the previous scan was not finished
or properly aborted (for example, with a cancel). So I am not
surprised, that the backend gets confused in this case.
If you want to conduct some more tests I suggest, that you switch on/off
the scanner every time, as long as these hangs happen, which I suppose
to be SCSI problems.
I am interested to get this model running, so keep me informed.
Bernd
-- Bernd Schroeder Email: mailto:bernd@aquila.muc.de PGP public key available: mailto:pgp@aquila.muc.de | Subject: send key
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com