kopia lustrzana https://gitlab.com/sane-project/website
147 wiersze
6.6 KiB
HTML
147 wiersze
6.6 KiB
HTML
<!-- received="Wed Sep 22 04:44:05 1999 PDT" -->
|
||
<!-- sent="22 Sep 1999 13:53:02 +0200" -->
|
||
<!-- name="Camille DIOU" -->
|
||
<!-- email="diou@lirmm.fr" -->
|
||
<!-- subject="Re: ppSCSI and Microtek Phantom 330 CX" -->
|
||
<!-- id="" -->
|
||
<!-- inreplyto="Wed, 22 Sep 1999 12:37:13 +0200"" -->
|
||
<title>sane-devel: Re: ppSCSI and Microtek Phantom 330 CX</title>
|
||
<h1>Re: ppSCSI and Microtek Phantom 330 CX</h1>
|
||
<b>Camille DIOU</b> (<a href="mailto:diou@lirmm.fr"><i>diou@lirmm.fr</i></a>)<br>
|
||
<i>22 Sep 1999 13:53:02 +0200</i>
|
||
<p>
|
||
<ul>
|
||
<li> <b>Messages sorted by:</b> <a href="date.html#137">[ date ]</a><a href="index.html#137">[ thread ]</a><a href="subject.html#137">[ subject ]</a><a href="author.html#137">[ author ]</a>
|
||
<!-- next="start" -->
|
||
<li> <b>Next message:</b> <a href="0138.html">John Stoffel: "Re: gimp and xsane"</a>
|
||
<li> <b>Previous message:</b> <a href="0136.html">Bernd Schroeder: "Re: ppSCSI and Microtek Phantom 330 CX"</a>
|
||
<li> <b>In reply to:</b> <a href="0136.html">Bernd Schroeder: "Re: ppSCSI and Microtek Phantom 330 CX"</a>
|
||
<!-- nextthread="start" -->
|
||
<!-- reply="end" -->
|
||
</ul>
|
||
<!-- body="start" -->
|
||
Hi Bernd,<br>
|
||
<p>
|
||
* "BS" == Bernd Schroeder écrivait le Wed, 22 Sep 1999 12:37:13 +0200:<br>
|
||
<p>
|
||
onscsi.1: Arbitration failure, bs=31 cb=0 [...cut...]<br>
|
||
<p>
|
||
BS> Even if the 'no-backtrack-option' is set it is possible that<br>
|
||
BS> the scanner stops and starts, but should not move back. Here it<br>
|
||
BS> looks as if one or more buffers are read, but then the device<br>
|
||
BS> fails to read another buffer. I don't know what the error<br>
|
||
BS> messages mean, but it looks like a problem with the ppSCSI<br>
|
||
BS> stuff. Maybe you should ask on the linux-parport mailinglist.<br>
|
||
<p>
|
||
The 'arbitration failure' error message also arise when I turn off the <br>
|
||
scanner while scanning. Maybe a communication problem between the<br>
|
||
module and the hardware. I'll try the parport mailing-list.<br>
|
||
<p>
|
||
I forgot something: scanimage seems to work with lineart mode.<br>
|
||
<p>
|
||
<i> >> Is there any way to avoid the head hitting the borders of the</i><br>
|
||
<i> >> scanner? (I didn't find any solution in the archive since Juny).</i><br>
|
||
<p>
|
||
BS> For some reason the device doesn't find the zero position. I<br>
|
||
BS> think that if a preview scan is done it tries to scan an A4<br>
|
||
BS> sized image, but because a number of lines are missing at the<br>
|
||
BS> beginning it tries to scan beyond the bottom of the scan<br>
|
||
BS> area. If this is the case it should at least work better, if<br>
|
||
BS> you do a normal scan, but don't specify the whole scan area.<br>
|
||
<p>
|
||
That's right.<br>
|
||
<p>
|
||
BS> There is one SCSI command that sets all the parameters for a<br>
|
||
BS> scan - including the scan area - and these are set correctly,<br>
|
||
BS> so it should start at position 0.<br>
|
||
<p>
|
||
I tried the -t -b -x -y options to define the scan area without<br>
|
||
success. I got an error message concerning the --br-c (sorry but I<br>
|
||
don't remember it exactly).<br>
|
||
<p>
|
||
BS> One thing you can try is: Set the still experimental and<br>
|
||
BS> undocumented 'option backend-calibration on' in the<br>
|
||
BS> microtek2.conf file, if it exists in your version. Otherwise<br>
|
||
BS> download a newer version from<br>
|
||
BS> <a href="ftp://ftp.muc.de/people/bernds/mtek2">ftp://ftp.muc.de/people/bernds/mtek2</a>.<br>
|
||
<p>
|
||
I'll try that.<br>
|
||
<p>
|
||
BS> If this option is set this will enable an additional option in<br>
|
||
BS> the frontend (Calibration by backend). If this option is<br>
|
||
BS> checked the backend instead of the device will do a colour<br>
|
||
BS> calibration at the beginning of a scan. This will involve some<br>
|
||
BS> additional commands to position the scan head. I don't know if<br>
|
||
BS> it helps, but I think it's worth a try.<br>
|
||
<p>
|
||
BS> When the scan head returns to its home position after a scan<br>
|
||
BS> the backend it not involved at all. After the last buffer has<br>
|
||
BS> been read the head moves back automatically, and there is no<br>
|
||
BS> command to position it.<br>
|
||
<p>
|
||
I tested the scanner with the -T option. What I got is:<br>
|
||
<p>
|
||
scanimage: scanning image of size 612x838 pixels at 24 bits/pixel<br>
|
||
scanimage: acquiring RGB frame, 8 bits/sample<br>
|
||
scanimage: reading one scanline, 1836 bytes... PASS<br>
|
||
scanimage: reading one byte... PASS<br>
|
||
scanimage: stepped read, 2 bytes... PASS<br>
|
||
scanimage: stepped read, 4 bytes... PASS<br>
|
||
scanimage: stepped read, 8 bytes... PASS<br>
|
||
scanimage: stepped read, 16 bytes... PASS<br>
|
||
scanimage: stepped read, 32 bytes... PASS<br>
|
||
scanimage: stepped read, 64 bytes... PASS<br>
|
||
scanimage: stepped read, 128 bytes... PASS<br>
|
||
scanimage: stepped read, 256 bytes... PASS<br>
|
||
scanimage: stepped read, 512 bytes... PASS<br>
|
||
scanimage: stepped read, 1024 bytes... PASS<br>
|
||
scanimage: stepped read, 2048 bytes... PASS<br>
|
||
scanimage: stepped read, 2047 bytes... PASS<br>
|
||
scanimage: stepped read, 1023 bytes... PASS<br>
|
||
scanimage: stepped read, 511 bytes... PASS<br>
|
||
scanimage: stepped read, 255 bytes... PASS<br>
|
||
scanimage: stepped read, 127 bytes... PASS<br>
|
||
scanimage: stepped read, 63 bytes... PASS<br>
|
||
scanimage: stepped read, 31 bytes... PASS<br>
|
||
scanimage: stepped read, 15 bytes... PASS<br>
|
||
scanimage: stepped read, 7 bytes... PASS<br>
|
||
scanimage: stepped read, 3 bytes... PASS<br>
|
||
[root@localhost sane-1.0.1]# scanimage: stopping scanner...<br>
|
||
scanimage: stopping scanner...<br>
|
||
scanimage: stopping scanner...<br>
|
||
scanimage: stopping scanner...<br>
|
||
<p>
|
||
.. and so on: the scanner never stop.<br>
|
||
<p>
|
||
This results and the head position problem let me think that it acts<br>
|
||
as if the generic scsi commands were recognized by the ppSCSI module,<br>
|
||
but not the hardware specific ones. Perhaps a problem with the onSCSI<br>
|
||
module (but I could be wrong, as I don't know the scsi<br>
|
||
interface/protocol at all). <br>
|
||
<p>
|
||
That's all for now. Thank you for your help.<br>
|
||
Bye<br>
|
||
<p>
|
||
<pre>
|
||
--
|
||
Regards,
|
||
<p>
|
||
Camille Diou
|
||
<p>
|
||
<p>
|
||
<pre>
|
||
--
|
||
Source code, list archive, and docs: <a href="http://www.mostang.com/sane/">http://www.mostang.com/sane/</a>
|
||
To unsubscribe: echo unsubscribe sane-devel | mail <a href="mailto:majordomo@mostang.com">majordomo@mostang.com</a>
|
||
</pre>
|
||
<!-- body="end" -->
|
||
<p>
|
||
<ul>
|
||
<!-- next="start" -->
|
||
<li> <b>Next message:</b> <a href="0138.html">John Stoffel: "Re: gimp and xsane"</a>
|
||
<li> <b>Previous message:</b> <a href="0136.html">Bernd Schroeder: "Re: ppSCSI and Microtek Phantom 330 CX"</a>
|
||
<li> <b>In reply to:</b> <a href="0136.html">Bernd Schroeder: "Re: ppSCSI and Microtek Phantom 330 CX"</a>
|
||
<!-- nextthread="start" -->
|
||
<!-- reply="end" -->
|
||
</ul>
|