Lines Matching refs:you
19 dynamically so you need to rely on udev (or similar) to create the device node.
22 If a new device is detected by your HID I/O Driver and you want to register this
23 device with the HID subsystem, then you need to open /dev/uhid once for each
24 device you want to register. All further communication is done by read()'ing or
42 If you want to handle multiple events in a single syscall, then use vectored
48 The first thing you should do is sending an UHID_CREATE2 event. This will
52 That is, you might put your device asleep unless you receive the UHID_OPEN
53 event. If you receive the UHID_OPEN event, you should start I/O. If the last
54 user closes the HID device, you will receive an UHID_CLOSE event. This may be
56 reference-counting in user-space. That is, you will never receive multiple
58 ref-counting for you.
62 If you want to send data on the interrupt channel to the HID subsystem, you send
64 on the interrupt channel to the device, you will read an UHID_OUTPUT event.
68 UHID_GET_REPORT and UHID_SET_REPORT events and requires you to forward them to
69 the device on the control channel. Once the device responds, you must forward
74 If your device disconnects, you should send an UHID_DESTROY event. This will
77 If you close() the fd, the device is automatically unregistered and destroyed
82 write() allows you to modify the state of the device and feed input data into
91 This creates the internal HID device. No I/O is possible until you send this
97 may still be pending messages that you can receive with read() but no further
104 contains a data-payload. This is the raw data that you read from your device
108 If you receive a UHID_GET_REPORT request you must answer with this request.
111 If "err" is 0 then you should fill the buffer of the answer with the results
122 them but you should handle them according to your needs.
140 For messages sent by user-space to the kernel, you must adjust the
147 If you didn't destroy your device via UHID_DESTROY, but the kernel sends an
157 it is useful for power-management. As long as you haven't received this event
163 the counterpart of UHID_OPEN and you may as well ignore this event.
169 This may be received even though you haven't received UHID_OPEN, yet.
176 parallel. However, if you fail to respond with a UHID_GET_REPORT_REPLY, the
178 Once you read a GET_REPORT request, you shall forward it to the hid device and
180 GET_REPORT (or if it fails), you must send a UHID_GET_REPORT_REPLY to the
186 This is the SET_REPORT equivalent of UHID_GET_REPORT. On receipt, you shall
187 send a SET_REPORT request to your hid device. Once it replies, you must tell