Lines Matching refs:you
18 dynamically so you need to rely on udev (or similar) to create the device node.
21 If a new device is detected by your HID I/O Driver and you want to register this
22 device with the HID subsystem, then you need to open /dev/uhid once for each
23 device you want to register. All further communication is done by read()'ing or
41 If you want to handle multiple events in a single syscall, then use vectored
47 The first thing you should do is sending an UHID_CREATE2 event. This will
51 That is, you might put your device asleep unless you receive the UHID_OPEN
52 event. If you receive the UHID_OPEN event, you should start I/O. If the last
53 user closes the HID device, you will receive an UHID_CLOSE event. This may be
55 reference-counting in user-space. That is, you will never receive multiple
57 ref-counting for you.
61 If you want to send data on the interrupt channel to the HID subsystem, you send
63 on the interrupt channel to the device, you will read an UHID_OUTPUT event.
67 UHID_GET_REPORT and UHID_SET_REPORT events and requires you to forward them to
68 the device on the control channel. Once the device responds, you must forward
73 If your device disconnects, you should send an UHID_DESTROY event. This will
76 If you close() the fd, the device is automatically unregistered and destroyed
81 write() allows you to modify the state of the device and feed input data into
90 This creates the internal HID device. No I/O is possible until you send this
96 may still be pending messages that you can receive with read() but no further
103 contains a data-payload. This is the raw data that you read from your device
107 If you receive a UHID_GET_REPORT request you must answer with this request.
110 If "err" is 0 then you should fill the buffer of the answer with the results
121 them but you should handle them according to your needs.
137 For messages sent by user-space to the kernel, you must adjust the
143 If you didn't destroy your device via UHID_DESTROY, but the kernel sends an
152 it is useful for power-management. As long as you haven't received this event
158 the counterpart of UHID_OPEN and you may as well ignore this event.
164 This may be received even though you haven't received UHID_OPEN, yet.
171 parallel. However, if you fail to respond with a UHID_GET_REPORT_REPLY, the
173 Once you read a GET_REPORT request, you shall forward it to the hid device and
175 GET_REPORT (or if it fails), you must send a UHID_GET_REPORT_REPLY to the
181 This is the SET_REPORT equivalent of UHID_GET_REPORT. On receipt, you shall
182 send a SET_REPORT request to your hid device. Once it replies, you must tell