[sane-devel] Help with Canon 2700F
adeuring at gmx.net
Thu Aug 17 13:29:21 UTC 2006
> Am Mittwoch, 16. August 2006 18:58 schrieb abel deuring:
>>>to me, it looks like that the (working) Epson scanner gives much more
>>>info than the canon does.
>>right: the Epson seems to be OK, while something is broken with the
>>FS2700, see below.
>>>I already tried to debug (eclipse, cdt) the call - but I did not manage
>>>to have the source included when init() is called - the closest I got to,
>>>is that sense_handler in canon.c seems to be called with a null argument
>>>- seen in the debug output too - but here the mess has happened already.
>>The null argument in the sense handler is OK.
> sorry - but, no it is _not_.
> if you look at the sense_handler function in canon.c, it is quite clear, that
> this sense_handler will return via the
> sense_str = "problem not analyzed (unknown SCSI class)";
> // status = SANE_STATUS_IO_ERROR;
ouch. yes, you are right. The problem is that this error occurs
quite early during the setup of the device structures. Perhaps you
can simply comment out this call of TEST UNIT READY.
>>Besides, you can grep for strings like
>>"attach: sending TEST_UNIT_READY" in the sources files of the
>>backend; you should be able to quickly find the correct lines; here
>>you can add for example additional DBG calls.
>>The authors of the backend decided to not let the backend continue
>>to access the scanner in this case -- a reasonable decision. You
>>might though try to ignore this specific error and patch the backend
> I already did - and got a lamp-error - the scanner works just fine on w2k - no
> lamp error.
If you look at the sense buffer of the first error and at the
function sense_handler in the canon sources, you'll see that "lamp
error" is exactly the error you get in the first place. It seems
that the Windows driver simply ignores this error. You could patch
sense_handler to simply print a warning in case of a lamp error, but
to return SANE_STATUS_GOOD in this case. But you should expect a
somewhat degraded scan quality.
> following your suggestions I found the lines where the calling of the
> sense_handler with the null argument originates - it is in sanei/sanei_scsi.c
> in function at line 251ff:
> SANEI_SCSI_Sense_Handler handler
> = fd_info[req->fd].sense_handler;
> void *arg = fd_info[req->fd].sense_handler_arg;
right: If sanei_scsi_cmd discovers an error, it calls the sense
handler so that the backend can decide, what to do.
> I'm still on my way to find out where this structure gets initialized.
As already said: in the function attach.
More information about the sane-devel