On 06/18/2010 07:59 AM, Jiri Kosina wrote:
Documenation for the hidraw driver.
Thanks a lot for writing this up, Alan. It's something that has been
lingering on my TODO for just too long, it's great that someone finally
got fed up with it and wrote it :)
I wouldn't say I was fed up :)
I'm sure someone here will have a better idea where
to put this than the root of Documentation/. I didn't see a better place, as
hidraw is used for both Bluetooth and USB.
Either Documentation/input comes to mind, or we could even establish
Documentation/hid directory as well.
Antonio suggested the same, putting hidraw.txt and hiddev.txt into a new
Documentation/hid/ directory. I'll do this for the next rev unless I
hear otherwise.
Documentation/hidraw.txt | 283 ++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 283 insertions(+), 0 deletions(-)
create mode 100644 Documentation/hidraw.txt
diff --git a/Documentation/hidraw.txt b/Documentation/hidraw.txt
new file mode 100644
index 0000000..7153a06
--- /dev/null
+++ b/Documentation/hidraw.txt
@@ -0,0 +1,283 @@
+ HIDRAW - Raw Access to USB and Bluetooth Human Interface Devices
+ ==================================================================
+
+The hidraw driver provides a raw interface to USB and Bluetooth Human
+Interface Devices (HIDs). It differs from hiddev in that reports sent and
+received are not parsed by the HID parser, but are sent to and received from
+the device unmodified.
The important point behind hidraw (compared to hiddev), always has been
that it's in fact completely independent on underlying hardware transport
protocol. Currently there are no other implementations of HID than the
ones using Bluetooth or USB, but there is no general obstacle to using
hidraw once any vendor comes with HID-over-FibreChannel :) for example.
This basic principle might be worth mentioning as well.
I'll make sure to put that in.
+Hidraw should be used if the userspace application knows exactly how to
+communicate with the hardware device, and is able to construct the HID
+reports manually. This is often the case when making userspace drivers for
+custom HID devices.
+
+Hidraw is also useful for communicating with non-conformant HID devices
+which send and receive data in a way that is inconsistent with their report
+descriptors. Because hiddev parses reports which are sent and received
+through it and checks them against the device's report descriptor, such
+communication with these non-conformant devices is impossible using hiddev.
hidraw is just one of the alternatives here of course. Writing in-kernel
driver also can be done to overcome these obstacles.
Also true. I'll add it.
Thanks,
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
