kernel/linux.git/include/linux/input.h, branch v6.12.80

Input: fix regression when re-registering input handlers

2024-11-03T05:28:58+00:00

Commit d469647bafd9 ("Input: simplify event handling logic") introduced code that would set handler->events() method to either input_handler_events_filter() or input_handler_events_default() or input_handler_events_null(), depending on the kind of input handler (a filter or a regular one) we are dealing with. Unfortunately this breaks cases when we try to re-register the same filter (as is the case with sysrq handler): after initial registration the handler will have 2 event handling methods defined, and will run afoul of the check in input_handler_check_methods(): input: input_handler_check_methods: only one event processing method can be defined (sysrq) sysrq: Failed to register input handler, error -22 Fix this by adding handle_events() method to input_handle structure and setting it up when registering a new input handle according to event handling methods defined in associated input_handler structure, thus avoiding modifying the input_handler structure. Reported-by: "Ned T. Crigler" Reported-by: Christian Heusel Tested-by: "Ned T. Crigler" Tested-by: Peter Seiderer Fixes: d469647bafd9 ("Input: simplify event handling logic") Link: https://lore.kernel.org/r/Zx2iQp6csn42PJA7@xavtug Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov

Input: make events() method return number of events processed

2024-07-08T23:22:49+00:00

In preparation to consolidating filtering and event processing in the input core change events() method to return number of events processed by it. Reviewed-by: Jeff LaBundy Reviewed-by: Benjamin Tissoires Link: https://lore.kernel.org/r/20240703213756.3375978-4-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov

Input: make input_class constant

2024-03-10T21:38:04+00:00

Since commit 43a7206b0963 ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the input_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Suggested-by: Greg Kroah-Hartman Signed-off-by: Ricardo B. Marliere Link: https://lore.kernel.org/r/20240305-class_cleanup-input-v1-1-0c3d950c25db@marliere.net Signed-off-by: Dmitry Torokhov

Input: Annotate struct ff_device with __counted_by

2023-10-14T03:18:42+00:00

Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct ff_device. Signed-off-by: Kees Cook Reviewed-by: Gustavo A. R. Silva Link: https://lore.kernel.org/r/20231006201739.work.350-kees@kernel.org Signed-off-by: Dmitry Torokhov

Input: add input_copy_abs() function

2022-03-01T07:26:27+00:00

Add a new helper function to copy absinfo from one input_dev to another input_dev. This is useful to e.g. setup a pen/stylus input-device for combined touchscreen/pen hardware where the pen uses the same coordinates as the touchscreen. Suggested-by: Dmitry Torokhov Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20220131143539.109142-2-hdegoede@redhat.com Signed-off-by: Dmitry Torokhov

Input: Add "inhibited" property

2020-12-03T06:10:35+00:00

Userspace might want to implement a policy to temporarily disregard input from certain devices, including not treating them as wakeup sources. An example use case is a laptop, whose keyboard can be folded under the screen to create tablet-like experience. The user then must hold the laptop in such a way that it is difficult to avoid pressing the keyboard keys. It is therefore desirable to temporarily disregard input from the keyboard, until it is folded back. This obviously is a policy which should be kept out of the kernel, but the kernel must provide suitable means to implement such a policy. This patch adds a sysfs interface for exactly this purpose. To implement the said interface it adds an "inhibited" property to struct input_dev, and effectively creates four states a device can be in: closed uninhibited, closed inhibited, open uninhibited, open inhibited. It also defers calling driver's ->open() and ->close() to until they are actually needed, e.g. it makes no sense to prepare the underlying device for generating events (->open()) if the device is inhibited. uninhibit closed <------------ closed uninhibited ------------> inhibited | ^ inhibit | ^ 1st | | 1st | | open | | open | | | | | | | | last | | last | | close | | close v | uninhibit v | open <------------ open uninhibited ------------> inhibited The top inhibit/uninhibit transition happens when users == 0. The bottom inhibit/uninhibit transition happens when users > 0. The left open/close transition happens when !inhibited. The right open/close transition happens when inhibited. Due to all transitions being serialized with dev->mutex, it is impossible to have "diagonal" transitions between closed uninhibited and open inhibited or between open uninhibited and closed inhibited. No new callbacks are added to drivers, because their open() and close() serve exactly the purpose to tell the driver to start/stop providing events to the input core. Consequently, open() and close() - if provided - are called in both inhibit and uninhibit paths. Signed-off-by: Patrik Fimml Co-developed-by: Andrzej Pietrasiewicz Signed-off-by: Andrzej Pietrasiewicz Link: https://lore.kernel.org/r/20200608112211.12125-8-andrzej.p@collabora.com Signed-off-by: Dmitry Torokhov

Input: add input_device_enabled()

2020-12-03T06:10:31+00:00

A helper function for drivers to decide if the device is used or not. A lockdep check is introduced as inspecting ->users should be done under input device's mutex. Signed-off-by: Andrzej Pietrasiewicz Link: https://lore.kernel.org/r/20200608112211.12125-2-andrzej.p@collabora.com Signed-off-by: Dmitry Torokhov

Input: add input_get_poll_interval()

2019-10-04T19:31:46+00:00

Some drivers need to be able to know the current polling interval for devices working in polling mode, let's allow them fetching it. Acked-By: Benjamin Tissoires Tested-by: Michal Vokáč Signed-off-by: Dmitry Torokhov

Input: add support for polling to input devices

2019-08-20T19:04:07+00:00

Separating "normal" and "polled" input devices was a mistake, as often we want to allow the very same device work on both interrupt-driven and polled mode, depending on the board on which the device is used. This introduces new APIs: - input_setup_polling - input_set_poll_interval - input_set_min_poll_interval - input_set_max_poll_interval These new APIs allow switching an input device into polled mode with sysfs attributes matching drivers using input_polled_dev APIs that will be eventually removed. Tested-by: Michal Vokáč Acked-by: Benjamin Tissoires Signed-off-by: Dmitry Torokhov

Input: allow drivers specify timestamp for input events

2019-07-25T08:12:20+00:00

Currently, evdev stamps events with timestamps acquired in evdev_events() However, this timestamping may not be accurate in terms of measuring when the actual event happened. Let's allow individual drivers specify timestamp in order to provide a more accurate sense of time for the event. It is expected that drivers will set the timestamp in their hard interrupt routine. Signed-off-by: Atif Niyaz Signed-off-by: Dmitry Torokhov