>Am Montag, 17. April 2006 12:18 schrieb Frank Zago:
>
>> Before changing the code, set SANE_DEBUG_MICROTEK to 128 (type "export
>> SANE_DEBUG_MICROTEK=128" under your shell) and redo your test. That will
>> give more information.
>> In particular get_scan_status() doesn't seems to return the correct
>> information, which leads to linewidth being 0.
>>
>> Frank.
>
>that didn't change anything. Typing the export command (in the console after
>"su -l root") didn't produce any answer, I guess that's how it should be (?).
>Then typing "scanimage --device-name=microtek:/dev/sg0" produced the same
>list as before. Also the crash-messages after trying Kooka (in a root
>session) have been the same (compared last one to the new one with KDiff3,
>same text, same number of lines, only the thread number and some Hex-numbers
>in the lines with the ??'s are different (saved it, in case you still want to
>see it).
>
>Is it possible that I first need to install some "debug package" or something?
Hiya,
First off... I must admit it has been a while since I have played with this
code! (My "Microtek E6" has been boxed for a few years due to several
moves; hopefully I'll get a chance to set it up again soon.)
Ah... I think there is a little bug preventing you from getting more
debugging output --- fixing it will require modifying the code and
recompiling the backend.
In this block in the function id_microtek():
if (forcewarn) {
/* force debugging on, to encourage user to send in a report */
#ifndef NDEBUG
DBG_LEVEL = 1;
#endif
The "DBG_LEVEL = 1;" line should be changed to:
if (DBG_LEVEL < 1)
DBG_LEVEL = 1;
(This little-exercised codepath is reseting the debugging level back
to 1 when it prints your "Congratualations" message.)
Once that is done, as before, set the SANE_DEBUG_MICROTEK variable in
the shell's environment before running any tests. (No debug package
should be necessary.) How one sets the variable depends on the
shell:
For sh shells: > export SANE_DEBUG_MICROTEK=128
For csh shells: > setenv SANE_DEBUG_MICROTEK 128
You can then test the value by executing "echo $SANE_DEBUG_MICROTEK".
The shell should print out "128".
In fact, I'd say, set this to 255 instead of 128.
And, set SANE_DEBUG_SANEI_SCSI to 255 as well. This will cause the SCSI
traffic to be dumped as well. (This would be overwhelming if the scan
were in progress, but we're not quite that far yet.)
The problem (from the current evidence) is that get_scan_status() is not
returning a valid "bytes_per_line" value. This may just be a quirk of
the scanner firmware, or it could be some weird SCSI problem, etc.
The debugging info will reveal more clues as to how this is failing.
Oh, quirky, quirky firmware,
-matt m.
PS: The microtek-class of firmware probably isn't much quirkier than
any other. Why are so many device API's deigned "proprietary"?
Why won't device manufacturers publish their API's? As anyone
who has written device drivers will know, it's not because they
are trying to protect their "intellectual property". It is
usually a combination of:
a) having no documentation whatsoever to begin with;
b) old-fashioned fear of embarrassment.
