Abel,
I would be happy to do some testing but unfortunately
my coding skills do not go beyond python, C is rather like
klingonian for me.
In the latest sane backend sources (Top of the changelog below)
I could not find the header file sg.h . I would need something
like in file www/xxx replace yyy with zzz.
Thanks, Dirk
2003-02-27 Henning Meier-Geinitz <henn...@meier-geinitz.de>
* backend/gt68xx.c backend/gt68xx.conf backend/gt68xx_devices.c
backend/gt68xx_low.c backend/gt68xx_low.h
doc/descriptions/gt68xx.desc
doc/gt68xx/gt68xx.CHANGES: Added Genius Colorpage Vivid3xe.
Added
request_type and request fields to the command set. Request is
0x01
or 0x04.
> -----Original Message-----
> From: sane-devel-ad...@www.mostang.com
> [mailto:sane-devel-ad...@www.mostang.com] On Behalf Of abel deuring
> Sent: Friday, March 07, 2003 11:44 AM
> To: Frank Zago
> Cc: sane-de...@www.mostang.com
> Subject: Re: [sane-devel] lost with FUJITSU scanner M3096G
>
>
> Frank Zago wrote:
> >
> > abel deuring wrote:
> > > Frank Zago wrote:
> > >
> > >>>[fujitsu] set_window_param
> > >>>[fujitsu] Window set
> > >>>[fujitsu] 000: 00 00 01 2c 01 2c 00 00 00 00 00 00 00 00 00 00
> > >>>[fujitsu] 016: 03 b0 00 00 05 89 00 00 00 02 08 00 00 00 00 00
> > >>>[fujitsu] 032: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0
> > >>>[fujitsu] 048: 20 00 00 00 00 84 00 00 00 00 00 00 00 00 00 00
> > >>>[fujitsu] 5/38/0: Invalid field in parm list
> > >>>[fujitsu] sanei_scsi_cmd: returning 0x00000004
> > >>>[fujitsu] sane_start: ERROR: failed to set window
> > >>
> > >>The scanner rejected the window parameter. If the scsi
> > >>implementation is decent, the sense might contain the
> offset of the
> > >>offending byte somewhere around byte 16 oy 17. To get
> that, at the
> > >>beginning of scsi_sense_handler, add this line:
> > >>
> > >> hexdump (MSG_IO, "Sense", sensed_data, sensed_data[7]+8);
> > >
> > >
> > > Frank,
> > >
> > > you're right, the sense bytes 16 and 17 should point to the
> > > offending byte, but unfortunately the Linux SCSI system
> returns only
> > > the first 16 bytes of a SCSI command.
> >
> > Are you sure of that? There are devices out there that return more
> > than 100 bytes of data in the sense. I assume someone
> would have fixed
> > such a problem.
>
> This is the definition of sg_header from sg.h:
>
> #define SG_MAX_SENSE 16 /* this only applies to the sg_header
> interface */
>
> struct sg_header
> {
> /* Length of incoming packet (including header). */
> int pack_len;
> /* Maximal length of expected reply. */
> int reply_len;
> /* Id number of packet. */
> int pack_id;
> /* 0==ok, otherwise error number. */
> int result;
> /* Force 12 byte command length for group 6 & 7 commands. */
> unsigned int twelve_byte:1;
> /* SCSI status from target. */
> unsigned int target_status:5;
> /* Host status (see "DID" codes). */
> unsigned int host_status:8;
> /* Driver status+suggestion. */
> unsigned int driver_status:8;
> /* Unused. */
> unsigned int other_flags:10;
> /* Output in 3 cases:
> when target_status is CHECK_CONDITION or
> when target_status is COMMAND_TERMINATED or
> when (driver_status & DRIVER_SENSE) is true. */
> unsigned char sense_buffer[SG_MAX_SENSE];
> };
>
> Using the new header structure, I am not 100% sure though --
> would be worth some tests ;)
>
> >
> > > But it might help to issue a REQUEST SENSE manually after the
> > > failing SET WINDOW and print the result of this command.
> >
> > Unless the system caches the sense (and more than 16
> bytes), the next
> > request sense isn't going to return anything.
>
> Right, there is not guarantee that the data returned from a
> second REQUEST SENSE call is valid -- but that depends on
> the device, I think (and the usage conditions, of course).
> At least one backend issued REQUEST SENSE via sanei_scsi_cmd
> in older versions of Sane, obviously without problems.
>
> Abel
> _______________________________________________
> Sane-devel mailing list
> sane-de...@www.mostang.com
> http://www.mostang.com/mailman/listinfo/sane- > devel
>
