[sane-devel] microtek2 - libusb ?

[Steven Palm]

On May 14, 2005, at 7:18 AM, Henning Meier-Geinitz wrote:
>> Any notes on how to go about (or general guidelines for) converting a
>> driver to support libusb?
>
> You shouldn't use libusb directly but the sanei_usb functions. AFAIK
> the avision backend has been changed to use direct USB access instead
> of using the kernel driver hpusbscsi so you may want to have a look at
> its code.

  I'm running into a few issues that are beyond the scope of my  
ignorance... :-)  (Well, the scope of my ignorance is pretty large in  
this area, so maybe I should say beyond the scope of my understanding.)

  A few things seem to be different between the avision and microtek2  
that are complicating my efforts.

  1)  The avision does a status read on an interrupt endpoint, the  
microtek2 USB config has none. Not a big deal, I just do a bulk_read  
and it seems to catch it OK.

  2)  The microtek has three endpoints, one output and two input.   
Using the sanei_open() and related functions I see this happening:

[sanei_usb] sanei_usb_open: trying to open device `libusb: 
003:002-05da-00a3-ff-03'
usb_os_open: 05da:00a3
usb_set_configuration: called for config 1
usb_claim_interface: called for interface 0
Interface 0 of device is 0x000011cf
claim_interface: Interface 0 of device from QueryInterface is 0x303c80
libusb/darwin.c get_endpoints: building table of endpoints.
get_endpoints: Pipe 1: DIR: 0 number: 1
get_endpoints: Pipe 2: DIR: 1 number: 2
get_endpoints: Pipe 3: DIR: 1 number: 3
libusb/darwin.c get_endpoints: complete.
[sanei_usb] sanei_usb_open: configuration nr: 0
[sanei_usb] sanei_usb_open:     interface nr: 0
[sanei_usb] sanei_usb_open:   alt_setting nr: 0
[sanei_usb] sanei_usb_open:num: 0 endpoint: 0x304260
[sanei_usb] sanei_usb_open: direction: 0)
[sanei_usb] sanei_usb_open:  address: 1 transfertype: 2
[sanei_usb] sanei_usb_open: found bulk-out endpoint (address 0x01)
[sanei_usb] sanei_usb_open:num: 1 endpoint: 0x304274
[sanei_usb] sanei_usb_open: direction: 128)
[sanei_usb] sanei_usb_open:  address: 2 transfertype: 2
[sanei_usb] sanei_usb_open: found bulk-in endpoint (address 0x02)
[sanei_usb] sanei_usb_open:num: 2 endpoint: 0x304288
[sanei_usb] sanei_usb_open: direction: 128)
[sanei_usb] sanei_usb_open:  address: 3 transfertype: 2
[sanei_usb] sanei_usb_open: found bulk-in endpoint (address 0x03)
[sanei_usb] sanei_usb_open: we already have a bulk-in endpoint  
(address: 0x82), ignoring the new one
[sanei_usb] sanei_usb_open: opened usb device `libusb: 
003:002-05da-00a3-ff-03' (*dn=0)

  The trouble is, I can't have it throwing away the other endpoint,  
because apparently the microtek scanner sends command responses back  
on endpoint 2, but scan data comes back on endpoint 3. <sigh> Anyway  
to get this type of behavior out of the sanei_ routines?

  FWIW, I gleaned this little bit of info from the microtek linux  
kernel driver code:

* The X6 USB has three bulk endpoints, one output (0x1) down which
* commands and outgoing data are sent, and two input: 0x82 from which
* normal data is read from the scanner (in packets of maximum 32
* bytes) and from which the status byte is read, and 0x83 from which
* the results of a scan (or preview) are read in up to 64 * 1024 byte
* chunks by the Windows driver. We don't know how much it is possible
* to read at a time from 0x83.
*
* It seems possible to read (with URB transfers) everything from 0x82
* in one go, without bothering to read in 32 byte chunks.
*
* There seems to be an optimisation of a further READ implicit if
* you simply read from 0x83.


(MY NOTE: I have no clue what that last bit means... Anyone? :-)

*
* Guessed protocol:
*
*    Send raw SCSI command to EP 0x1
*
*    If there is data to receive:
*        If the command was READ datatype=image:
*            Read a lot of data from EP 0x83
*        Else:
*            Read data from EP 0x82
*    Else:
*        If there is data to transmit:
*            Write it to EP 0x1
*
*    Read status byte from EP 0x82


  So far, it is talking to the scanner anyway, sending some commands  
and getting data back right up until it calls the READ microtek  
opcode and times out on waiting for response, my guess is that this  
response needs to be obtained over the other endpoint.  THe above  
said READ datatype=image, and in this case the READ is type=system  
status.

Thanks!

  Steve