Re: [PATCH] [v2] Input: increase max button number to 0x340

This one apparently slipped through,

On Thu, Aug 08, 2024 at 06:42:37PM +0200, Tomasz Pakuła wrote:
[...]

I dug around the kernel some more, and have few ideas and questions I would like
to pose, before I send out another patch and make a fool of myself.

1. For the compatible solution, and I know this might sound
sacreligious, but would it be at all considered ok, if joysticks could
use the KEY_MACRO range?  Current behavior in hid-input.c is to just
add (BTN_TRIGGER_HAPPY - 0x10) after 16 buttons.  KEY_MACRO range lies
directly beneath TRIGGER_HAPPY so we would only replace
BTN_TRIGGER_HAPPY with KEY_MACRO1. I know this is not their intended
use, but their description says "Some keyboards have keys which do not
have a defined meaning, these keys are intended to be programmed /
bound to macros by the user"

iirc the hid-input.c behaviour is fallthrough behaviour rather than "we
explicitly map it to this", right?

Either way, the KEY_MACRO range has an explicit meaning and if you start
re-using this for something else it's the same problem as mentioned
elsewhere - you now expect all of userspace to encode those special
exceptions forever just to make the kernel patches a bit easier. That's
... not ideal ;)

Binding buttons to do some actions sounds just like a dame controller,
in a way :P I already tested this change and it enabled over 40
additional buttons without the need to intervene in software. This was
picked up by SDL, proton, firefox and basically
everything, as these usages are obviously not crossing KEY_MAX.

To squeeze just a little bit more, we could utilize the BTN_0 to BTN_9
range. I couldn't find their meaning, but I suppose the definition of
a joystick/gamepad could be stretched to include these.

They're used by e.g. wacom tablets for the physical tablet buttons (not
those on the stylus but on the actual tablet). And their meaning is
basically "numbered buttons without an explicit meaning". Using those
will likely get your device tagged as tablet though, you'd need to
double-check what udev's builtin-input_id does to make sure otherwise
we'll have to quirk every device one-by-one.

Cheers,
  Peter
 

2. For the better, more scalable solution, your proposition from the
start is the best one.
I thought that overflowing buttons could be just hardcoded to one
selected usage in
hid-input.c. Be it BTN_MISC, BTN_JOYSTICK. Deduplication would make sure, they
don't actually send any bogus EV_KEY events.

Let's take a look at usage setup in hid-input.c
We can see that if a usage is from EV_KEY range, EV_MSC usage is always appended
and it will send not only EV_KEY events, but EV_MSC MSC_SCAN events as well.

if (usage->type == EV_KEY) {
    set_bit(EV_MSC, input->evbit);
    set_bit(MSC_SCAN, input->mscbit);
}

This sadly comes AFTER deduplication. It would probably be better to
set it explicitly in the
joystick/gamepad switch entry. MSC_SCAN already has a value that seems
to depend on the
button number, but a dedicated MSC_PROG_KEY would indeed be better
suited for this, along
with MSC_PROG_VAL, as you said, as MSC_SCAN and MSC_PROG_KEY would not contain
it. Or maybe we could do some bit magic and send the state with the
value. MSG could indicate
state. This is a bit less self explanatory but we only need to handle one event.

Now, software such as SDL could be changed so it doesn't care about
usages at all, and
gets the button number from these two. A legacy path could be retained
as detection could be
based on the existence of these MSC_PROG_* events.

Cheers
Tomasz