[Feature Request] Support KC_BTN4-8 for PS2 devices

[daniel2887]

Feature Request Type

• [ ] Core functionality
• [X] Add-on hardware support (eg. audio, RGB, OLED screen, etc.)
• [X] Alteration (enhancement/optimization) of existing feature(s)
• [ ] New behavior

Description

Currently, ps2_mouse doesn't support KC_BTN4-8. Copy/pasting my observations from Discord:

1. action.c:register_mouse() gets called on mousekey state changes In that function's switch statement, there are 3 paths:
   1. If there's no PS2 or pointing device, mousekey_send() is called and everyone's happy
   2. If there's a pointing device, the pointing device decides how to handle mousekeys (pointing_device_keycode_handler())
   3. If there's a PS2 device, the PS2 device decides how to handle keycodes mousekeys, through an extern'd tp_buttons. However, values >KC_BTN3 get omitted (due to PS2 protocol stuff?)
2. In ps2_mouse.c:ps2_mouse_task(), tp_buttons get added onto a local mouse_report, which contains data received from the PS2 device.
3. In the same function, the final mouse_report gets sent to the host via host_mouse_send()

So because action.c drops >BTN3, ps2_mouse doesn't get them and doesn't report them to the host.

I have a local fix here that disentangles PS2 device button presses from KC_BTN* presses, and enables support for KC_BTN4-8 for ps2_mouse. If this looks more or less ok, I can submit a PR, although I think the right fix is to convert ps2_mouse into a pointing device instead of having it be grafted on in action.c (which is a larger project).

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged properly or other activity occurs. For maintainers: Please label with bug, in progress, on hold, discussion or to do to prevent the issue from being re-flagged.

[drashna]

Honestly, the best way forward for the ps2 code is to merge it into the pointing device code, as that supports the 8 buttons, and a lot more.

There is a PR to start that: https://github.com/qmk/qmk_firmware/pull/22532

However, there is a lot of cleanup to do, because of how different it is handled.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged properly or other activity occurs. For maintainers: Please label with bug, in progress, on hold, discussion or to do to prevent the issue from being re-flagged.

[github-actions[bot]]

This issue has been automatically closed because it has not had activity in the last 30 days. If this issue is still valid, re-open the issue and let us know. // [stale-action-closed]