sane-project-website/old-archive/1998-11/0182.html

<!-- received="Sat Nov 21 08:56:57 1998 PST" -->
<!-- sent="Sat, 21 Nov 1998 17:24:57 +0100" -->
<!-- name="Bernd Schroeder" -->
<!-- email="bernd@aquila.muc.de" -->
<!-- subject="Re: Patch for Microtek ScanMaker X6 (microtek2 backend)" -->
<!-- id="" -->
<!-- inreplyto="199811201241.NAA19923@elephant.cs.tu-berlin.de" -->
<title>sane-devel: Re: Patch for Microtek ScanMaker X6 (microtek2 backend)</title>
<h1>Re: Patch for Microtek ScanMaker X6 (microtek2 backend)</h1>
<b>Bernd Schroeder</b> (<a href="mailto:bernd@aquila.muc.de"><i>bernd@aquila.muc.de</i></a>)<br>
<i>Sat, 21 Nov 1998 17:24:57 +0100</i>
<p>
<ul>
<li> <b>Messages sorted by:</b> <a href="date.html#182">[ date ]</a><a href="index.html#182">[ thread ]</a><a href="subject.html#182">[ subject ]</a><a href="author.html#182">[ author ]</a>
<!-- next="start" -->
<li> <b>Next message:</b> <a href="0183.html">Bernd Schroeder: "Re: Patch for Microtek ScanMaker X6 (microtek2 backend)"</a>
<li> <b>Previous message:</b> <a href="0181.html">Dieter Lange: "Re: Primax scanner"</a>
<li> <b>In reply to:</b> <a href="0176.html">Sebastian Erdmann: "Re: Patch for Microtek ScanMaker X6 (microtek2 backend)"</a>
<!-- nextthread="start" -->
<!-- reply="end" -->
</ul>
<!-- body="start" -->
Hi,<br>
<p>
On Fri, Nov 20, 1998 at 01:41:21PM +0100, Sebastian Erdmann wrote:<br>
<i>&gt; </i><br>
<i>&gt; On Fri, 20 Nov 1998 00:31:31 +0100, Bernd Schroeder wrote:</i><br>
<i>&gt; &gt;</i><br>
<i>&gt; &gt; This sounds indeed strange. Normally the scanner should be in reset state </i><br>
<i>&gt; &gt; after it is switched on. Or are the colors wrong if the scanner is switched</i><br>
<i>&gt; &gt; on before the system is booted (or the SCSI driver is loaded) ? Then</i><br>
<i>&gt; &gt; the SCSI driver sends one or more commands to the device, but these</i><br>
<i>&gt; &gt; commands should not affect the results of a scan.</i><br>
<i>&gt; </i><br>
<i>&gt; I tried every computer/scanner power-up sequence I could think of :-)</i><br>
<i>&gt; I also tried loading/unloading the SCSI driver, but the problem occurs</i><br>
<i>&gt; every time. It doesn't seem to be related to SCSI, since it occurs on</i><br>
<i>&gt; both the Adaptec AVA-1505 host adapter (supplied with the scanner)</i><br>
<i>&gt; and my NCR 53C810 controller.</i><br>
<p>
But I still don't understand why the device doesn't work after it is<br>
powered on, and then works better, if it switched off an on again.<br>
<p>
<i>&gt; </i><br>
<i>&gt; [...] </i><br>
<i>&gt; &gt; &gt; I fixed it anyway to prevent potential problems: The scanner seems</i><br>
<i>&gt; &gt; &gt; to come up with random values for the NTRACK and NCALIB bits in</i><br>
<i>&gt; &gt; &gt; the system status. The fix (included in the patch below) was to</i><br>
<i>&gt; &gt; &gt; explicitly set these bits to zero in sane_start().</i><br>
<i>&gt; &gt; </i><br>
<i>&gt; &gt; NCALIB set to 1 prevents the scanner from calibration before a scan.</i><br>
<i>&gt; &gt; This is explicitly set (and later reset) in the do_dummy_scan()-function.</i><br>
<i>&gt; &gt; Please check, whether the differences for this bit result from these</i><br>
<i>&gt; &gt; different settings.</i><br>
<i>&gt; </i><br>
<i>&gt; Note that my patch places the call to do_dummy_scan() (and therefore</i><br>
<i>&gt; the call to scsi_send_diagnostic()) in sane_start() before the call</i><br>
<i>&gt; to scsi_send_system_status(). I did this because I'm not sure whether</i><br>
<i>&gt; the system status is preserved across a self test. Therefore I need</i><br>
<i>&gt; to set NTRACK and NCALIB in sane_start().</i><br>
<i>&gt; </i><br>
<i>&gt; [...]</i><br>
<i>&gt; &gt; I experimented with this command myself a while ago as a replacement for</i><br>
<i>&gt; &gt; this "do_dummy_scan" stuff, but it has some disadvantages.</i><br>
<i>&gt; &gt; </i><br>
<i>&gt; &gt; In particular this command is used for every scan if scanimage is used, and</i><br>
<i>&gt; &gt; as you wrote the execution of this command takes some time. On my</i><br>
<i>&gt; &gt; own ScanMaker 630 every second "send diagnostics" fails, BTW, with</i><br>
<i>&gt; &gt; sense code "lamp failure" :/ .</i><br>
<i>&gt; </i><br>
<i>&gt; :-/ ... well, this bug doesn't occur on my scanner.</i><br>
<i>&gt;  </i><br>
<i>&gt; Yes, this "send diagnostics" command is annoying, because it keeps</i><br>
<i>&gt; the scanner busy for a rather long time. This is the reason for the</i><br>
<i>&gt; did_self_test flag in my patch. Of course, this flag doesn't help</i><br>
<i>&gt; with scanimage. On the other hand, my patch shouldn't affect your</i><br>
<i>&gt; ScanMaker 630, because do_dummy_scan() returns early for this model.</i><br>
<p>
Not in that version of the backend, but in the one I am actually<br>
working on :) . Some ScanMaker 630 have a similar problem in that the<br>
colors are wrong in color scans after a lineart scan (mainly an inverted<br>
green channel), and this can be cured in a similar way.<br>
<p>
The reason why I am somewhat sceptical about this "send diagnostics" is<br>
that I think it is an overkill to introduce a command that costs a lot<br>
of time and additional movements of the scan head (and may have side effects)<br>
to work around a problem, that occurs only once after the scanner is powered<br>
on.<br>
<p>
<i>&gt; &gt; I suggest not to include this patch into sane-1.00, but to remove the</i><br>
<i>&gt; &gt; NTRACK and NCALIB changes, and also to introduce an option in the</i><br>
<i>&gt; &gt; configuration file to enable/disable the "send diagnostics" command</i><br>
<i>&gt; &gt; (but in a later release of the backend).</i><br>
<i>&gt; &gt; </i><br>
<i>&gt; &gt; Bernd</i><br>
<i>&gt; </i><br>
<i>&gt; It would be sufficient to issue the "send diagnostics" command just</i><br>
<i>&gt; once after switching on the scanner. But I didn't find a way to</i><br>
<i>&gt; determine in software whether the scanner acts weirdly or not --</i><br>
<i>&gt; the only method seems to be to manually inspect a scanned image.</i><br>
<p>
Yes, that seems to be a problem. I, too, didn't find a way to reliably <br>
recognize, whether the next scan will produce garbage.<br>
<p>
<i>&gt; As an alternative, I could write a small stand-alone program that</i><br>
<i>&gt; just issues a "send diagnostics" command. But such a program would</i><br>
<i>&gt; duplicate a lot of functionality of the SANE microtek2 backend and</i><br>
<i>&gt; the SCSI layer. Yet another alternative would be an option settable</i><br>
<i>&gt; via sane_control_option(). But those alternatives would all require</i><br>
<i>&gt; user intervention.</i><br>
<i>&gt; </i><br>
<i>&gt; If you like, I could go ahead and implement the configuration file</i><br>
<i>&gt; option as per your suggestion. I think a similar option to control</i><br>
<i>&gt; do_dummy_scan would also be useful.</i><br>
<p>
I think, that this is the best method to introduce a switches into the<br>
backend (one for the do_dummy_scan and another for the "power on"<br>
problem).<br>
<p>
The next release will have an option "disable backtracking", and it can<br>
be configured in the configuration file, whether this option will be<br>
visible in the frontend or not. If not it is set to a default value.<br>
Some other less important options will follow (bind resolution is another<br>
candidate). The purpose is to have less active options in order to reduce<br>
the height of the xscanimage window, because on small screens and with<br>
low resolutions xscanimage exceeds the size of the screen.<br>
<p>
So something like 'option fix-thisorthatproblem on/off'<br>
in the configuration file, that activates/deactivates a respective<br>
boolean option in the frontend might indeed be useful (one for each problem).<br>
But I strongly recommend to set the default value for this<br>
"send diagnostics" to "off" (and never activate it if it is not an X6) :) .<br>
<p>
Unfortunately I can't provide a current version of the backend, which<br>
actually works, because I am about to include support for non-blocking<br>
IO's. This will simplify a lot of things, but unfortunately it also affects<br>
large parts of the code.<br>
<p>
Of course, the best solution would be to know how the Windows software<br>
handles theses sorts of problems. I contacted Microtek once about two<br>
months ago via email because of this problem, that the colors are<br>
wrong after one successful color or grayscale scan, and actually got<br>
a response, but this response was - mildly said - not very exhaustive.<br>
But I am planning to present them a list with problems once again.<br>
<p>
Another way would be to trace the SCSI commands of the Windows software<br>
(under wine, for example). I tried this, too, but didn't manage to get<br>
the Scanwizard or even a simple test application running under wine.<br>
<p>
It looks as if you have the documentation, so if iyou discover anything that<br>
explains, why these problems occur, please let me know.<br>
<p>
Bernd<br>
 <br>
<pre>
-- 
Bernd Schroeder 
Email: <a href="mailto:bernd@aquila.muc.de">mailto:bernd@aquila.muc.de</a>
PGP public key available: <a href="mailto:pgp@aquila.muc.de">mailto:pgp@aquila.muc.de</a> | Subject: send key 
<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="0183.html">Bernd Schroeder: "Re: Patch for Microtek ScanMaker X6 (microtek2 backend)"</a>
<li> <b>Previous message:</b> <a href="0181.html">Dieter Lange: "Re: Primax scanner"</a>
<li> <b>In reply to:</b> <a href="0176.html">Sebastian Erdmann: "Re: Patch for Microtek ScanMaker X6 (microtek2 backend)"</a>
<!-- nextthread="start" -->
<!-- reply="end" -->
</ul>