Documentation/input/input-programming.rst

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>
34 		    return -EBUSY;
40 		    error = -ENOMEM;
44 	    button_dev->evbit[0] = BIT_MASK(EV_KEY);
45 	    button_dev->keybit[BIT_WORD(BTN_0)] = BIT_MASK(BTN_0);
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
113 routine isn't reporting two same value events (press, press for example) to
114 the input system, because the input_report_* functions check that
126 dev->open() and dev->close()
140 		    return -EBUSY;
154 	    button_dev->open = button_open;
155 	    button_dev->close = button_close;
159 Note that input core keeps track of number of users for the device and
160 makes sure that dev->open() is called only when the first user connects
161 to the device and that dev->close() is called when the very last user
164 The open() callback should return a 0 in case of success or any nonzero value
171 It's reported to the input system via::
173 	input_report_key(struct input_dev *dev, int code, int value)
175 See uapi/linux/input-event-codes.h for the allowable values of code (from 0 to
176 KEY_MAX). Value is interpreted as a truth value, ie any nonzero value means key
177 pressed, zero value means key released. The input code generates events only
178 in case the value is different from before.
182 device. A relative value may be for example a mouse movement in the X axis.
185 events are namely for joysticks and digitizers - devices that do work in an
191 	input_report_rel(struct input_dev *dev, int code, int value)
193 function. Events are generated only for nonzero value.
212 max values), with noise in the data up to +- 4, and with a center flat
224 	BITS_TO_LONGS(x) - returns the length of a bitfield array in longs for
226 	BIT_WORD(x)	 - returns the index in the array in longs for bit x
227 	BIT_MASK(x)	 - returns the index in a long for bit x
232 The dev->name should be set before registering the input device by the input
237 of the device. The bus IDs are defined in input.h. The vendor and device ids
239 should be set by the input device driver before registering it.
241 The idtype field can be used for specific information for the input device
249 These three fields should be used by input devices that have dense keymaps.
250 The keycode is an array used to map from scancodes to input system keycodes.
260 dev->getkeycode() and dev->setkeycode()
264 keycode/keycodesize/keycodemax mapping mechanism provided by input core
270 ... is simple. It is handled by the input.c module. Hardware autorepeat is
273 autorepeat for your device, just set EV_REP in dev->evbit. All will be
274 handled by the input system.
281 - EV_LED - used for the keyboard LEDs.
282 - EV_SND - used for keyboard beeps.
285 direction - from the system to the input device driver. If your input device
289     button_dev->event = button_event;
292 		     unsigned int code, int value)
295 		    outb(value, BUTTON_BELL);
298 	    return -1;