Lines Matching full:event

38 The "type" field contains the ID of the event. Depending on the ID different
39 payloads are sent. You must not split a single event across multiple read()'s or
40 multiple write()'s. A single event must always be sent as a whole. Furthermore,
41 only a single event can be sent per read() or write(). Pending data is ignored.
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
51 UHID_OPEN event, the internally attached HID Device Driver has no user attached.
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
55 followed by an UHID_OPEN event again and so on. There is no need to perform
57 UHID_OPEN events without an UHID_CLOSE event. The HID subsystem performs
63 an HID_INPUT2 event with your raw data payload. If the kernel wants to send data
64 on the interrupt channel to the device, you will read an UHID_OUTPUT event.
74 If your device disconnects, you should send an UHID_DESTROY event. This will
83 the kernel. The kernel will parse the event immediately and if the event ID is
92   event to the kernel. The payload is of type struct uhid_create2_req and
103   You must send UHID_CREATE2 before sending input to the kernel! This event
126   UHID_CREATE2. This is always the first event that is sent. Note that this
127   event might not be available immediately after write(UHID_CREATE2) returns.
129   This event contains a payload of type uhid_start_req. The "dev_flags" field
148   UHID_STOP event, this should usually be ignored. It means that the kernel
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.
172   This event is sent if the kernel driver wants to perform a GET_REPORT request