[sane-devel] old Agfa DuoScan / Floating point exception

[Matto Marjanovic]

 >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.