Hi Albert, On Mittwoch, 26. November 2003 12:51, Albert ARIBAUD wrote: [SNIPSNAP] > > I simply turned the IO operations in the parport backend, and hoped, that > > the scanner will work. The major problem is, that the GL640 allows > > various ways on how a parport-ASIC can be connected, and therefore it is > > almost impossible to directly "map" the former parport I/O functions to > > USB I/O functions... > > Uhm. OK. :( How about reverse engineering the connections between the > 98003 and the GL640? My brother is not a software guy indeed, but he can > use an ohmmeter and help sort out things there.
I don't think, that we need this. In the end we don't have a pin-out for the P98003. The only the we can compare are probably the connections to the parport and GL640... > > After all of these trials had no or minor success, I made some USB-snoop > > loggings and noticed, that for this scanner almost only bulk-read and > > -writes are used and so the whole parport-driver code needs to be > > rewritten there. There are currently also some parts of the log, that I > > do not understand... > > An outside eye might be helpful. Could you send me the logs together > with an indication of what the scanner was asked to do at that time? Here you are, the following sequence is interesting and representative, because the data can be assigned to a function in the plustek_pp code called p12ProgramCCD(). So this shows us, that single transfers on plain parport are done via BULK transfers in the U12... 7 out down 0x02 12.861 BULK_OR_INTERRUPT_TRANSFER 2c 00 39 3d 3a 06 3b 46 URB Header (length: 72) SequenceNumber: 7 Function: 0009 (BULK_OR_INTERRUPT_TRANSFER) TransferFlags: 0x00000002 TransferBuffer: 0x0000003a (58) length 0000: 2c 00 39 3d 3a 06 3b 46 3c 06 41 3d 42 92 43 01 0010: 44 13 45 13 46 f2 47 01 48 13 49 13 4a fa 4b 1b 0020: 4c 06 4d 06 4e 0b 50 23 51 06 52 06 53 0b 67 00 0030: 6f 30 70 06 60 17 61 9f 65 01 7 out up 0x02 12.862 BULK_OR_INTERRUPT_TRANSFER - 0x00000000 URB Header (length: 72) SequenceNumber: 7 Function: 0009 (BULK_OR_INTERRUPT_TRANSFER) TransferFlags: 0x00000002 No TransferBuffer 8 out down 0x00 12.872 VENDOR_DEVICE 01 11 00 00 08 00 00 00 URB Header (length: 80) SequenceNumber: 8 Function: 0017 (VENDOR_DEVICE) PipeHandle: 00000000 SetupPacket: 0000: 40 04 82 00 2c 00 00 00 bmRequestType: 40 DIR: Host-To-Device TYPE: Vendor RECIPIENT: Device bRequest: 04 TransferBuffer: 0x00000008 (8) length 0000: 01 11 00 00 08 00 00 00 This last transfer I do not understand. I can't identify it's meaning, but it seems that all bulk transfers, are closed by such a 8 byte sequence. The only point where these sequences differ is position 5. Maybe somebody out there has an idea? Maybe we once get a driver ;-) Gerhard
