On 06/30/2010 10:02 AM, Xiaofan Chen wrote:
On Wed, Jun 30, 2010 at 9:13 PM, Antonio Ospite
<ospite@xxxxxxxxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
