[Bug] Mouse Button presses KC_BTN* only work when mouse cursor is moving

[btittelbach]

Describe the Bug

Expected behaviour

• If the mouse cursor is resting, e.g. the trackpoint is not being touched, the mouse buttons KC_BTN* in the keymap should work

Actual behaviour

• The mouse buttons don't work, unless the mouse cursor is also being moved

Blamed commit

I managed to trace the bug to the following commit: a850f7d
Mouse buttons work right before the commit was applied and stopped working with this commit.

keyboard configuration

ENCODER_MAP_ENABLE = yes
WS2812_DRIVER = vendor
RGBLIGHT_ENABLE = yes
COMBO_ENABLE = yes

{
.....
   "processor": "RP2040",                               
    "bootloader": "rp2040",                              
    "features": {                                        
        "bootmagic": true,                                                           
        "encoder": true,                               
        "extrakey": true,                                         
        "mousekey": true,                                            
        "ps2mouse": true                                        
    },                                                           
    "ps2": {                                                        
        "clock_pin": "GP27",                                          
        "data_pin": "GP26",                             
        "driver": "vendor",                              
        "enabled": true,                                 
        "mouse_enabled": true                            
    },
...
}                            

Keyboard Used

qmk compile -kb chrumm/leds38 -km btittelbach_65keys_mouse_rgblight

Link to product page (if applicable)

https://github.com/btittelbach/chrumm-qmk/tree/rgblight

Operating System

GNU/Linux

qmk doctor Output

No response

Is AutoHotKey / Karabiner installed

• AutoHotKey (Windows)
• Karabiner (macOS)

Other keyboard-related software installed

No response

Additional Context

No response

[btittelbach]

@strobo5 maybe you could take a look?

[PeterMortensen]

What PS/2 device was it tested with?

A Trackpoint from a Thinkpad T61? An Azoteq ProxSense TPS65 (datasheet. Now allegedly EOL)? A Cirque trackpad? Something else?

[strobo5]

Strange. I have the same question as PeterMortensen. Looking at the code, it's not immediately obvious to me what could be going on..

For #22265 / #23694 I used qmk console to get debugging output from the PS/2 driver. Maybe you can do the same, paste some of the output here, and we can try to make sense of it together.

These are my possibly outdated notes on how to get this log (check the documentation for reference):

In the info.json, set "console": true.

In the keymap.c add this to keyboard_post_init_user():

debug_enable=true;
debug_mouse=true;

In the config.h add this:

#define PS2_MOUSE_DEBUG_RAW
#define PS2_MOUSE_DEBUG_HID

Compile a new image, then check dmesg for the hidraw number, e.g.:

hid-generic 0003:FEED:0000.001D: hiddev98,hidraw6: USB HID v1.11 Device

Then chmod 666 /dev/hidraw6 (as root / with sudo).

Now use qmk console.

[btittelbach]

What PS/2 device was it tested with?

I am not sure this is related to the PS/2 device at all, since the mouse keys are normal keys on keyboard on layer 1. I hold OSL(1) and then have access to KC_BTN1 to e.g. double-click. The buttons are not, in hardware, related to the PS/2 input at all. On the image, the mouse keys are where X, C, V are.

Nevertheless:

This is one of my keyboards with the problem:

It used a surnaiee MS8006 China Trackpoint USB Evaluation Module and de-soldered the blue trackpoint module from the USB-Module. (see below) The blue module just outputs PS/2 on two wires, which I wired to the RP2040. The module is actually very good and precise.

[sigprof]

I suppose the following happens here:

• ps2_mouse_task() gets called on every pass of the QMK main loop, which happens more frequently than the reports coming from the PS/2 device, therefore sometimes ps2_mouse_task() does not get any data from the PS/2 device.
• Before Fix PS/2 Trackpoint mouse clicks (#22265) #23694 ps2_mouse_task() treated the case when there is no PS/2 report as if the PS/2 device returned a report containing all zero values (because the call to ps2_mouse_clear_report() on the previous iteration had it set that way). This caused problems when using a PS/2 device with its own set of mouse buttons, because the button state alternated between the state actually reported by the PS/2 device and no buttons pressed.
• After Fix PS/2 Trackpoint mouse clicks (#22265) #23694 ps2_mouse_task() just does nothing if there is no PS/2 report; however, by doing nothing at all it also ignores the button state passed through the tp_buttons variable, and tp_buttons is where register_mouse() places the button state updated by keycodes like KC_BTN1 when the PS/2 mouse support is enabled (the mousekeys_send() call gets skipped in this configuration, because it is intended that the PS/2 code would send the mouse report). So if the PS/2 device does not send any reports (e.g., because there is no movement and no actual buttons on the PS/2 device), register_mouse() updates only the tp_buttons variable, but ps2_mouse_task() ignores those updates and does not send the mouse report.

The proper way to fix all this is probably to make the PS/2 mouse support use the pointing device code instead of sending the USB reports itself. A quicker fix might be to revert the changes done in #23694, and then remove mouse_report->buttons = 0; from ps2_mouse_clear_report(); then ps2_mouse_task() would treat the “no PS/2 report” case as “no movement, button state unchanged from the previously reported one”, and then the subsequent code would combine that button state with tp_buttons and send the mouse report if something had changed.

[strobo5]

Thank you for these explanations, I had no idea about this mechanism with register_mouse(). I vaguely remember being confused by the tp_buttons variable.

The proper way to fix all this is probably to make the PS/2 mouse support use the pointing device code instead of sending the USB reports itself. A quicker fix might be to revert the changes done in #23694, and then remove mouse_report->buttons = 0; from ps2_mouse_clear_report(); then ps2_mouse_task() would treat the “no PS/2 report” case as “no movement, button state unchanged from the previously reported one”, and then the subsequent code would combine that button state with tp_buttons and send the mouse report if something had changed.

I tried the quick fix with my T61 keyboard (on top of #23696 which is still not merged) and did not notice any erratic behavior. It seems to fix #22265 just like #23694 did.