> Yuri Dario, author of the SANE-OS2 port, has asked me to post this
>problem-report here. We're aware that "microtek" backend problems with the
>E3 were fixed in the Linux distribution almost a year ago, but for reasons
>unclear, the OS/2 ports of SANE version 1.01 (as well as 0.72 and 0.74)
>continue unable to drive the E3:
> (1) After a short precal dance, the E3 quits instead of scanning
> and yet,
> (2)[YD]> Looking at code, there aren't OS/2 specific patches to the
> [microtek] backend.
>...................
> The E3 makes a series of short, slow-speed moves, then a brief,
>high-pitch whine (fast return to home postion, following precal?)
>Immediately after that short move, SCANIMAGE fails with a "Device I/O
>error".
> ....
With sane_debug_sanei_scsi=32 and sane_debug_microtek=32, the E3 failure
occurs after precalibration:
>[microtek] do_precalibrate done.
>[microtek] .scanning_frame...
>[microtek] .scanning_frame: in- 0,0 1181,1181
>[microtek] .scanning_frame: out- 0,0 1181,1181
>[microtek] .accessory...
>[microtek] .download_gamma...
>[microtek] .mode_select 0...
>[microtek] .mode_select: pap_len: 3505
>[microtek] .mode_select_1 0...
>[microtek] .save_mode_sense 0...
>[microtek] .wait_ready 0...
>[microtek] .start_scan...
>[sanei_scsi] sanei_scsi_cmd: command 0x1b failed.
>[microtek] end_scan...
>[microtek] .stop_scan...
>[sanei_scsi] sanei_scsi_cmd: command 0x1b failed.
>[microtek] end_scan: OY! on stop_scan
>[sanei_scsi] OS/2: ASPI closed
>scanimage: sane_start: Error during device I/O
>[microtek] sane_cancel...
>[microtek] end_scan...
>[microtek] sane_close...
>[microtek] sane_exit...
>[microtek] sane_exit: MICROTEK says goodbye.
Besides SANE, I also have Jan Schonepauck's "mtekscan" (Microtek only, last
updated 1997 AFAIK) While browsing through that documentation, I recently
noticed a comment to the effect that the start- or stop-scan command had
needed some "timeout-tweaking" before (mistakenly) declaring it failed.
From earlier exploration of this list's archives, I'm also aware that in
porting SANE to OS/2, Yuri had to contend with subtle differences between the
UNix/Linux thread model and that of OS/2.
I'm probably grasping at straws here, but is it conceivable that seemingly
identical backend code might show different _timing_ characteristics when
executed under OS/2 (multi-threaded, but lacking fork() ), as opposed to
running on the same x86 box under Linux?
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com