On Tue, Mar 16, 1999 at 06:12:27PM -0800, Warren Early wrote:
> This is a response from a technical person at Microtek. Hopefully this info
> is useful for Bernd. The names were changed to protect the innocent. ;-)
>
> >Hey Wearly,
>
> >The SCSI command set can be downloaded from our ftp site at:
> > ftp://ftp.microtek.com/microtek/devpack
>
> >Don't worry about the fact that the dates are old--this info covers
> >everything up to and including the SM-5. The SCSI command sets >were
> determined way back when.
>
> >One problem XXXX said everyone runs into is in how to read the >color data
> that comes back from the scanner. Each line of data that >comes back is
> preceded by a letter R, G, or B. That first letter tells you >what channel
> the line is for. The scanner does NOT send back one >line of R, one line of
> G, one line of B, etc. The scanner sends back like >20 to 40 lines of red,
> 20 to 40 lines of G, etc. So you have to check >and buffer each line that
> comes back.
I already have this documentation. It defines several formats how the data
is transferred, and I think the format XXX refers to is the format, where
the backend has to cope with the CCD gap.
One of the problems mentioned is that some models have have more bytes
per scanline than expected (i.e. more than 3*pixels_per_line for a color
scan, where the number of pixels per line (ppl) is even). For that format
this is indeed the case because the color indicator is contained in the
number of bytes per line (bpl).
The models, where the problem occurs, however, transfers a scanline as
RGBRGB... And for this format bpl should equal 3*ppl (again: even number
of pixels per line). But actually it is bpl=3*ppl+6 (even number of
pixels per line) and bpl=3*ppl+3 for an odd number of pixels per line.
This is not really a serious problem, but one has to figure out, which
pixels in a line are the relevant ones, and you must let do this other
people, if you don't have such a model.
A more serious problem are the corrupted colors. The symptoms are that one
color scan, after the devices is switched on, produces good results, but
all subsequent color scans are messed up, although the backend implements
a sequence of SCSI commands as recommended in the documentation.
I suppose that, when a scan is finished, the device is left in a somehow
'confused' state and must be reset. One way to reset it is, of course,
to powercycle it. Another way seems to be to do a B/W scan, and this
actually the workaround: to initiate a short B/W scanbefore each scan.
People, who don't know this, are hardly aware of it, but it is at least
annoying, though.
> >Apparently, this method of transfer is the fastest way there is and
> >Microtek holds the patent on it. :-)
>
> >For the EPP stuff, you have to get the info from OnSpec--not even >XXX has
> that info. But it seems unlikely that OnSpec would pass out >that info.
> Apparently, in order to talk to the chip, you either have to >have OnSpec
> develop the driver/backend for you, or you need the >whole source code for
> how they do it on the PC. In explaining how >they do the communications,
> they would be giving away their "trade >secrets" and helping their
> competitors. So you're right; it would be >easier to get OnSpec to write a
> Linux backend than to get them to >show you how.
I think this needs some clarification. One thing is to get a byte stream
transferred over the cable. This is where the type of the chip plays a role,
and , as you wrote earlier, is in case of Linux subject to the Linux parport
project (although SANE is aimed to run on other platforms, too). A driver
for the Onspec chip, how it is used in these scanners, is not yet available.
The other thing is the communication protocol between the host and the
scanner. This is what the documetation for the SCSI commad set provides.
And I am pretty sure, that the same command set can be applied to an
EPP model, where a respective SCSI model exists. But I don't know
whether this command set applies to the Slimscan series, for example,
but I suppose that not.
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