Re: Trying to develop a Pixelsense kernel driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Alan, thanks for the quick response.

On 22.08.2013 16:49, Alan Stern wrote:
> On Thu, 22 Aug 2013, Florian Echtler wrote:
>> So even though userspace and kernel driver look like they perform
>> exactly the same operations on the device, there must be some difference
>> I don't understand - perhaps libusb does some kind of internal error
>> handling which the kernel doesn't do?
>>
>> 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.

>> // for bulk data transfer
>> result = usb_bulk_msg (surface->usbdev,
>> usb_rcvbulkpipe (surface->usbdev, 0x86),
>> surface->bulk_in_buffer, 512, &bulk_read, 1000);
> 
> This is equivalent to the version above.

OK.

>> Can anybody venture a guess what kind of functional difference there is
>> between these code snippets?
> 
> It's hard to say exactly.  Probably one of the control messages will 
> work and the other one won't.

The (wrong?) control messages in the kernel still work (in the sense
that they don't trigger any detectable errors during the init sequence).
However, as mentioned above, after a few loads and unloads of the kernel
driver, the firmware EEPROM is trashed. (Which leads to some speculation
about the quality of said firmware, regardless of my poor driver writing
skills.)

Once I work up the nerve to give it another try with the updated driver,
I'll report back.

Florian
-- 
SENT FROM MY DEC VT50 TERMINAL

Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux