On 22.08.2013 17:22, Florian Echtler wrote: > On 22.08.2013 16:49, Alan Stern wrote: >> On Thu, 22 Aug 2013, Florian Echtler wrote: >>> Userspace version: >>> // for control commands >>> usb_control_msg(handle, 0xC0, cmd, 0x00, index, (char*)buf, len, 1000); >>> Kernel version: >>> // for control commands >>> #define surface_command(dev, command, index, buffer, size) >>> usb_control_msg (dev->usbdev, usb_rcvctrlpipe (dev->usbdev, 0), >>> command, USB_TYPE_VENDOR | USB_RECIP_ENDPOINT | USB_DIR_IN, 0x00, >>> index, buffer, size, 1000) >> This isn't equivalent to the userspace version. Here the recipient is >> USB_RECIP_ENDPOINT, but in the userspace version it is >> USB_RECIP_DEVICE. To put it another way, here the bRequestType value >> is 0xC2 and there it is 0xC0. > Great, thanks for spotting this. I thought I had correctly interpreted > the original value with respect to the kernel constants - apparently not. > Once I work up the nerve to give it another try with the updated driver, > I'll report back. As promised, I did fix this in the prototype driver and for the first time, it didn't behave eratically or trash the firmware EEPROM. So I think I'm finally back on track for a working, non-dangerous input driver which I should presumably submit to linux-input@xxxxxxxxxxxxxxx when done? Thanks again for your help, Alan! Best regards, Florian -- SENT FROM MY DEC VT50 TERMINAL
Attachment:
signature.asc
Description: OpenPGP digital signature
