470113 2023-05-22 09:52:14 +0000 Main keyboard layout switching shortcuts fire on press instead of on release 2023-11-30 22:06:09 +0000 1 1 4 Plasma kwin input 5.27.5 Other Linux RESOLVED UPSTREAM https://bugs.kde.org/show_bug.cgi?id=464805 https://bugs.kde.org/show_bug.cgi?id=470257 https://bugs.kde.org/show_bug.cgi?id=470256 https://github.com/xkbcommon/libxkbcommon/issues/92 NOR normal --- 0 oded kwin-bugs-null beatloman91 butirsky cravchik 0 oldest_to_newest 2232391 0 oded 2023-05-22 09:52:14 +0000 SUMMARY With multiple keyboard layouts configure, the shortcuts for switching layout trigger on press instead of on release, making them unusable as a prelude for other shortcuts - for example: CTRL+SHIFT is a common prefix for complex shortcuts (Kate, for example, has a ton of default CTRL+SHIFT shortcuts, but just consider "Save As"), but when setting Input Devices -> Keyboard -> Advances -> switching to another layout -> Ctrl+Shift, all these shortcuts become inaccessible. The more common Alt+Shift (for people who grew up on multi-lingual MS-Windows) is less common in KDE software but still breaks a lot of useful functionality in other apps. STEPS TO REPRODUCE 1. In System Settings -> Input Devices -> Keyboard -> Layouts, set two or more layouts. 2. Click the "Main shortcuts" setting and choose, well, anything in the list that opens - but lets try "Left Ctrl" for the most damage. 3. Go to any app and try to save the document with CTRL + S. OBSERVED RESULT The layout switches. EXPECTED RESULT The expected action for the combined shortcut should trigger. SOFTWARE/OS VERSIONS Operating System: KDE neon Testing Edition KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.107.0 Qt Version: 5.15.9 Kernel Version: 6.2.0-20-generic (64-bit) Graphics Platform: offscreen Processors: 8 × Intel® Core™ i7-7820HQ CPU @ 2.90GHz Memory: 31.2 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 630 ADDITIONAL INFORMATION - See the 20 years old Xorg bug https://gitlab.freedesktop.org/xorg/xserver/-/issues/258 that describes the problem with the original XKB specification that is probably the cause of this kwin_wayland issue (and its 20 years worth of "me too"). Andrey Butirsky (@butirsky) had commented there about opening a ticket here, so - 2 years late - here we are. - See bug #464805 and bug #420493 (X11-specific) for slightly different behaviors about 'fire on press' that are also problematic and were (apparently) fixed. 2232397 1 butirsky 2023-05-22 10:59:11 +0000 I corrected the summary to reflect what is the real problem on Plasma side. Please confirm. 2232415 2 oded 2023-05-22 12:41:50 +0000 (In reply to Andrey from comment #1) > I corrected the summary to reflect what is the real problem on Plasma side. > Please confirm. This is not about the kwin "modifier only shortcut" feature. This is about the implementation of the KXB-like "shortcuts to switch layouts" implementation, which I'm not sure where exactly it is, but I'm close to 100% sure it isn't using the '[ModifierOnlyShortuts]' configuration in kwin. The current implementation definitely works with more than one modifier - I just chose the example of "Left Ctrl" as the "worst possible but still possible" example, but more common configurations are Ctrl+Shift and Alt+Shift. Also the actual problem isn't the "only one" behavior but the "on press instead of on release" behavior (which is also a problem with the '[ModifierOnlyShortuts]' configuration but as I mentioned above - likely a different similar problem). 2232419 3 butirsky 2023-05-22 12:59:12 +0000 (In reply to Oded Arbel from comment #2) > This is not about the kwin "modifier only shortcut" feature. This is about > the implementation of the KXB-like "shortcuts to switch layouts" > implementation, which I'm not sure where exactly it is, but I'm close to > 100% sure it isn't using the '[ModifierOnlyShortuts]' configuration in kwin. There is no such implementation in KWin - there is XKB behavior support via libxkbcommon and native Plasma's global shortcuts implementation (accessible via Alternative shortcuts in Keyboard KCM), which can also include modifiers-only shortcuts. That is why I think it's actually about "modifier only shortcut" feature. Please check all of that. > > The current implementation definitely works with more than one modifier - I > just chose the example of "Left Ctrl" as the "worst possible but still > possible" example, but more common configurations are Ctrl+Shift and > Alt+Shift. Also the actual problem isn't the "only one" behavior but the "on > press instead of on release" behavior (which is also a problem with the > '[ModifierOnlyShortuts]' configuration but as I mentioned above - likely a > different similar problem). I assumed ModifierOnlyShortuts trigger on release, if not - please file a separate report. 2232423 4 oded 2023-05-22 13:14:57 +0000 (In reply to Andrey from comment #3) > (In reply to Oded Arbel from comment #2) > > This is about the implementation of the KXB-like "shortcuts to switch layouts" implementation > There is no such implementation in KWin - there is XKB behavior support via > libxkbcommon Ok, so we're back to libxkbcommon's bug 92 - https://github.com/xkbcommon/libxkbcommon/issues/92 - which I see you picked up on 👍👍✌️ > and native Plasma's global shortcuts implementation (accessible > via Alternative shortcuts in Keyboard KCM), which can also include > modifiers-only shortcuts. It does not, and even it it did - it wouldn't work to solve the problem, both because of the "only one modifier" requirement, and because it uses logical keys and not hardware key codes, so it doesn't distinguish between left and right Ctrl, Alt vs AltGr, etc, which layout switching sometimes rely on (check, for example, "left ctrl for first layout, right ctrl for second layout"). > I assumed ModifierOnlyShortuts trigger on release, if not - please file a > separate report. I will. 2232429 5 butirsky 2023-05-22 13:32:51 +0000 (In reply to Oded Arbel from comment #4) > (In reply to Andrey from comment #3) > > and native Plasma's global shortcuts implementation (accessible > > via Alternative shortcuts in Keyboard KCM), which can also include > > modifiers-only shortcuts. > > It does not, and even it it did - it wouldn't work to solve the problem, > both because of the "only one modifier" requirement, and because it uses > logical keys and not hardware key codes, so it doesn't distinguish between > left and right Ctrl, Alt vs AltGr, etc, which layout switching sometimes > rely on (check, for example, "left ctrl for first layout, right ctrl for > second layout"). > Please report it too > > I assumed ModifierOnlyShortuts trigger on release, if not - please file a > > separate report. > > I will. Please note bug 464805 wasn't confirmed on Wayland, so check it too. 2233095 6 oded 2023-05-25 14:07:01 +0000 I verified that #464805 is indeed still an issue on Wayland and created tickets #470256 and #470257 2233098 7 butirsky 2023-05-25 14:13:19 +0000 Can you check if bug 464805 is still there if you register she modifier-only shortcut through special config file? 2233498 8 oded 2023-05-28 10:48:07 +0000 (In reply to Andrey from comment #7) > Can you check if bug 464805 is still there if you register she modifier-only > shortcut through special config file? Setting up modifier-only shortcuts using kwinrc ([ModifierOnlyShortcuts] section), instead of using the System Settings shortcuts KCM, the modifier-only shortcut does trigger correctly on release. 2233653 9 butirsky 2023-05-29 10:54:46 +0000 Nice, so temporary solution for you would be setting up the modifiers-only shortcut switching the layout through the config file. I would be appreciate if you investigate it yourself fist, but if you need my assistant please ask. 2233654 10 butirsky 2023-05-29 11:03:13 +0000 Hint: basically, you would have to configure sending appropriate DBus call switching the layout 2233662 11 oded 2023-05-29 11:59:43 +0000 I can get it to work (for some values of "work") by adding this to ~/.config/kwinrc: [ModifierOnlyShortcuts] Control=org.kde.keyboard,/Layouts,,switchToNextLayout Then if I disable the kxbcommon group switch shortcut, I can still switch shortcuts by hitting CTRL and releasing (and it doesn't take effect if I use a CTRL prefix on a shortcut, like CTRL+S). So.. well... I will try to live with this for a while - but it isn't a solution for people that still want to use "MS-Windows-like" shortcuts or have more complex setups. Some of that can be helped by implementing something like my suggestion in https://bugs.kde.org/show_bug.cgi?id=470256#c1, and obviously this needs to be figure out into the shortcut KCM (and not what it currently does, aka bug #464805) and the Keyboard KCM (bug #470257). Ok, while writing this up I figured where the "only CTRL on release" layout switcher trips me up - I often hold CTRL while thinking about the next I do - for example, I expect to want to CTRL+Tab next, so I hold CTRL while finishing reading, at which point I might not want to CTRL+Tab and release CTRL causing a layout switch. Using another single modifier won't help (there aren't enough anyway: ALT triggers menus in various apps, SHIFT suffers from the same problem that I often just hold it down for a bit, and META is already used for Kickoff). I will try to get used to that, but multi-modifier-only shortcuts should definitely be a thing that Plasma supports, if we want to dump xkbcommon. 2233666 12 butirsky 2023-05-29 12:19:13 +0000 Still a progress) Thank you. 2270073 13 nate 2023-11-30 22:06:09 +0000 *** Bug 477508 has been marked as a duplicate of this bug. ***