Package: kwin-wayland Version: 4:6.3.6-1 Severity: normal Tags: upstream X-Debbugs-CC: [email protected] Dear Maintainers, on a Microsoft Surface Go 3 with the Surface Type Cover under a Plasma Wayland session, opening the Type Cover (after the firmware emits SW_LID=open) disables the touchpad without any user interaction: the global shortcut "Toggle Touchpad" (component kcm_touchpad) is activated by itself and the resulting state is persisted, so the touchpad stays off until it is re-enabled manually. I reported this to KDE first. It was initially answered with the generic "Plasma 6.3.6 is no longer maintained, upgrade to an active version" message, and it is now RESOLVED/DOWNSTREAM with the note that 6.3.6 is the version your distribution ships: https://bugs.kde.org/show_bug.cgi?id=525555 So apparently the ball is on the Debian side. I understand 6.3.6 is EOL upstream and that a big backport is not realistic; this report is meant to document the behaviour for trixie and to ask whether the small upstream change described below is worth considering. If you prefer, feel free to close it as "upstream / won't fix". == Steps to reproduce == 1. Boot into the Plasma Wayland session (kwin_wayland / plasmashell). 2. Make sure the touchpad is enabled and the Toggle Touchpad shortcut has not been set to "none" manually. 3. Fold the Type Cover over the screen (closing the lid) and open it again; unlock the session. == Actual behaviour == The touchpad is disabled. KWin's InputDevice "enabled" property becomes false and ~/.config/kcminputrc gets: [Libinput][1118][2415][Microsoft Surface Type Cover Touchpad] Enabled=false It stays disabled until manually re-enabled. == Expected behaviour == The touchpad stays enabled. == Analysis == * InputRedirection::enableOrDisableTouchpads(false) is only reachable from the touchpad global shortcut actions registered in InputRedirection::setupTouchpadShortcuts() (src/input.cpp). * Monitoring the session bus, ~0.7 s after SW_LID open this signal is emitted, while no key press by a user is seen at that moment: path /component/kcm_touchpad interface org.kde.kglobalaccel.Component member globalShortcutPressed args "kcm_touchpad", "Toggle Touchpad" * The cause on this hardware is a firmware event: the Type Cover keyboard device advertises and emits KEY_F21 (evdev code 191) when the lid is opened. /usr/share/X11/xkb/symbols/inet maps <FK21> to XF86TouchpadToggle, which Qt turns into Qt::Key_TouchpadToggle - the first default shortcut of the "Toggle Touchpad" action. The "Intel HID events" and "Intel HID 5 button array" devices emit KEY_UNKNOWN/0xf0 (evdev 240) at the same time. Verified capabilities on this machine: Microsoft Surface Type Cover (0003:045E:096F.0006): KEY= bitmap with F21 and 0xf0 Microsoft Surface Type Cover CC (0003:045E:096F.0007): 0xf0 Intel HID events : 0xf0 Intel HID 5 button array : 0xf0, KEY_TOUCHPAD_ON (KEY_TOUCHPAD_TOGGLE / 0x230 is not advertised by any of them) * Aggravating compositor bug: KGlobalAccel::allShortcutInfos() returns a bogus 0 entry in the active shortcut list of "Toggle Touchpad", e.g. [16777488, 0, 352321808, 352325930]. This comes from registering Qt::Key_TouchpadToggle twice in setupTouchpadShortcuts(): KGlobalAccel::self()->setDefaultShortcut(touchpadToggleAction, {Qt::Key_TouchpadToggle, Qt::Key_TouchpadToggle, Meta+Ctrl+Key_TouchpadToggle, Meta+Ctrl+Key_Zenkaku_Hankaku}); KGlobalAccel::self()->setShortcut(touchpadToggleAction, ...same...); A key event with no keysym (Qt key 0 / Key_unknown) matches that 0 entry and can activate the action, so the phantom 0xf0 event ends up toggling the touchpad as well. Upstream 6.6 no longer contains setupTouchpadShortcuts() in src/input.cpp: the touchpad shortcuts moved to the plasma-desktop KCM and became desktop-file based, with the duplicate removed from the default list: X-KDE-Shortcuts=Touchpad Toggle\tMeta+Ctrl+Touchpad Toggle\tMeta+Ctrl+Zenkaku Hankaku So both halves of the problem (the bogus 0 shortcut and the persistence of a shortcut-driven disable) are addressed by code that does not exist in 6.3.6. I understand 6.3.6 is EOL upstream and that Debian is not expected to backport it. == Workaround in use here == Setting the shortcut to "none" stops the issue (~/.config/kglobalshortcutsrc): [kcm_touchpad] Toggle Touchpad=none A second mitigation, masking the phantom keycodes via libinput, is documented in /etc/libinput/local-overrides.quirks: [Surface Type Cover - mask phantom keys] MatchName=Microsoft Surface Type Cover MatchDMIModalias=dmi:*pnSurfaceGo3* AttrEventCode=-KEY_F21;-KEY_ZENKAKUHANKAKU;-EV_KEY:0xf0 [Intel HID - mask phantom keycode] MatchName=Intel HID* MatchDMIModalias=dmi:*pnSurfaceGo3* AttrEventCode=-EV_KEY:0xf0 Note: with this quirk the Type Cover still reports KEY_F21 in /proc/bus/input/devices, so I cannot confirm from here that libinput actually applied the removal to the device as seen by the compositor (`libinput list-devices` is not available to an unprivileged session). The effective workaround here is the "none" shortcut; the quirks are kept as a second layer. == System information == Debian: Debian GNU/Linux 13 (trixie), 13.6 Kernel: 6.12.107+deb13-amd64 (linux-image-amd64 6.12.107-1) Session: Plasma Wayland (plasmashell 6.3.6) Hardware: Microsoft Surface Go 3. DMI modalias: dmi:bvnMicrosoftCorporation:bvr17.103.143:bd11/04/2025:svnMicrosoftCorporation:pnSurfaceGo3:pvr124I00074T000M0300000D0B06F6C09P38S01E0Y0L0:rvnMicrosoftCorporation:rnSurfaceGo3:rvr:cvnMicrosoftCorporation:ct9:cvr:skuSurface_Go_3_1901: Relevant packages: kwin-wayland 4:6.3.6-1 kwin-common 4:6.3.6-1 libkwin6 4:6.3.6-1 plasma-desktop 4:6.3.6-1 plasma-workspace 4:6.3.6-2 kglobalacceld 6.3.6-1 libkf6globalaccel6 6.13.0-1 libkglobalacceld0 6.3.6-1 libinput10 1.28.1-1+deb13u1 libqt6core6t64 6.8.2+dfsg-9+deb13u2 Involved input devices (as exposed by the kernel): Microsoft Surface Type Cover (0003:045E:096F.0006) Microsoft Surface Type Cover Consumer Control (0003:045E:096F.0007) Microsoft Surface Type Cover Mouse (0003:045E:096F.0009) Microsoft Surface Type Cover Touchpad (0003:045E:096F.0009) Intel HID events / Intel HID 5 button array / Intel HID switches If you consider that the right place to stop the phantom KEY_F21 / 0xf0 events is the kernel HID driver or libinput rather than KWin, please reassign as appropriate. == Additional info == Related upstream reports: https://bugs.kde.org/show_bug.cgi?id=497952 https://bugs.kde.org/show_bug.cgi?id=489362 https://bugs.kde.org/show_bug.cgi?id=519755 https://github.com/linux-surface/linux-surface/issues/1059 Thanks for your work on the Debian KDE packages. Kind regards,
