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
