STRUCT INPUT_DEV(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… NAME

struct input_dev β€” it's literally the whole vibe of an input device, like the main character struct that holds everything the kernel needs to know about your keyboard, mouse, touchpad, whatever πŸŽ€


✨ SYNOPSIS

okay so here's the whole glow-up, no cap, every field exactly as it is:

struct input_dev {
    const char *name;
    const char *phys;
    const char *uniq;
    struct input_id id;
    unsigned long propbit[BITS_TO_LONGS(INPUT_PROP_CNT)];
    unsigned long evbit[BITS_TO_LONGS(EV_CNT)];
    unsigned long keybit[BITS_TO_LONGS(KEY_CNT)];
    unsigned long relbit[BITS_TO_LONGS(REL_CNT)];
    unsigned long absbit[BITS_TO_LONGS(ABS_CNT)];
    unsigned long mscbit[BITS_TO_LONGS(MSC_CNT)];
    unsigned long ledbit[BITS_TO_LONGS(LED_CNT)];
    unsigned long sndbit[BITS_TO_LONGS(SND_CNT)];
    unsigned long ffbit[BITS_TO_LONGS(FF_CNT)];
    unsigned long swbit[BITS_TO_LONGS(SW_CNT)];
    unsigned int hint_events_per_packet;
    unsigned int keycodemax;
    unsigned int keycodesize;
    void *keycode;
    int (*setkeycode)(struct input_dev *dev, const struct input_keymap_entry *ke, unsigned int *old_keycode);
    int (*getkeycode)(struct input_dev *dev, struct input_keymap_entry *ke);
    struct ff_device *ff;
    struct input_dev_poller *poller;
    unsigned int repeat_key;
    struct timer_list timer;
    int rep[REP_CNT];
    struct input_mt *mt;
    struct input_absinfo *absinfo;
    unsigned long key[BITS_TO_LONGS(KEY_CNT)];
    unsigned long led[BITS_TO_LONGS(LED_CNT)];
    unsigned long snd[BITS_TO_LONGS(SND_CNT)];
    unsigned long sw[BITS_TO_LONGS(SW_CNT)];
    int (*open)(struct input_dev *dev);
    void (*close)(struct input_dev *dev);
    int (*flush)(struct input_dev *dev, struct file *file);
    int (*event)(struct input_dev *dev, unsigned int type, unsigned int code, int value);
    struct input_handle *grab;
    spinlock_t event_lock;
    struct mutex mutex;
    unsigned int users;
    bool going_away;
    struct device dev;
    struct list_head        h_list;
    struct list_head        node;
    unsigned int num_vals;
    unsigned int max_vals;
    struct input_value *vals;
    bool devres_managed;
    ktime_t timestamp[INPUT_CLK_MAX];
    bool inhibited;
    bool ready;
 };

🫢 Members

okay bestie, member-by-member tour, let's go πŸ’–

  • name β€” the name of the device. iconic, essential, the whole identity ✨
  • phys β€” physical path to the device in the system hierarchy
  • uniq β€” unique identification code for the device (if the device has it). iykyk
  • id β€” id of the device (struct input_id)
  • propbit β€” bitmap of device properties and quirks
  • evbit β€” bitmap of types of events supported by the device (EV_KEY, EV_REL, etc.)
  • keybit β€” bitmap of keys/buttons this device has
  • relbit β€” bitmap of relative axes for the device
  • absbit β€” bitmap of absolute axes for the device
  • mscbit β€” bitmap of miscellaneous events supported by the device
  • ledbit β€” bitmap of leds present on the device
  • sndbit β€” bitmap of sound effects supported by the device
  • ffbit β€” bitmap of force feedback effects supported by the device
  • swbit β€” bitmap of switches present on the device
  • hint_events_per_packet β€” average number of events generated by the device in a packet (between EV_SYN/SYN_REPORT events). Event handlers use it to estimate the size of the buffer needed to hold events 🫢
  • keycodemax β€” size of keycode table
  • keycodesize β€” size of elements in keycode table
  • keycode β€” map of scancodes to keycodes for this device
  • setkeycode β€” optional method to alter current keymap, used to implement sparse keymaps. If it's not supplied, the default mechanism will be used. Heads up bestie: this method is being called while holding event_lock and thus must not sleep 😴🚫
  • getkeycode β€” optional legacy method to retrieve current keymap.
  • ff β€” force feedback structure associated with the device if the device supports force feedback effects
  • poller β€” poller structure associated with the device if the device is set up to use polling mode
  • repeat_key β€” stores key code of the last key pressed; used to implement software autorepeat πŸ”
  • timer β€” timer for software autorepeat
  • rep β€” current values for autorepeat parameters (delay, rate)
  • mt β€” pointer to multitouch state
  • absinfo β€” array of struct input_absinfo elements holding information about absolute axes (current value, min, max, flat, fuzz, resolution)
  • key β€” reflects current state of device's keys/buttons
  • led β€” reflects current state of device's LEDs
  • snd β€” reflects current state of sound effects
  • sw β€” reflects current state of device's switches
  • open β€” this method is called when the very first user calls input_open_device. The driver must prepare the device to start generating events (start polling thread, request an IRQ, submit URB, etc.). The meaning of open is to start providing events to the input core 🌱
  • close β€” this method is called when the very last user calls input_close_device. The meaning of close is to stop providing events to the input core πŸ₯€
  • flush β€” purges the device. Most commonly used to get rid of force feedback effects loaded into the device when disconnecting from it
  • event β€” event handler for events sent to the device, like EV_LED or EV_SND. The device is expected to carry out the requested action (turn on a LED, play sound, etc.). The call is protected by event_lock and must not sleep πŸ’€
  • grab β€” input handle that currently has the device grabbed (via the EVIOCGRAB ioctl). When a handle grabs a device it becomes the sole recipient for all input events coming from the device βœ‹
  • event_lock β€” this spinlock is taken when the input core receives and processes a new event for the device (in input_event). Code that accesses and/or modifies parameters of a device (such as keymap or absmin, absmax, absfuzz, etc.) after the device has been registered with the input core must take this lock πŸ”’
  • mutex β€” serializes calls to open, close and flush methods
  • users β€” stores number of users (input handlers) that opened this device. It is used by input_open_device and input_close_device to make sure that dev->open is only called when the first user opens the device and dev->close is called when the very last user closes the device
  • going_away β€” marks devices that are in the middle of unregistering and causes input_open_device and input_inhibit/uninhibit_device to fail with -ENODEV. it's giving farewell era πŸ‘‹
  • dev β€” driver model's view of this device
  • h_list β€” list of input handles associated with the device. When accessing the list, dev->mutex must be held
  • node β€” used to place the device onto input_dev_list
  • num_vals β€” number of values queued in the current frame
  • max_vals β€” maximum number of values queued in a frame
  • vals β€” array of values queued in the current frame
  • devres_managed β€” indicates that the device is managed with the devres framework and needs not be explicitly unregistered or freed. lazy girlie win ✨
  • timestamp β€” storage for a timestamp set by input_set_timestamp called by a driver
  • inhibited β€” indicates that the input device is inhibited. If that's the case then the input core ignores any events generated by the device. Device's close is called when it is being inhibited and its open is called when it is being uninhibited
  • ready β€” indicates that the device has been successfully opened and is prepared to process events (like LEDs or sounds) sent from the input core πŸ‘‘

πŸ” SEE ALSO

go read these next bestie, they're all in Kernel file ./include/linux/input.h:


okay that's the whole page πŸ¦‹ this came from ./include/linux, October 2026 edition β€” so if it's stale by the time you read it, not my fault bestie πŸ’œ slay, go write a driver πŸŽ€

πŸ“¦ where this page comes from