Re: Report ID problem with HID-RAW interface usage

[Alan Ott <alan@signal11.us>]

On 06/30/2010 10:02 AM, Xiaofan Chen wrote:
> On Wed, Jun 30, 2010 at 9:13 PM, Antonio Ospite
> <ospite@studenti.unina.it>  wrote:
>    
>> One of the advantages in the usb case is that you do not have to
>> _detach_ the kernel driver bound to the device in order to set/get
>> raw hid reports. With libusb this is needed.
>>
>>      
> To me this is not that much an advantage. Actually libusb-1.0
> has the API to re-attach the kernel driver under Linux. And we make
> use of this in the new libusb-1.0 example program xusb.
> http://libusb.sourceforge.net/api-1.0/group__dev.html#ga9de769d3aeb45a07f5559c8a0597cbcc
> http://git.libusb.org/?p=libusb-pbatard.git;a=blob;f=examples/xusb.c;h=e260153aa50234f1c994db521969b7f0e84aebb6;hb=HEAD
>    

Another advantage of hidraw is that the API does not depend on the 
transport. As Jiri said, it supports multiple hardware types, but beyond 
that, one does not have to worry about whether to send data over the 
control endpoint vs. interrupt endpoints, whether the report number gets 
added properly (in theory, when there aren't bugs :) ), etc.

The theory is that one can throw data at hidraw using simple read() and 
write() commands, and it comes out on the device side, without the 
client program having to know too much about USB or Bluetooth.

That's an advantage to me anyway. It's true that libusb is more flexible 
for USB devices as it handles custom class, and non-HID class devices, 
and can send data on any endpoint directly. The HID is supposed to be a 
simplified interface (limited endpoints, well-structured data, etc), so 
it makes sense to have a simplified API to communicate with it.

Think of hidraw as analogous to the Windows hid.dll API. The concepts 
are similar.

Alan.