[sane-devel] lost with FUJITSU scanner M3096G

[Dirk Petersen]

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 <henning at 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-admin at www.mostang.com 
 > [mailto:sane-devel-admin at www.mostang.com] On Behalf Of abel deuring
 > Sent: Friday, March 07, 2003 11:44 AM
 > To: Frank Zago
 > Cc: sane-devel at 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-devel at www.mostang.com 
 > http://www.mostang.com/mailman/listinfo/sane- > devel
 >