[sane-devel] Help with Canon 2700F

[Lutz]

Am Mittwoch, 16. August 2006 18:58 schrieb abel deuring:
> Lutz wrote:
> > 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
------------------------
   else
    {
      sense_str = "problem not analyzed (unknown SCSI class)";
      // status = SANE_STATUS_IO_ERROR;
    }
--------------------
branch of the first if... in this function:
if (dev && ....
and dev gets bound to *arg:
--------------------------------
static SANE_Status
sense_handler (int scsi_fd, u_char * result, void *arg)
{
  static char testbuffer0[256];
  CANON_Device *dev = (CANON_Device *) arg;
....
-------------------------------
> Regarding debugging: 
> gdb is your friend ;)
it is eclipses friend too ;) 
... but I seem not to be eclipses friend (yet) 
=8o
> 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
> accordingly.
I already did - and got a lamp-error - the scanner works just fine on w2k - no 
lamp error.

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;
-----------------
I'm still on my way to find out where this structure gets initialized.
btw - when I disabled the return of an error in the first call, I got several 
calls to the sense_handler, where the arg is not null - the lamp error is 
signaled from a not-null dev.
>
> Abel
thx

Lutz