Created attachment 76603 [details] Proposed patch to fix it With this commit: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0de6575ad0a8f19ccf91d6e783b2a1bba0edb7a5 support for MSI Wind U100 laptop appeared in msi-laptop driver. Before that, there was mapping in udev's keymaps/mirco-star for Fn+F3 -> F21 (touchpad toggle keycode). But after that commit msi-laptop driver is able to send separate touchpad on/off keycodes (F22/F23) for Fn+F3 key, so we need to disable Fn+F3 -> F21 mapping for MSI Wind U100 to avoid having both touchpad toggle and touchpad on/off keycodes sent. I propose attached patch to fix it.
Just to clarify, pressing *one* key (Fn+F3) sends both a "touchpad off" and a "touchpad on" scan code with this patch, or the kernel driver already remembers the state and sends alternating codes of "off" and "on"? Which scan codes are these?
(In reply to comment #1) > Just to clarify, pressing *one* key (Fn+F3) sends both a "touchpad off" and > a "touchpad on" scan code with this patch, or the kernel driver already > remembers the state and sends alternating codes of "off" and "on"? Which > scan codes are these? Okay, I will try to explain in details. Before the mentioned commit in kernel the behavior was the following. When Fn+F3 is pressed, scan code is generated. 'showkey -s' shows 0x74, 'showkey -k' shows 191, and there is a mapping for this key in /lib/udev/keymaps/micro-star - code 0xE4 to f21 (touchpad toggle key). I don't fully understand why 'showkey -s' shows 0x74, and in udev it is 0xe4, but that mapping really works and maps Fn+F3 to F21 key, which is touchpad toggle key. If I run '/lib/udev/keymap input/event0 0xE4 reserved', the mapping disappears and Fn+F3 stops generating F21 key code. Fn+F3 on MSI Wind U100 toggles touchpad in hardware. The first press disables touchpad and the second press enabled touchpad again. And msi-laptop driver is only able to read current touchpad state. So it is not correct to send F21 (touchpad toggle key) key code, because F21 is intended to be processed by desktop environment in case when hardware does not react on touchpad toggle key press and when desktop environment should disable/enable touchpad in software. But currently with that udev mapping we send F21 key code on Fn+F3 press and that may lead to losing synchronization between hardware and software touchpad states (switch to X11 session, press Fn+F3, touchpad is disabled both in hardware and in software, then switch to VT1, press Fn+F3 again, touchpad is enabled in hardware but still disabled in software in X11 session, so when you switch again to X11 session, touchpad will be disabled forever, and pressing Fn+F3 will not help, because touchpad will be disabled in software and enabled in hardware or it will be disabled in hardware and enabled in software). So at first, it's a bug, and we need to disable Fn+F3 -> F21 mapping for MSI Wind U100, and the patch does that. After the mentioned commit in kernel the support for MSI Wind U100 appeared in msi-laptop driver. It means that this driver now handles Fn+F3 key presses, reads the real touchpad state and sends either KEY_TOUCHPAD_ON or KEY_TOUCHPAD_OFF depending on touchpad state. These codes are then mapped to F22 and F23, which are used to inform desktop environment about current touchpad state. Also, it is not correct to send both F21 and F22/F23 key codes (F21 should be sent when hardware does not handle touchpad toggle key, and F22/F23 should be send when it does), and it is another reason to disable Fn+F3 -> F21 mapping in udev. So, after applying this patch, Fn+F3 key will not send F21 (touchpad toggle) key code any more, and with fresh kernels separate F22/F23 (touchpad on/off) key codes will be sent depending on current touchpad state (if touchpad is turned on by Fn+F3 press, F22 code is sent, and if touchpad is turned off, F23 code is sent).
Thanks for the detailled explanation! I pushed this.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.