kopia lustrzana https://gitlab.com/sane-project/website
176 wiersze
9.6 KiB
HTML
176 wiersze
9.6 KiB
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>> </i><br>
|
||
<i>> On Fri, 20 Nov 1998 00:31:31 +0100, Bernd Schroeder wrote:</i><br>
|
||
<i>> ></i><br>
|
||
<i>> > This sounds indeed strange. Normally the scanner should be in reset state </i><br>
|
||
<i>> > after it is switched on. Or are the colors wrong if the scanner is switched</i><br>
|
||
<i>> > on before the system is booted (or the SCSI driver is loaded) ? Then</i><br>
|
||
<i>> > the SCSI driver sends one or more commands to the device, but these</i><br>
|
||
<i>> > commands should not affect the results of a scan.</i><br>
|
||
<i>> </i><br>
|
||
<i>> I tried every computer/scanner power-up sequence I could think of :-)</i><br>
|
||
<i>> I also tried loading/unloading the SCSI driver, but the problem occurs</i><br>
|
||
<i>> every time. It doesn't seem to be related to SCSI, since it occurs on</i><br>
|
||
<i>> both the Adaptec AVA-1505 host adapter (supplied with the scanner)</i><br>
|
||
<i>> 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>> </i><br>
|
||
<i>> [...] </i><br>
|
||
<i>> > > I fixed it anyway to prevent potential problems: The scanner seems</i><br>
|
||
<i>> > > to come up with random values for the NTRACK and NCALIB bits in</i><br>
|
||
<i>> > > the system status. The fix (included in the patch below) was to</i><br>
|
||
<i>> > > explicitly set these bits to zero in sane_start().</i><br>
|
||
<i>> > </i><br>
|
||
<i>> > NCALIB set to 1 prevents the scanner from calibration before a scan.</i><br>
|
||
<i>> > This is explicitly set (and later reset) in the do_dummy_scan()-function.</i><br>
|
||
<i>> > Please check, whether the differences for this bit result from these</i><br>
|
||
<i>> > different settings.</i><br>
|
||
<i>> </i><br>
|
||
<i>> Note that my patch places the call to do_dummy_scan() (and therefore</i><br>
|
||
<i>> the call to scsi_send_diagnostic()) in sane_start() before the call</i><br>
|
||
<i>> to scsi_send_system_status(). I did this because I'm not sure whether</i><br>
|
||
<i>> the system status is preserved across a self test. Therefore I need</i><br>
|
||
<i>> to set NTRACK and NCALIB in sane_start().</i><br>
|
||
<i>> </i><br>
|
||
<i>> [...]</i><br>
|
||
<i>> > I experimented with this command myself a while ago as a replacement for</i><br>
|
||
<i>> > this "do_dummy_scan" stuff, but it has some disadvantages.</i><br>
|
||
<i>> > </i><br>
|
||
<i>> > In particular this command is used for every scan if scanimage is used, and</i><br>
|
||
<i>> > as you wrote the execution of this command takes some time. On my</i><br>
|
||
<i>> > own ScanMaker 630 every second "send diagnostics" fails, BTW, with</i><br>
|
||
<i>> > sense code "lamp failure" :/ .</i><br>
|
||
<i>> </i><br>
|
||
<i>> :-/ ... well, this bug doesn't occur on my scanner.</i><br>
|
||
<i>> </i><br>
|
||
<i>> Yes, this "send diagnostics" command is annoying, because it keeps</i><br>
|
||
<i>> the scanner busy for a rather long time. This is the reason for the</i><br>
|
||
<i>> did_self_test flag in my patch. Of course, this flag doesn't help</i><br>
|
||
<i>> with scanimage. On the other hand, my patch shouldn't affect your</i><br>
|
||
<i>> 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>> > I suggest not to include this patch into sane-1.00, but to remove the</i><br>
|
||
<i>> > NTRACK and NCALIB changes, and also to introduce an option in the</i><br>
|
||
<i>> > configuration file to enable/disable the "send diagnostics" command</i><br>
|
||
<i>> > (but in a later release of the backend).</i><br>
|
||
<i>> > </i><br>
|
||
<i>> > Bernd</i><br>
|
||
<i>> </i><br>
|
||
<i>> It would be sufficient to issue the "send diagnostics" command just</i><br>
|
||
<i>> once after switching on the scanner. But I didn't find a way to</i><br>
|
||
<i>> determine in software whether the scanner acts weirdly or not --</i><br>
|
||
<i>> 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>> As an alternative, I could write a small stand-alone program that</i><br>
|
||
<i>> just issues a "send diagnostics" command. But such a program would</i><br>
|
||
<i>> duplicate a lot of functionality of the SANE microtek2 backend and</i><br>
|
||
<i>> the SCSI layer. Yet another alternative would be an option settable</i><br>
|
||
<i>> via sane_control_option(). But those alternatives would all require</i><br>
|
||
<i>> user intervention.</i><br>
|
||
<i>> </i><br>
|
||
<i>> If you like, I could go ahead and implement the configuration file</i><br>
|
||
<i>> option as per your suggestion. I think a similar option to control</i><br>
|
||
<i>> 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>
|