Lines Matching full:input

2 Creating an input device driver
8 Here comes a very simple example of an input device driver. The device has
12     #include <linux/input.h>
74 First it has to include the <linux/input.h> file, which interfaces to the
75 input subsystem. This provides all the definitions needed.
81 Then it allocates a new input device structure with input_allocate_device()
82 and sets up input bitfields. This way the device driver tells the other
83 parts of the input systems what it is - what events can be generated or
84 accepted by this input device. Our example device can only generate EV_KEY
94 Then the example driver registers the input device structure by calling::
98 This adds the button_dev structure to linked lists of the input driver and
99 calls device handler modules _connect functions to tell them a new input
112 call to the input system. There is no need to check whether the interrupt
114 the input system, because the input_report_* functions check that
159 Note that input core keeps track of number of users for the device and
167 Inhibiting input devices
170 Inhibiting a device means ignoring input events from it. As such it is about
171 maintaining relationships with input handlers - either already existing
175 If a device is inhibited, no input handler will receive events from it.
180 is to stop providing events to the input core and that of open() is to start
181 providing events to the input core.
189 input handlers. Userspace might want to inhibit a device in anticipation before
199 this interface. So, there may be input drivers which should be considered wakeup
200 sources even when inhibited. Actually, in many I2C input devices their interrupt
202 is not aware of input-specific inhibit (nor should it be).  Composite devices
217 It's reported to the input system via::
221 See uapi/linux/input-event-codes.h for the allowable values of code (from 0 to
223 key pressed, zero value means key released. The input code generates events only
278 The dev->name should be set before registering the input device by the input
283 of the device. The bus IDs are defined in input.h. The vendor and device IDs
285 should be set by the input device driver before registering it.
287 The idtype field can be used for specific information for the input device
295 These three fields should be used by input devices that have dense keymaps.
296 The keycode is an array used to map from scancodes to input system keycodes.
310 keycode/keycodesize/keycodemax mapping mechanism provided by input core
316 ... is simple. It is handled by the input.c module. Hardware autorepeat is
320 handled by the input system.
331 direction - from the system to the input device driver. If your input device