[RFC PATCH 0/6] Input: New EV_BTN event for generic buttons

[RFC PATCH 0/6] Input: New EV_BTN event for generic buttons

[Tomasz Pakuła]

This patch series adds EV_BTN and it's handling to the input system. It's main
focus is to add a simple event for generic buttons, not relying on defined
usages and meanings.

Joysticks unlike keyboards, mice and even gamepads (though that's debatable)
define arbitrary number of buttons that don't mean anything. They can be used
in any kind of software, but mainly games, by assigning them manually to
functions. Some games even carry default presets for devices based on their USB
VID:PID pairs.

The more important issue that this is trying to solve is the longstanding
problem of limited button support in Linux. The use for arbitrary number of
buttons wasn't considered some 20 years ago because Linux wasn't a good platform
for gaming. First, Joystick and Gamepad ranges were limited to 16 buttons, later
extended by 40 additional usages in the TRIGGER_HAPPY range. By allowing the
usages to be incremented up to KEY_MAX, Joysticks were able to expose up to 80
buttons for the past 15 years or so.

Many simracing, simflight etc. devices actually expose way more then that. 128
is a pretty common number with even more in the wild. Usually the numbers get so
big to support things like positional rotary switches as one such rotary can
have 12+ positions. My Moza GS V2P wheel has 5 such rotaries and that's not
counting other buttons.

Doing something about this limit was brought up maaany times in the past:
https://forums.x-plane.org/forums/topic/299033-xp12-linux-winwing-orion-2-throttle-has-too-many-buttons/?page=1
https://forum.falcon-bms.com/topic/26403/solved-winwing-orion-2-on-linux-only-80-buttons-detected
https://lore.kernel.org/linux-input/CACa7zynMpa3BOJUW=s_Tj1TwH5txDQOuta5Fph45PYhDOtQQ3g@mail.gmail.com/
https://lore.kernel.org/linux-input/20200710065112.18286-1-cpuwolf@gmail.com/#r
https://lore.kernel.org/linux-input/20240802201001.406898-1-tomasz.pakula.oficjalny@gmail.com/
https://lore.kernel.org/linux-input/20250201113906.769162-11-tomasz.pakula.oficjalny@gmail.com/
https://lore.kernel.org/linux-input/20251119163844.1343-1-Hunter.Moore@garmin.com/
https://lore.kernel.org/linux-input/20251220194100.GA12646@altimeter-info/
https://lore.kernel.org/linux-input/665df7c9-0d32-4ecd-9f4d-fff67deb5878@endrift.com/

But some considerations:

1. Usages have their actual meanings and we shouldn't use them willy-nilly to add
more buttons, even if that approach works with naive approaches use by SDL and
Wine alike.

2. Extending the KEY_MAX will cause additional issues when it comes to bitmask
sizes, mapping usages and reading them afterward. Basically, we're moving the
goalpost somewhere, but a device that would define 1024 buttons would break
things again.

I must give HUGE thanks to Dmitry for forcing this into my head to a point where
I actually understood the whole issue.

Thus, I thought up of a best, long-term solution to this problem. I do think
EV_BTN should be a first-class event so it can be as easy to handle as possible.
If there's a need, it could be hooked up for Gamepads as well as HID gamepads do
the same thing and only expose raw buttons without specific usages. The usages
are a best guess when handling generic ones and only custom drivers can actually
assign proper buttons like BTN_A, THUMBL etc.

In the future, the Joystick usages could be completely removed and joysticks
could rely ONLY on the new event. For now, the old way is kept to not break
compatibility.

I'm eagerly waiting for comments, recommendations and critique. Currently, there
isn't a way to poll states of all buttons like with EVIOCGKEY but I'm not sure
if it's needed? I added INPUT_MAX_KEYS just for some sane limits BUT I don't see
a real use for it. Instead of this define, we could just use U16_MAX. 65k of
buttons ought to be enough for ANYBODY :D

Companion changes to consumers that already show the working state of this patch series:
Wine: https://gitlab.winehq.org/wine/wine/-/merge_requests/9853
SDL: https://github.com/libsdl-org/SDL/pull/14758
evtest: https://gitlab.freedesktop.org/libevdev/evtest/-/merge_requests/25

Tested with my Moza Racing R9 and Moza Universal Hub (both expose 128 usable
buttons). hid-universal-pidff driver was disabled for testing as it contains
usage range hack.

Sneak peek from updated evtest:

Event: time 1767559522.509446, type 6 (EV_BTN), button 12, value 1
Event: time 1767559522.509446, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9000c
Event: time 1767559522.509446, type 1 (EV_KEY), code 299 (BTN_BASE6), value 1
Event: time 1767559522.509446, -------------- SYN_REPORT ------------
Event: time 1767559522.656447, type 6 (EV_BTN), button 12, value 0
Event: time 1767559522.656447, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9000c
Event: time 1767559522.656447, type 1 (EV_KEY), code 299 (BTN_BASE6), value 0
Event: time 1767559522.656447, -------------- SYN_REPORT ------------
Event: time 1767559523.737498, type 6 (EV_BTN), button 112, value 1
Event: time 1767559523.737498, -------------- SYN_REPORT ------------
Event: time 1767559523.807477, type 6 (EV_BTN), button 112, value 0
Event: time 1767559523.807477, -------------- SYN_REPORT ------------

Tomasz Pakuła (6):
  Input: Introduce EV_BTN event for generic buttons
  Input: Add info about EV_BTN
  Input: Fire EV_BTN if found in ev_bit
  Input: Assign EV_BTN event to HID Joysticks
  Input: Realign rest of the HID_UP_BUTTON cases
  Input: Add EVIOCGBTNCNT

 Documentation/input/event-codes.rst    |  5 ++
 drivers/hid/hid-input.c                | 77 +++++++++++++++++---------
 drivers/input/evdev.c                  |  5 ++
 drivers/input/input.c                  | 10 ++++
 include/linux/input.h                  |  4 ++
 include/uapi/linux/input-event-codes.h |  1 +
 include/uapi/linux/input.h             |  1 +
 7 files changed, 77 insertions(+), 26 deletions(-)

--
2.52.0

[RFC PATCH 1/6] Input: Introduce EV_BTN event for generic buttons

[Tomasz Pakuła]

This will be used to fire generic button events that only transmit
button number and it's value, not related to any defined usage.

Made for HID joysticks but could be adopted by other devices.

Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
---
 Documentation/input/event-codes.rst    | 5 +++++
 include/uapi/linux/input-event-codes.h | 1 +
 2 files changed, 6 insertions(+)

diff --git a/Documentation/input/event-codes.rst b/Documentation/input/event-codes.rst
index 4424cbff251f..c387eaa63dfb 100644
--- a/Documentation/input/event-codes.rst
+++ b/Documentation/input/event-codes.rst
@@ -59,6 +59,11 @@ Codes section for details on valid codes for each type.
 
   - Used to describe binary state input switches.
 
+* EV_BTN:
+
+  - Used to describe state changes generic, numbered buttons without defined
+    usages.
+
 * EV_LED:
 
   - Used to turn LEDs on devices on and off.
diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h
index 30f3c9eaafaa..1c853c37b58a 100644
--- a/include/uapi/linux/input-event-codes.h
+++ b/include/uapi/linux/input-event-codes.h
@@ -42,6 +42,7 @@
 #define EV_ABS			0x03
 #define EV_MSC			0x04
 #define EV_SW			0x05
+#define EV_BTN			0x06
 #define EV_LED			0x11
 #define EV_SND			0x12
 #define EV_REP			0x14
-- 
2.52.0

[RFC PATCH 2/6] Input: Add info about EV_BTN

[Tomasz Pakuła]

Add necessary bits to modalias etc. Store the number of buttons.

Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
---
 drivers/input/input.c | 10 ++++++++++
 include/linux/input.h |  2 ++
 2 files changed, 12 insertions(+)

diff --git a/drivers/input/input.c b/drivers/input/input.c
index a500e1e276c2..e926327443bb 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -258,6 +258,10 @@ static int input_get_disposition(struct input_dev *dev,
 		}
 		break;
 
+	case EV_BTN:
+		disposition = INPUT_PASS_TO_HANDLERS;
+		break;
+
 	case EV_ABS:
 		if (is_event_supported(code, dev->absbit, ABS_MAX))
 			disposition = input_handle_abs_event(dev, code, &value);
@@ -1124,6 +1128,8 @@ static int input_devices_seq_show(struct seq_file *seq, void *v)
 		input_seq_print_bitmap(seq, "FF", dev->ffbit, FF_MAX);
 	if (test_bit(EV_SW, dev->evbit))
 		input_seq_print_bitmap(seq, "SW", dev->swbit, SW_MAX);
+	if (test_bit(EV_BTN, dev->evbit))
+		seq_printf(seq, "I: BTN=%u\n", dev->button_count);
 
 	seq_putc(seq, '\n');
 
@@ -1347,6 +1353,7 @@ static int input_print_modalias_parts(char *buf, int size, int full_len,
 				'f', id->ffbit, 0, FF_MAX);
 	len += input_print_modalias_bits(buf + len, size - len,
 				'w', id->swbit, 0, SW_MAX);
+	len += snprintf(buf + len, size - len, "t%u", id->button_count);
 
 	return len;
 }
@@ -1679,6 +1686,8 @@ static int input_dev_uevent(const struct device *device, struct kobj_uevent_env
 		INPUT_ADD_HOTPLUG_BM_VAR("FF=", dev->ffbit, FF_MAX);
 	if (test_bit(EV_SW, dev->evbit))
 		INPUT_ADD_HOTPLUG_BM_VAR("SW=", dev->swbit, SW_MAX);
+	if (test_bit(EV_BTN, dev->evbit))
+		INPUT_ADD_HOTPLUG_VAR("BTN=%u", dev->button_count);
 
 	INPUT_ADD_HOTPLUG_MODALIAS_VAR(dev);
 
@@ -2113,6 +2122,7 @@ void input_set_capability(struct input_dev *dev, unsigned int type, unsigned int
 		break;
 
 	case EV_PWR:
+	case EV_BTN:
 		/* do nothing */
 		break;
 
diff --git a/include/linux/input.h b/include/linux/input.h
index 7d7cb0593a63..f6389de4a4d1 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -59,6 +59,7 @@ enum input_clock_type {
  * @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
+ * @button_count: number of generic buttons 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). Used by
  *	event handlers to estimate size of the buffer needed to hold
@@ -152,6 +153,7 @@ struct input_dev {
 	unsigned long ffbit[BITS_TO_LONGS(FF_CNT)];
 	unsigned long swbit[BITS_TO_LONGS(SW_CNT)];
 
+	unsigned int button_count;
 	unsigned int hint_events_per_packet;
 
 	unsigned int keycodemax;
-- 
2.52.0

[RFC PATCH 3/6] Input: Fire EV_BTN if found in ev_bit

[Tomasz Pakuła]

Passes EV_BTN through to handlers and allows reacting to this event by
clients.

Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
---
 drivers/hid/hid-input.c | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 2bbb645c2ff4..900a6fc9813e 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -1673,7 +1673,8 @@ void hidinput_hid_event(struct hid_device *hid, struct hid_field *field, struct
 
 	switch (usage->type) {
 	case EV_KEY:
-		if (usage->code == 0) /* Key 0 is "unassigned", not KEY_UNKNOWN */
+		/* Key 0 is "unassigned", not KEY_UNKNOWN */
+		if (usage->code == 0 && !test_bit(EV_BTN, input->evbit))
 			return;
 		break;
 
@@ -1723,10 +1724,19 @@ void hidinput_hid_event(struct hid_device *hid, struct hid_field *field, struct
 	    value == field->value[usage->usage_index])
 		return;
 
-	/* report the usage code as scancode if the key status has changed */
-	if (usage->type == EV_KEY &&
-	    (!test_bit(usage->code, input->key)) == value)
-		input_event(input, EV_MSC, MSC_SCAN, usage->hid);
+
+	if (usage->type == EV_KEY) {
+		/* Send out EV_BTN with button number (starts at 1) */
+		if (test_bit(EV_BTN, input->evbit))
+			input_event(input, EV_BTN, usage->hid & HID_USAGE, value);
+
+		if (usage->code == 0)
+			return;
+
+		/* report usage code as scancode if the status has changed */
+		if ((!test_bit(usage->code, input->key)) == value)
+			input_event(input, EV_MSC, MSC_SCAN, usage->hid);
+	}
 
 	input_event(input, usage->type, usage->code, value);
 
-- 
2.52.0

[RFC PATCH 4/6] Input: Assign EV_BTN event to HID Joysticks

[Tomasz Pakuła]

Joysticks will now fire EV_BTN for every of their buttons, even buttons
that were previously ignored because they were cut off by KEY_MAX. This
in turns enables joysticks to finally report buttons above 80 which was
the previous limitation.

Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
---
 drivers/hid/hid-input.c | 27 +++++++++++++++++++++------
 include/linux/input.h   |  2 ++
 2 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 900a6fc9813e..1c11077b1577 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -760,11 +760,15 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
 		case HID_GD_MOUSE:
 		case HID_GD_POINTER:  code += BTN_MOUSE; break;
 		case HID_GD_JOYSTICK:
-				if (code <= 0xf)
-					code += BTN_JOYSTICK;
-				else
-					code += BTN_TRIGGER_HAPPY - 0x10;
-				break;
+			if (input->button_count >= INPUT_MAX_BUTTONS)
+				goto ignore;
+
+			code += BTN_JOYSTICK;
+			if (code > BTN_DEAD)
+				code += BTN_TRIGGER_HAPPY - BTN_DEAD - 1;
+			if (code > KEY_MAX)
+				code = KEY_RESERVED;
+			break;
 		case HID_GD_GAMEPAD:
 				if (code <= 0xf)
 					code += BTN_GAMEPAD;
@@ -1379,7 +1383,6 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
 	}
 
 	set_bit(usage->type, input->evbit);
-
 	/*
 	 * This part is *really* controversial:
 	 * - HID aims at being generic so we should do our best to export
@@ -1390,12 +1393,18 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
 	 *   *_MISC+N to overwrite a legitimate even, which confuses userspace
 	 *   (for instance ABS_MISC + 7 is ABS_MT_SLOT, which has a different
 	 *   processing)
+	 * - Joysticks can have arbitrary number of buttons without defined
+	 *   usages. Buttons that extend beyond KEY_MAX are assigned to
+	 *   KEY_RESERVED thus deduplication must be disabled for them.
 	 *
 	 * If devices still want to use this (at their own risk), they will
 	 * have to use the quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE, but
 	 * the default should be a reliable mapping.
 	 */
 	while (usage->code <= max && test_and_set_bit(usage->code, bit)) {
+		if (field->application == HID_GD_JOYSTICK && usage->code == KEY_RESERVED)
+			break;
+
 		if (device->quirks & HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE) {
 			usage->code = find_next_zero_bit(bit,
 							 max + 1,
@@ -1455,6 +1464,12 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
 	if (usage->type == EV_KEY) {
 		set_bit(EV_MSC, input->evbit);
 		set_bit(MSC_SCAN, input->mscbit);
+
+		if (field->application == HID_GD_JOYSTICK &&
+		    (usage->hid & HID_USAGE_PAGE) == HID_UP_BUTTON) {
+			set_bit(EV_BTN, input->evbit);
+			++input->button_count;
+		}
 	}
 
 	return;
diff --git a/include/linux/input.h b/include/linux/input.h
index f6389de4a4d1..7f39c663fa85 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -214,6 +214,8 @@ struct input_dev {
 };
 #define to_input_dev(d) container_of(d, struct input_dev, dev)
 
+#define INPUT_MAX_BUTTONS 2048 /* A sane limit of supported device buttons */
+
 /*
  * Verify that we are in sync with input_device_id mod_devicetable.h #defines
  */
-- 
2.52.0

[RFC PATCH 5/6] Input: Realign rest of the HID_UP_BUTTON cases

[Tomasz Pakuła]

The switch statement here had too much indentation.

Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
---
 drivers/hid/hid-input.c | 30 +++++++++++++++---------------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 1c11077b1577..9542829de234 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -770,22 +770,22 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
 				code = KEY_RESERVED;
 			break;
 		case HID_GD_GAMEPAD:
-				if (code <= 0xf)
-					code += BTN_GAMEPAD;
-				else
-					code += BTN_TRIGGER_HAPPY - 0x10;
-				break;
+			if (code <= 0xf)
+				code += BTN_GAMEPAD;
+			else
+				code += BTN_TRIGGER_HAPPY - 0x10;
+			break;
 		case HID_CP_CONSUMER_CONTROL:
-				if (hidinput_field_in_collection(device, field,
-								 HID_COLLECTION_NAMED_ARRAY,
-								 HID_CP_PROGRAMMABLEBUTTONS)) {
-					if (code <= 0x1d)
-						code += KEY_MACRO1;
-					else
-						code += BTN_TRIGGER_HAPPY - 0x1e;
-					break;
-				}
-				fallthrough;
+			if (hidinput_field_in_collection(device, field,
+							 HID_COLLECTION_NAMED_ARRAY,
+							 HID_CP_PROGRAMMABLEBUTTONS)) {
+				if (code <= 0x1d)
+					code += KEY_MACRO1;
+				else
+					code += BTN_TRIGGER_HAPPY - 0x1e;
+				break;
+			}
+			fallthrough;
 		default:
 			switch (field->physical) {
 			case HID_GD_MOUSE:
-- 
2.52.0

[RFC PATCH 6/6] Input: Add EVIOCGBTNCNT

[Tomasz Pakuła]

Allow userspace to get the button count of input
devices. currently only used for Joysticks which
includes Simracing and Simflight hardware. Such
devices are always defined as generic joysticks.

Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
---
 drivers/input/evdev.c      | 5 +++++
 include/uapi/linux/input.h | 1 +
 2 files changed, 6 insertions(+)

diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index 90ff6be85cf4..b90dc035c0b3 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -1134,6 +1134,11 @@ static long evdev_do_ioctl(struct file *file, unsigned int cmd,
 
 	case EVIOCSKEYCODE_V2:
 		return evdev_handle_set_keycode_v2(dev, p);
+
+	case EVIOCGBTNCNT:
+		if (copy_to_user(p, &dev->button_count, sizeof(unsigned int)))
+			return -EFAULT;
+		return 0;
 	}
 
 	size = _IOC_SIZE(cmd);
diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
index 6aa703fcfcfb..3d1b17ebcdfc 100644
--- a/include/uapi/linux/input.h
+++ b/include/uapi/linux/input.h
@@ -174,6 +174,7 @@ struct input_mask {
 #define EVIOCGLED(len)		_IOC(_IOC_READ, 'E', 0x19, len)		/* get all LEDs */
 #define EVIOCGSND(len)		_IOC(_IOC_READ, 'E', 0x1a, len)		/* get all sounds status */
 #define EVIOCGSW(len)		_IOC(_IOC_READ, 'E', 0x1b, len)		/* get all switch states */
+#define EVIOCGBTNCNT		_IOR('E', 0x1c, unsigned int)		/* get button count */
 
 #define EVIOCGBIT(ev,len)	_IOC(_IOC_READ, 'E', 0x20 + (ev), len)	/* get event bits */
 #define EVIOCGABS(abs)		_IOR('E', 0x40 + (abs), struct input_absinfo)	/* get abs value/limits */
-- 
2.52.0

Re: [RFC PATCH 1/6] Input: Introduce EV_BTN event for generic buttons

[Randy Dunlap]

Hi--

On 1/4/26 1:31 PM, Tomasz Pakuła wrote:
> This will be used to fire generic button events that only transmit
> button number and it's value, not related to any defined usage.

                    its

> 
> Made for HID joysticks but could be adopted by other devices.
> 
> Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
> ---
>  Documentation/input/event-codes.rst    | 5 +++++
>  include/uapi/linux/input-event-codes.h | 1 +
>  2 files changed, 6 insertions(+)
> 
> diff --git a/Documentation/input/event-codes.rst b/Documentation/input/event-codes.rst
> index 4424cbff251f..c387eaa63dfb 100644
> --- a/Documentation/input/event-codes.rst
> +++ b/Documentation/input/event-codes.rst
> @@ -59,6 +59,11 @@ Codes section for details on valid codes for each type.
>  
>    - Used to describe binary state input switches.
>  
> +* EV_BTN:
> +
> +  - Used to describe state changes generic, numbered buttons without defined

                              changes to generic,

> +    usages.
> +
>  * EV_LED:
>  
>    - Used to turn LEDs on devices on and off.


-- 
~Randy

Re: [RFC PATCH 0/6] Input: New EV_BTN event for generic buttons

[Ivan Gorinov]

On Sun, Jan 04, 2026 at 10:31:26PM +0100, Tomasz Pakuła wrote:

> I'm eagerly waiting for comments, recommendations and critique. Currently, there
> isn't a way to poll states of all buttons like with EVIOCGKEY but I'm not sure
> if it's needed? I added INPUT_MAX_KEYS just for some sane limits BUT I don't see
> a real use for it. Instead of this define, we could just use U16_MAX. 65k of
> buttons ought to be enough for ANYBODY :D

If I understand correctly, EVIOCGKEY is the only way to read initial state of buttons
and switches when the input device is opened with /dev/input/event# interface.

Legacy /dev/input/js# interface sends those initial states immediately after openeing
as JS_EVENT_BUTTON | JS_EVENT_INIT event type.

Re: [RFC PATCH 0/6] Input: New EV_BTN event for generic buttons

[Peter Hutterer]

On Sun, Jan 04, 2026 at 10:31:26PM +0100, Tomasz Pakuła wrote:
> This patch series adds EV_BTN and it's handling to the input system. It's main
> focus is to add a simple event for generic buttons, not relying on defined
> usages and meanings.
> 
> Joysticks unlike keyboards, mice and even gamepads (though that's debatable)
> define arbitrary number of buttons that don't mean anything. They can be used
> in any kind of software, but mainly games, by assigning them manually to
> functions. Some games even carry default presets for devices based on their USB
> VID:PID pairs.
> 
> The more important issue that this is trying to solve is the longstanding
> problem of limited button support in Linux. The use for arbitrary number of
> buttons wasn't considered some 20 years ago because Linux wasn't a good platform
> for gaming. First, Joystick and Gamepad ranges were limited to 16 buttons, later
> extended by 40 additional usages in the TRIGGER_HAPPY range. By allowing the
> usages to be incremented up to KEY_MAX, Joysticks were able to expose up to 80
> buttons for the past 15 years or so.
> 
> Many simracing, simflight etc. devices actually expose way more then that. 128
> is a pretty common number with even more in the wild. Usually the numbers get so
> big to support things like positional rotary switches as one such rotary can
> have 12+ positions. My Moza GS V2P wheel has 5 such rotaries and that's not
> counting other buttons.
> 
> Doing something about this limit was brought up maaany times in the past:
> https://forums.x-plane.org/forums/topic/299033-xp12-linux-winwing-orion-2-throttle-has-too-many-buttons/?page=1
> https://forum.falcon-bms.com/topic/26403/solved-winwing-orion-2-on-linux-only-80-buttons-detected
> https://lore.kernel.org/linux-input/CACa7zynMpa3BOJUW=s_Tj1TwH5txDQOuta5Fph45PYhDOtQQ3g@mail.gmail.com/
> https://lore.kernel.org/linux-input/20200710065112.18286-1-cpuwolf@gmail.com/#r
> https://lore.kernel.org/linux-input/20240802201001.406898-1-tomasz.pakula.oficjalny@gmail.com/
> https://lore.kernel.org/linux-input/20250201113906.769162-11-tomasz.pakula.oficjalny@gmail.com/
> https://lore.kernel.org/linux-input/20251119163844.1343-1-Hunter.Moore@garmin.com/
> https://lore.kernel.org/linux-input/20251220194100.GA12646@altimeter-info/
> https://lore.kernel.org/linux-input/665df7c9-0d32-4ecd-9f4d-fff67deb5878@endrift.com/
> 
> But some considerations:
> 
> 1. Usages have their actual meanings and we shouldn't use them willy-nilly to add
> more buttons, even if that approach works with naive approaches use by SDL and
> Wine alike.

fwiw, we *already* add those usages willy-nilly for a rather large
proportion of devices. any HID device with the Button usage page will
convert from HID button 4 to BTN_SIDE and then the rest of the stack
pretends this was a conscious choice. Which leads to hilarities that
BTN_SIDE is actually the back button and BTN_BACK is just... button 7
(or button 11 thanks to X11 history). Which then again leads to
hilarities that sending BTN_BACK to indicate a back action may or may
not have an effect, I recently had a bug like this in mutter/gtk's tablet
handling. IOW, it's quite messy anyway.

So what I (think I) would like is to use EV_BTN in addition with EV_KEY
to signal purely numbered buttons but *also* which buttons have the
exact semantic meaning. The logic becomes:

If an EV_KEY $code is just a numbered button it *also* sends EV_BTN
$number. 
If an EV_KEY $code is a fixed semantic meaning (e.g. BTN_BACK) it does
*not* send an EV_BTN $number.

Then we can have a mapping in the device that maps from EV_BTN to EV_KEY
code, obtained via some EVIOCBTNKEYCODE() ioctl. The hypothetical
example of a device with 3 numbered buttons and a fixed BTN_BACK would
be: EV_BTN count of 3, EV_KEY bits for left/middle/right and back.

nbuttons = EVIOCBTNCNT()
EVIOCBTNKEYCODE(0, nbuttons) returns [BTN_LEFT, BTN_RIGHT, BTN_MIDDLE]

A sequence with right and back down would look like this:

Event: time 1767559522.509446, type 6 (EV_BTN), button 2, value 1
Event: time 1767559522.509446, type 6 (EV_KEY), code 0x110 (BTN_RIGHT), value 1
Event: time 1767559522.509446, type 6 (EV_KEY), code 0x110 (BTN_BACK), value 1
Event: time 1767559522.509446, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9000c
Event: time 1767559522.509446, -------------- SYN_REPORT ------------

And userspace can ignore BTN_RIGHT thanks to that mapping but BTN_BACK
retains its semantic meaning. This is flexible enough even though I'm
not sure how many devices will mix the two.

Does that make sense?

Cheers,
  Peter


> 2. Extending the KEY_MAX will cause additional issues when it comes to bitmask
> sizes, mapping usages and reading them afterward. Basically, we're moving the
> goalpost somewhere, but a device that would define 1024 buttons would break
> things again.
> 
> I must give HUGE thanks to Dmitry for forcing this into my head to a point where
> I actually understood the whole issue.
> 
> Thus, I thought up of a best, long-term solution to this problem. I do think
> EV_BTN should be a first-class event so it can be as easy to handle as possible.
> If there's a need, it could be hooked up for Gamepads as well as HID gamepads do
> the same thing and only expose raw buttons without specific usages. The usages
> are a best guess when handling generic ones and only custom drivers can actually
> assign proper buttons like BTN_A, THUMBL etc.
> 
> In the future, the Joystick usages could be completely removed and joysticks
> could rely ONLY on the new event. For now, the old way is kept to not break
> compatibility.
> 
> I'm eagerly waiting for comments, recommendations and critique. Currently, there
> isn't a way to poll states of all buttons like with EVIOCGKEY but I'm not sure
> if it's needed? I added INPUT_MAX_KEYS just for some sane limits BUT I don't see
> a real use for it. Instead of this define, we could just use U16_MAX. 65k of
> buttons ought to be enough for ANYBODY :D
> 
> Companion changes to consumers that already show the working state of this patch series:
> Wine: https://gitlab.winehq.org/wine/wine/-/merge_requests/9853
> SDL: https://github.com/libsdl-org/SDL/pull/14758
> evtest: https://gitlab.freedesktop.org/libevdev/evtest/-/merge_requests/25
> 
> Tested with my Moza Racing R9 and Moza Universal Hub (both expose 128 usable
> buttons). hid-universal-pidff driver was disabled for testing as it contains
> usage range hack.
> 
> Sneak peek from updated evtest:
> 
> Event: time 1767559522.509446, type 6 (EV_BTN), button 12, value 1
> Event: time 1767559522.509446, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9000c
> Event: time 1767559522.509446, type 1 (EV_KEY), code 299 (BTN_BASE6), value 1
> Event: time 1767559522.509446, -------------- SYN_REPORT ------------
> Event: time 1767559522.656447, type 6 (EV_BTN), button 12, value 0
> Event: time 1767559522.656447, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9000c
> Event: time 1767559522.656447, type 1 (EV_KEY), code 299 (BTN_BASE6), value 0
> Event: time 1767559522.656447, -------------- SYN_REPORT ------------
> Event: time 1767559523.737498, type 6 (EV_BTN), button 112, value 1
> Event: time 1767559523.737498, -------------- SYN_REPORT ------------
> Event: time 1767559523.807477, type 6 (EV_BTN), button 112, value 0
> Event: time 1767559523.807477, -------------- SYN_REPORT ------------
> 
> Tomasz Pakuła (6):
>   Input: Introduce EV_BTN event for generic buttons
>   Input: Add info about EV_BTN
>   Input: Fire EV_BTN if found in ev_bit
>   Input: Assign EV_BTN event to HID Joysticks
>   Input: Realign rest of the HID_UP_BUTTON cases
>   Input: Add EVIOCGBTNCNT
> 
>  Documentation/input/event-codes.rst    |  5 ++
>  drivers/hid/hid-input.c                | 77 +++++++++++++++++---------
>  drivers/input/evdev.c                  |  5 ++
>  drivers/input/input.c                  | 10 ++++
>  include/linux/input.h                  |  4 ++
>  include/uapi/linux/input-event-codes.h |  1 +
>  include/uapi/linux/input.h             |  1 +
>  7 files changed, 77 insertions(+), 26 deletions(-)
> 
> --
> 2.52.0
> 

Re: [RFC PATCH 3/6] Input: Fire EV_BTN if found in ev_bit

[Benjamin Tissoires]

On Jan 04 2026, Tomasz Pakuła wrote:
> Passes EV_BTN through to handlers and allows reacting to this event by
> clients.
> 
> Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
> ---
>  drivers/hid/hid-input.c | 20 +++++++++++++++-----
>  1 file changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index 2bbb645c2ff4..900a6fc9813e 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -1673,7 +1673,8 @@ void hidinput_hid_event(struct hid_device *hid, struct hid_field *field, struct
>  
>  	switch (usage->type) {
>  	case EV_KEY:
> -		if (usage->code == 0) /* Key 0 is "unassigned", not KEY_UNKNOWN */
> +		/* Key 0 is "unassigned", not KEY_UNKNOWN */
> +		if (usage->code == 0 && !test_bit(EV_BTN, input->evbit))
>  			return;
>  		break;
>  
> @@ -1723,10 +1724,19 @@ void hidinput_hid_event(struct hid_device *hid, struct hid_field *field, struct
>  	    value == field->value[usage->usage_index])
>  		return;
>  
> -	/* report the usage code as scancode if the key status has changed */
> -	if (usage->type == EV_KEY &&
> -	    (!test_bit(usage->code, input->key)) == value)
> -		input_event(input, EV_MSC, MSC_SCAN, usage->hid);
> +
> +	if (usage->type == EV_KEY) {
> +		/* Send out EV_BTN with button number (starts at 1) */
> +		if (test_bit(EV_BTN, input->evbit))
> +			input_event(input, EV_BTN, usage->hid & HID_USAGE, value);

In addition to what Peter said, this seems to be a lot more convoluted
than what it needs to be.

The one nice thing about the EV_BTN is that is transfers the intend of
"this is a buttons with no particular meaning". And that's exactly what
the HID usage page "button" is.

So why not:
- whenever there are buttons from the HID usage page button -> map them
	to EV_BTN
- only map EV_BTN to usage page Button (to prevent weird things
	happening with keyboards)
- keep doing the weird mapping in HID we do but do not upper bound the
	EV_KEY like we do (first hunk in this patch), and store the mapping
	EV_BTN/EV_KEY in the input/evdev subsystem, not in HID
- on the HID side, we fire just the EV_BTN for button usage page, and
	input does the backward compatibility.
- the backward compatibility needs to be in the input side of things so
	we can add the new ioctls Peter was mentioning.

Cheers,
Benjamin

> +
> +		if (usage->code == 0)
> +			return;
> +
> +		/* report usage code as scancode if the status has changed */
> +		if ((!test_bit(usage->code, input->key)) == value)
> +			input_event(input, EV_MSC, MSC_SCAN, usage->hid);
> +	}
>  
>  	input_event(input, usage->type, usage->code, value);
>  
> -- 
> 2.52.0
> 

Re: [RFC PATCH 4/6] Input: Assign EV_BTN event to HID Joysticks

[Benjamin Tissoires]

On Jan 04 2026, Tomasz Pakuła wrote:
> Joysticks will now fire EV_BTN for every of their buttons, even buttons
> that were previously ignored because they were cut off by KEY_MAX. This
> in turns enables joysticks to finally report buttons above 80 which was
> the previous limitation.
> 
> Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
> ---
>  drivers/hid/hid-input.c | 27 +++++++++++++++++++++------
>  include/linux/input.h   |  2 ++
>  2 files changed, 23 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index 900a6fc9813e..1c11077b1577 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -760,11 +760,15 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
>  		case HID_GD_MOUSE:
>  		case HID_GD_POINTER:  code += BTN_MOUSE; break;
>  		case HID_GD_JOYSTICK:
> -				if (code <= 0xf)
> -					code += BTN_JOYSTICK;
> -				else
> -					code += BTN_TRIGGER_HAPPY - 0x10;
> -				break;
> +			if (input->button_count >= INPUT_MAX_BUTTONS)
> +				goto ignore;
> +
> +			code += BTN_JOYSTICK;
> +			if (code > BTN_DEAD)
> +				code += BTN_TRIGGER_HAPPY - BTN_DEAD - 1;
> +			if (code > KEY_MAX)
> +				code = KEY_RESERVED;
> +			break;
>  		case HID_GD_GAMEPAD:
>  				if (code <= 0xf)
>  					code += BTN_GAMEPAD;
> @@ -1379,7 +1383,6 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
>  	}
>  
>  	set_bit(usage->type, input->evbit);
> -
>  	/*
>  	 * This part is *really* controversial:
>  	 * - HID aims at being generic so we should do our best to export
> @@ -1390,12 +1393,18 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
>  	 *   *_MISC+N to overwrite a legitimate even, which confuses userspace
>  	 *   (for instance ABS_MISC + 7 is ABS_MT_SLOT, which has a different
>  	 *   processing)
> +	 * - Joysticks can have arbitrary number of buttons without defined
> +	 *   usages. Buttons that extend beyond KEY_MAX are assigned to
> +	 *   KEY_RESERVED thus deduplication must be disabled for them.
>  	 *
>  	 * If devices still want to use this (at their own risk), they will
>  	 * have to use the quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE, but
>  	 * the default should be a reliable mapping.
>  	 */
>  	while (usage->code <= max && test_and_set_bit(usage->code, bit)) {
> +		if (field->application == HID_GD_JOYSTICK && usage->code == KEY_RESERVED)
> +			break;
> +
>  		if (device->quirks & HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE) {
>  			usage->code = find_next_zero_bit(bit,
>  							 max + 1,
> @@ -1455,6 +1464,12 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
>  	if (usage->type == EV_KEY) {
>  		set_bit(EV_MSC, input->evbit);
>  		set_bit(MSC_SCAN, input->mscbit);
> +
> +		if (field->application == HID_GD_JOYSTICK &&
> +		    (usage->hid & HID_USAGE_PAGE) == HID_UP_BUTTON) {

Too bad we only set up the button ranges for joysticks, when we could do
this for all HID devices with a button usage page.

It also makes the code hard to follow because we now enable this at the
different place than the other mappings.

Cheers,
Benjamin

> +			set_bit(EV_BTN, input->evbit);
> +			++input->button_count;
> +		}
>  	}
>  
>  	return;
> diff --git a/include/linux/input.h b/include/linux/input.h
> index f6389de4a4d1..7f39c663fa85 100644
> --- a/include/linux/input.h
> +++ b/include/linux/input.h
> @@ -214,6 +214,8 @@ struct input_dev {
>  };
>  #define to_input_dev(d) container_of(d, struct input_dev, dev)
>  
> +#define INPUT_MAX_BUTTONS 2048 /* A sane limit of supported device buttons */
> +
>  /*
>   * Verify that we are in sync with input_device_id mod_devicetable.h #defines
>   */
> -- 
> 2.52.0
>