^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) ===============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) Creating an input device driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) ===============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) The simplest example
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6) ~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) Here comes a very simple example of an input device driver. The device has
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) just one button and the button is accessible at i/o port BUTTON_PORT. When
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) pressed or released a BUTTON_IRQ happens. The driver could look like::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) #include <linux/input.h>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) #include <linux/module.h>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) #include <linux/init.h>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) #include <asm/irq.h>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) #include <asm/io.h>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) static struct input_dev *button_dev;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) static irqreturn_t button_interrupt(int irq, void *dummy)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) input_report_key(button_dev, BTN_0, inb(BUTTON_PORT) & 1);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) input_sync(button_dev);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) return IRQ_HANDLED;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) static int __init button_init(void)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) int error;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) if (request_irq(BUTTON_IRQ, button_interrupt, 0, "button", NULL)) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) printk(KERN_ERR "button.c: Can't allocate irq %d\n", button_irq);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) return -EBUSY;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) button_dev = input_allocate_device();
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) if (!button_dev) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) printk(KERN_ERR "button.c: Not enough memory\n");
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) error = -ENOMEM;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) goto err_free_irq;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) button_dev->evbit[0] = BIT_MASK(EV_KEY);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) button_dev->keybit[BIT_WORD(BTN_0)] = BIT_MASK(BTN_0);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) error = input_register_device(button_dev);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) if (error) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) printk(KERN_ERR "button.c: Failed to register device\n");
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) goto err_free_dev;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) return 0;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) err_free_dev:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) input_free_device(button_dev);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) err_free_irq:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) free_irq(BUTTON_IRQ, button_interrupt);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) return error;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) static void __exit button_exit(void)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) input_unregister_device(button_dev);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) free_irq(BUTTON_IRQ, button_interrupt);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) module_init(button_init);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) module_exit(button_exit);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) What the example does
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) ~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) First it has to include the <linux/input.h> file, which interfaces to the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) input subsystem. This provides all the definitions needed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) In the _init function, which is called either upon module load or when
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) booting the kernel, it grabs the required resources (it should also check
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) for the presence of the device).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) Then it allocates a new input device structure with input_allocate_device()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) and sets up input bitfields. This way the device driver tells the other
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) parts of the input systems what it is - what events can be generated or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) accepted by this input device. Our example device can only generate EV_KEY
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) type events, and from those only BTN_0 event code. Thus we only set these
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) two bits. We could have used::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) set_bit(EV_KEY, button_dev.evbit);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) set_bit(BTN_0, button_dev.keybit);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) as well, but with more than single bits the first approach tends to be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) shorter.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) Then the example driver registers the input device structure by calling::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) input_register_device(&button_dev);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) This adds the button_dev structure to linked lists of the input driver and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) calls device handler modules _connect functions to tell them a new input
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) device has appeared. input_register_device() may sleep and therefore must
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) not be called from an interrupt or with a spinlock held.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) While in use, the only used function of the driver is::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) button_interrupt()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) which upon every interrupt from the button checks its state and reports it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) via the::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) input_report_key()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) call to the input system. There is no need to check whether the interrupt
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) routine isn't reporting two same value events (press, press for example) to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) the input system, because the input_report_* functions check that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) themselves.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) Then there is the::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) input_sync()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) call to tell those who receive the events that we've sent a complete report.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) This doesn't seem important in the one button case, but is quite important
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) for for example mouse movement, where you don't want the X and Y values
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) to be interpreted separately, because that'd result in a different movement.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) dev->open() and dev->close()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) In case the driver has to repeatedly poll the device, because it doesn't
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) have an interrupt coming from it and the polling is too expensive to be done
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) all the time, or if the device uses a valuable resource (eg. interrupt), it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) can use the open and close callback to know when it can stop polling or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) release the interrupt and when it must resume polling or grab the interrupt
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) again. To do that, we would add this to our example driver::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) static int button_open(struct input_dev *dev)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) if (request_irq(BUTTON_IRQ, button_interrupt, 0, "button", NULL)) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) printk(KERN_ERR "button.c: Can't allocate irq %d\n", button_irq);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) return -EBUSY;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) return 0;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) static void button_close(struct input_dev *dev)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) free_irq(IRQ_AMIGA_VERTB, button_interrupt);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) static int __init button_init(void)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) button_dev->open = button_open;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) button_dev->close = button_close;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) Note that input core keeps track of number of users for the device and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) makes sure that dev->open() is called only when the first user connects
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) to the device and that dev->close() is called when the very last user
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) disconnects. Calls to both callbacks are serialized.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) The open() callback should return a 0 in case of success or any nonzero value
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) in case of failure. The close() callback (which is void) must always succeed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) Basic event types
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) ~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) The most simple event type is EV_KEY, which is used for keys and buttons.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) It's reported to the input system via::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) input_report_key(struct input_dev *dev, int code, int value)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) See uapi/linux/input-event-codes.h for the allowable values of code (from 0 to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) KEY_MAX). Value is interpreted as a truth value, ie any nonzero value means key
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) pressed, zero value means key released. The input code generates events only
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) in case the value is different from before.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) In addition to EV_KEY, there are two more basic event types: EV_REL and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) EV_ABS. They are used for relative and absolute values supplied by the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) device. A relative value may be for example a mouse movement in the X axis.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) The mouse reports it as a relative difference from the last position,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) because it doesn't have any absolute coordinate system to work in. Absolute
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) events are namely for joysticks and digitizers - devices that do work in an
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) absolute coordinate systems.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) Having the device report EV_REL buttons is as simple as with EV_KEY, simply
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) set the corresponding bits and call the::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) input_report_rel(struct input_dev *dev, int code, int value)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) function. Events are generated only for nonzero value.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) However EV_ABS requires a little special care. Before calling
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) input_register_device, you have to fill additional fields in the input_dev
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) struct for each absolute axis your device has. If our button device had also
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) the ABS_X axis::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) button_dev.absmin[ABS_X] = 0;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) button_dev.absmax[ABS_X] = 255;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) button_dev.absfuzz[ABS_X] = 4;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) button_dev.absflat[ABS_X] = 8;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) Or, you can just say::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) input_set_abs_params(button_dev, ABS_X, 0, 255, 4, 8);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) This setting would be appropriate for a joystick X axis, with the minimum of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) 0, maximum of 255 (which the joystick *must* be able to reach, no problem if
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) it sometimes reports more, but it must be able to always reach the min and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) max values), with noise in the data up to +- 4, and with a center flat
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) position of size 8.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215) If you don't need absfuzz and absflat, you can set them to zero, which mean
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) that the thing is precise and always returns to exactly the center position
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) (if it has any).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) BITS_TO_LONGS(), BIT_WORD(), BIT_MASK()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) These three macros from bitops.h help some bitfield computations::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) BITS_TO_LONGS(x) - returns the length of a bitfield array in longs for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) x bits
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) BIT_WORD(x) - returns the index in the array in longs for bit x
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) BIT_MASK(x) - returns the index in a long for bit x
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) The id* and name fields
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) ~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) The dev->name should be set before registering the input device by the input
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) device driver. It's a string like 'Generic button device' containing a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) user friendly name of the device.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) The id* fields contain the bus ID (PCI, USB, ...), vendor ID and device ID
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) of the device. The bus IDs are defined in input.h. The vendor and device ids
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) are defined in pci_ids.h, usb_ids.h and similar include files. These fields
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239) should be set by the input device driver before registering it.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) The idtype field can be used for specific information for the input device
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242) driver.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244) The id and name fields can be passed to userland via the evdev interface.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246) The keycode, keycodemax, keycodesize fields
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249) These three fields should be used by input devices that have dense keymaps.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250) The keycode is an array used to map from scancodes to input system keycodes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251) The keycode max should contain the size of the array and keycodesize the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252) size of each entry in it (in bytes).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254) Userspace can query and alter current scancode to keycode mappings using
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255) EVIOCGKEYCODE and EVIOCSKEYCODE ioctls on corresponding evdev interface.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256) When a device has all 3 aforementioned fields filled in, the driver may
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257) rely on kernel's default implementation of setting and querying keycode
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258) mappings.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 260) dev->getkeycode() and dev->setkeycode()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 261) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 262)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 263) getkeycode() and setkeycode() callbacks allow drivers to override default
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 264) keycode/keycodesize/keycodemax mapping mechanism provided by input core
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 265) and implement sparse keycode maps.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 266)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 267) Key autorepeat
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 268) ~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 269)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 270) ... is simple. It is handled by the input.c module. Hardware autorepeat is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 271) not used, because it's not present in many devices and even where it is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 272) present, it is broken sometimes (at keyboards: Toshiba notebooks). To enable
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 273) autorepeat for your device, just set EV_REP in dev->evbit. All will be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 274) handled by the input system.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 275)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 276) Other event types, handling output events
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 277) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 278)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 279) The other event types up to now are:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 280)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 281) - EV_LED - used for the keyboard LEDs.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 282) - EV_SND - used for keyboard beeps.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 283)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 284) They are very similar to for example key events, but they go in the other
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 285) direction - from the system to the input device driver. If your input device
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 286) driver can handle these events, it has to set the respective bits in evbit,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 287) *and* also the callback routine::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 288)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 289) button_dev->event = button_event;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 290)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 291) int button_event(struct input_dev *dev, unsigned int type,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 292) unsigned int code, int value)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 293) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 294) if (type == EV_SND && code == SND_BELL) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 295) outb(value, BUTTON_BELL);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 296) return 0;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 297) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 298) return -1;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 299) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 300)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 301) This callback routine can be called from an interrupt or a BH (although that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 302) isn't a rule), and thus must not sleep, and must not take too long to finish.
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags