Lines Matching refs:the

6 received are not parsed by the HID parser, but are sent to and received from
7 the device unmodified.
9 Hidraw should be used if the userspace application knows exactly how to
10 communicate with the hardware device, and is able to construct the HID
11 reports manually.  This is often the case when making userspace drivers for
17 through it, checking them against the device's report descriptor, such
19 Hidraw is the only alternative, short of writing a custom kernel driver, for
23 of the underlying hardware type.  Currently, Hidraw is implemented for USB
24 and Bluetooth.  In the future, as new hardware bus types are developed which
25 use the HID specification, hidraw will be expanded to add support for these
29 create hidraw device nodes.  Udev will typically create the device nodes
32 devices attached to the system.  There is a tutorial on libudev with a
41 read() will read a queued report received from the HID device. On USB
42 devices, the reports read using read() are the reports sent from the device
43 on the INTERRUPT IN endpoint.  By default, read() will block until there is
45 the O_NONBLOCK flag to open(), or by setting the O_NONBLOCK flag using
48 On a device which uses numbered reports, the first byte of the returned data
49 will be the report number; the report data follows, beginning in the second
50 byte.  For devices which do not use numbered reports, the report data
51 will begin at the first byte.
55 The write() function will write a report to the device. For USB devices, if
56 the device has an INTERRUPT OUT endpoint, the report will be sent on that
57 endpoint. If it does not, the report will be sent over the control endpoint,
60 The first byte of the buffer passed to write() should be set to the report
61 number.  If the device does not use numbered reports, the first byte should
62 be set to 0. The report data itself should begin at the second byte.
66 Hidraw supports the following ioctls:
69 This ioctl will get the size of the device's report descriptor.
72 This ioctl returns the device's report descriptor using a
73 hidraw_report_descriptor struct.  Make sure to set the size field of the
74 hidraw_report_descriptor struct to the size returned from HIDIOCGRDESCSIZE.
77 This ioctl will return a hidraw_devinfo struct containing the bus type, the
78 vendor ID (VID), and product ID (PID) of the device. The bus type can be one
87 This ioctl returns a string containing the vendor and product strings of
88 the device.  The returned string is Unicode, UTF-8 encoded.
91 This ioctl returns a string representing the physical address of the device.
92 For USB devices, the string contains the physical path to the device (the
93 USB controller, hubs, ports, etc).  For Bluetooth devices, the string
94 contains the hardware (MAC) address of the device.
97 This ioctl will send a feature report to the device.  Per the HID
98 specification, feature reports are always sent using the control endpoint.
99 Set the first byte of the supplied buffer to the report number.  For devices
100 which do not use numbered reports, set the first byte to 0. The report data
101 begins in the second byte. Make sure to set len accordingly, to one more
102 than the length of the report (to account for the report number).
105 This ioctl will request a feature report from the device using the control
106 endpoint.  The first byte of the supplied buffer should be set to the report
107 number of the requested report.  For devices which do not use numbered
108 reports, set the first byte to 0.  The report will be returned starting at
109 the first byte of the buffer (ie: the report number is not returned).
114 and all the ioctls for hidraw.  The code may be used by anyone for any