[sane-devel] [PATCH] make scanimage work with HP ScanJet (HP 6250C), finally

[m. allan noah]

i can confirm that this does help problems i have seen with the 6200C.
now the device is very consistent- it shows up and works the first,
third, fifth, etc times that i use it. but every 'even' call to Xsane
produces the following:

[hp] hp_AddOpenDevice: added device libusb:002:003 with fd=1
[hp] scl_inq: read failed (End of file reached)
[hp] scl_errcheck: Can't read SCL error stack: End of file reached
[hp] hp_nonscsi_device_new: SCL reset failed
[hp] scsi_close: closing fd 1
[hp] scsi_close: really closed

and xsane gives the 'no devices found' dialog. i have tried increasing
the sleep, but to no avail.

i have cc'd the backend author for comments. thanks for your efforts Jim!

allan

On 3/17/08, Jim Meyering <jim at meyering.net> wrote:
> This bug has been reported before, e.g.,
>   http://bugzilla.redhat.com/413471
>   http://bugs.debian.org/116962
>   https://bugs.launchpad.net/ubuntu/+source/sane-backends/+bug/119819
>
>  For years, scanimage/xsane has worked only sporadically with my
>  USB-connected HP 6250C.  I'd have to run it 3 or 4 times (sometimes
>  changing USB plug, when one would get "stuck") in order to get a single scan.
>  That was frustrating.  Often, it'd fail like this:
>
>   $ scanimage
>   scanimage: hp-option.c:3713: hp_optset_fix_geometry_options: Assertion `tl_x && tl_y && br_x && br_y' failed.
>   zsh: abort      scanimage
>   [Exit 134 (ABRT)]
>
>  [debug output attached below]
>
>  I get the same behavior with fedora rawhide and debian unstable.
>
>  Debugging showed that the primary problem lies in detecting supported
>  options.  During one run, it would fail to detect an option that I
>  knew to be valid and essential, like the one corresponding to tl_x
>  above), and during the next run, it *would* detect that same option.
>
>  The problematic code is in hp-scl.c's _hp_scl_inq function.
>  The issue-command call there is followed immediately by the "read
>  result" call:
>
>   RETURN_IF_FAIL( hp_scsi_scl(scsi, inq_cmnd, SCL_INQ_ID(scl)) );
>   status =  hp_scsi_read(scsi, buf, &bufsize, 1);
>
>  It looks like sometimes the device responds quickly enough,
>  and the attribute is detected.  Other times, is too slow and
>  sane reports that the attribute is not supported.
>
>  I found that inserting a 1ms delay between those two lines made everything
>  "just-work".  FYI, a .5ms delay appeared to work just as well (I ran
>  only 2 or 3 trials, and all succeeded), but my single trial with a .1ms
>  delay provoked the usual failed assertion.
>
>  There is probably a much cleaner way to wait until the data is ready,
>  but I'll let someone else investigate that.  Here's my patch:
>
>  Index: backend/hp-scl.c
>  ===================================================================
>  RCS file: /cvsroot/sane/sane-backends/backend/hp-scl.c,v
>  retrieving revision 1.14
>  diff -u -p -r1.14 hp-scl.c
>  --- backend/hp-scl.c    4 Oct 2004 18:09:05 -0000       1.14
>  +++ backend/hp-scl.c    17 Mar 2008 09:29:30 -0000
>  @@ -1763,6 +1763,7 @@ _hp_scl_inq (HpScsi scsi, HpScl scl, HpS
>    RETURN_IF_FAIL( hp_scsi_flush (scsi)) ;
>
>    RETURN_IF_FAIL( hp_scsi_scl(scsi, inq_cmnd, SCL_INQ_ID(scl)) );
>  +  usleep (1000); /* 500 works, too, but not 100 */
>
>    status =  hp_scsi_read(scsi, buf, &bufsize, 1);
>    if (FAILED(status))
>
>  When debugging, I ran the tool like this (built from checked-out
>  upstream CVS sources):
>
>   SANE_HP_RDREDO=3 SANE_DEBUG_HP=255 SANE_DEBUG_SANEI_SCSI=255 \
>     libtool --mode=execute gdb frontend/scanimage
>
>
> --
>  sane-devel mailing list: sane-devel at lists.alioth.debian.org
>  http://lists.alioth.debian.org/mailman/listinfo/sane-devel
>  Unsubscribe: Send mail with subject "unsubscribe your_password"
>              to sane-devel-request at lists.alioth.debian.org
>
>


-- 
"The truth is an offense, but not a sin"