https://bugs.kde.org/show_bug.cgi?id=519755
--- Comment #5 from [email protected] --- (In reply to Nate Graham from comment #4) > Yep, that's the bug all right. > > As such, it's tempting to say this is a hardware issue. However I know > that's not going to be a very satisfying answer. Let's see what the KWin > folks think about this whole sad situation. > > Perhaps it would need to be fixed in Qt, xkb, or even the kernel, so that > pressing this key only sends KEY_TOUCHPAD_TOGGLE on Linux. I understand, but interestingly it seems that the same bug doesn't occur on GNOME despite the same macro being executed. The evtest on GNOME gave the same results: ''' -event3 DEVICE_ADDED AT Translated Set 2 keyboard seat0 default group10 cap:k -event12 KEYBOARD_KEY +0.000s KEY_TOUCHPAD_TOGGLE (530) pressed event12 KEYBOARD_KEY +0.000s KEY_TOUCHPAD_TOGGLE (530) released -event3 KEYBOARD_KEY +0.003s *** (-1) pressed event3 KEYBOARD_KEY +0.007s KEY_LEFTMETA (125) pressed event3 KEYBOARD_KEY +0.010s KEY_F24 (194) pressed event3 KEYBOARD_KEY +0.018s KEY_F24 (194) released event3 KEYBOARD_KEY +0.029s KEY_LEFTMETA (125) released event3 KEYBOARD_KEY +0.034s *** (-1) released ''' The wev logs show that the standard XKB translation layer maps both hardware events to the same keysym (XF86TouchpadToggle): - key: 538 (evdev KEY_TOUCHPAD_TOGGLE) -> XF86TouchpadToggle - key: 202 (evdev KEY_F24) -> XF86TouchpadToggle The sequence of events is as follows: 1. XF86TouchpadToggle is pressed and released cleanly (key: 538). 2. Control_L and Super_L are pressed and held down. 3. A second XF86TouchpadToggle arrives (key: 202) while those modifiers are active. dconf watch /org/gnome/desktop/peripherals/touchpad/ shows that GNOME only flips the touchpad state once. My theory is that GNOME's gsd-media-keys probably requires an exact modifier match; because Control and Super are depressed during the second keysym arrival, GNOME evaluates it as an unbound combo (Ctrl+Super+XF86TouchpadToggle) and drops it. KDE / KWin / KGlobalAccel appears to evaluate media keysyms permissively, triggering global handlers even if system modifiers are concurrently active. Because of this, KDE treats both the clean ACPI signal and the Windows-targeted fallback macro as valid triggers back-to-back, executing the state toggle twice in <10ms. My ideas to fix the issue would be strict modifier matching for global shortcuts mapped to standard media keysyms like GNOME, or to implement an short time-debounce (~20-50ms) on touchpad toggle state changes to discard rapid firmware-injected duplicate macros. Haven't given it much thought though, so don't know what the implications could be for either of the fixes. -- You are receiving this mail because: You are watching all bug changes.
