qmk/qmk_firmware

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

Closed

#24,455 opened on Oct 1, 2024

View on GitHub
 (19 comments) (0 reactions) (0 assignees)C (20,368 stars) (43,867 forks)batch import
bughelp wanted

Description

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: a850f7d69509a99ef46dd2790c2e55171db16e7a 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

Contributor guide

Tech stack
c
Domain
backend
Issue type
bug
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
half day
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
C programmingQMK firmware basics
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
30
Research direction
Examine the commit a850f7d69509a99ef46dd2790c2e55171db16e7a. Look for changes in mouse button processing logic that may have introduced a dependency on mouse movement for button events. Check the mouse key handler and see if there is a flag or condition that prevents button presses from being sent when the cursor velocity is zero. Consider reverting or adjusting that logic.