Lines Matching full: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
39 payloads are sent. You must not split a single event across multiple read()'s 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
49 register the device. UHID will respond with an UHID_START event. You can now
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.
59 You may decide to ignore UHID_OPEN/UHID_CLOSE, though. I/O is allowed even
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
75 unregister the device. You can now send UHID_CREATE2 again to register a new
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
93   contains information about your device. You can start I/O now.
97   may still be pending messages that you can receive with read() but no further
99   You can create a new device by sending UHID_CREATE2 again. There is no need to
103   You must send UHID_CREATE2 before sending input to the kernel! This event
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.
109   You  must copy the "id" field from the request into the answer. Set the "err"
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
152   You can usually ignored any UHID_STOP events safely.
156   device provides is read by some other process. You may ignore this event but
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.
167   device on the interrupt channel. You should read the payload and forward it to
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