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"
