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

Peter Kirchgessner peter at kirchgessner.net
Wed Mar 26 20:24:31 UTC 2008


I have no problem if the usleep(1000) is added. If it helps, it's ok. 
For a typical scan about 200 inquiries are done. So setting up the 
scanner is slowed down by 0.2 seconds in total. That is far less than 
the scan will need.
I don't know if it is possible with libusb to check if an answer of the 
scanner is available or not. But if you tried increasing the value and 
it still did not work every second run I would say there are still some 
other problems with USB. My ScanJet 6250 is working without problems for 
years using USB.
Who will apply the patch to the official SANE-backends ?

Kind regards

Peter Kirchgessner

m. allan noah schrieb:
> 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
>>
>>
> 
> 

-- 
Peter Kirchgessner
http://www.kirchgessner.net
mailto:peter at kirchgessner.net




More information about the sane-devel mailing list