STRUCT INPUT_HANDLER(9)

💅 struct input_handler(9) — Kernel API Manual, but make it make sense 💅

okay so bestie, welcome to the Kernel API Manual entry for struct input_handler(9). This is the struct that implements one of interfaces for input devices — and yes, we’re keeping that phrase exactly, because the kernel said what it said 💀✨

---

🌸 NAME 🌸

struct input_handler — implements one of interfaces for input devices

---

✨ SYNOPSIS ✨

Here’s the whole struct, copied exactly so nobody comes for me:

struct input_handler {
    void *private;
    void (*event)(struct input_handle *handle, unsigned int type,
unsigned int code, int value);
    unsigned int (*events)(struct input_handle *handle, struct
input_value *vals, unsigned int count);
    bool (*filter)(struct input_handle *handle, unsigned int type,
unsigned int code, int value);
    bool (*match)(struct input_handler *handler, struct input_dev *dev);
    int (*connect)(struct input_handler *handler, struct input_dev *dev,
const struct input_device_id *id);
    void (*disconnect)(struct input_handle *handle);
    void (*start)(struct input_handle *handle);
    bool passive_observer;
    bool legacy_minors;
    int minor;
    const char *name;
    const struct input_device_id *id_table;
    struct list_head        h_list;
    struct list_head        node;
 };

🎀 Members 🎀

okay bestie, member-by-member, no skips, no crumbs:

• private — driver-specific data. literally the driver’s own little stash.
• event — event handler. This method is being called by input core with interrupts disabled and dev->event_lock spinlock held and so it may not sleep. Bestie, that means do not sleep here — this context is not giving nap time 😭.
• events — event sequence handler. This method is being called by input core with interrupts disabled and dev->event_lock spinlock held and so it may not sleep. The method must return number of events passed to it. So return the count, periodt.
• filter — similar to event; separates normal event handlers from "filters". It’s the vibe check between normal handlers and filters.
• match — called after comparing device’s id with handler’s id_table to perform fine-grained matching between device and handler. Fine-grained, no cap.
• connect — called when attaching a handler to an input device. the attach moment 🫶
• disconnect — disconnects a handler from input device. the un-attach moment 🙈
• start — starts handler for given handle. This function is called by input core when device is open and ready to process events, and also when device is uninhibited or when a process that "grabbed" a device releases it. main character energy for the handle ✨
• passive_observer — set to true by drivers only interested in observing data stream from devices if there are other users present. Such drivers will not result in starting underlying hardware device when input_open_device is called for their handles. just here to watch, not to wake the hardware 👀
• legacy_minors — set to true by drivers using legacy minor ranges. legacy era behavior 💅
• minor — beginning of range of 32 legacy minors for devices this driver can provide. 32 minors, iconic number.
• name — name of the handler, to be shown in /proc/bus/input/handlers. your handler’s government name 🎀
• id_table — pointer to a table of input_device_ids this driver can handle. the matchmaking table.
• h_list — list of input handles associated with the handler. the handle squad.
• node — for placing the driver onto input_handler_list. the driver’s spot on the list 🦋

---

🦋 Description 🦋

okay so here’s the vibe: Input handlers attach to input devices and create input handles. There are likely several handlers attached to any given input device at the same time. All of them will get their copy of input event generated by the device. Every single one, bestie — they each get their own copy, no cap. 💖

The very same structure is used to implement input filters. Input core allows filters to run first and will not pass event to regular handlers if any of the filters indicate that the event should be filtered (by returning true from their filter method). Filters get first dibs, and if they say no, the event does not pass go. 🚫✨

Note that input core serializes calls to connect and disconnect methods. So those calls are not out here doing chaos in parallel — input core keeps them in line. 💅

---

🌈 SEE ALSO 🌈

Kernel file ./include/linux/input.h is right there, plus struct input_value(9), struct input_dev(9), struct input_handle(9), input_set_events_per_packet(9), and struct ff_device(9). Go read them, bestie — they’re all part of the lore 💖

---

source/version: ./include/linux, dated October 2026 — page: struct input_handler(9) 💅✨🎀