Created attachment 148737 [details] Shortcuts file exported from plasma settings SUMMARY Shortcuts set in plasma settings don't work across layouts that have different top row (`1234567890`) consistently. Eg: `1` (US) is `+` in CZ layout `2` (US) is `ě` in CZ layout `3` (US) is `š` in CZ layout `4` (US) is `č` in CZ layout `5` (US) is `ř` in CZ layout ... STEPS TO REPRODUCE 1. Go to Plasma settings 2. Add CZ keyboard layout 3. Set some shortcuts to use the top keyboard row (eg. `SUPER + 1` to `Switch to desktop 1`, etc) 4. Go to desktop other than the one you want to switch to and try to switch to it using the shortcut 5. Try this for all the keys on the top row of the keyboard OBSERVED RESULT When I bind the top row to change my desktops (`SUPER + 1` is desktop 1, `SUPER + 2` is desktop 2, `SUPER + 3` ...) everything works fine in `US` layout, but when I change to `CZ` layout some things break as follows: `SUPER + 1` (`SUPER + +`) does not register now - result is only `+` symbol being typed into whatever window I have focused `SUPER + 2` (`SUPER + Ě`) works normally `SUPER + 3` (`SUPER + Š`) works `SUPER + 4` (`SUPER + Č`) works `SUPER + 5` (`SUPER + Ř`) works `SUPER + 6` (`SUPER + Ž`) works `SUPER + 7` (`SUPER + Ý`) does not work `SUPER + 8` (`SUPER + Á`) does not work `SUPER + 9` (`SUPER + Í`) does not work This is also inconsistent as ``SUPER + 9` (`SUPER + Í`) was not problematic before but after 2 days of this happening it started to be. Also `SUPER + 2` (`SUPER + Ě`) was problematic in the beginning but is not anymore. In the attachments you can find my exported shortcuts file. EXPECTED RESULT Shortcuts working consistently across keyboard layouts SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch linux (available in About System) KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.93.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION I'm running WAYLAND (This happens with other shortcuts as well. I have 3 activities and I switch between them with `CTRL + ALT + number` and `CTRL + ALT + 1` (`CTRL + ALT + +`) does not work in this case as well.)
I've used a quick fix when I set the shortcuts in both layouts, but that does not solve the inconsistency when some work and some don't
CONFIRMED TO BE WAYLAND ONLY ISSUE I switched to X11 and everything works again. Sadly I don't remember if this problem was there when I initially switched to Wayland few weeks ago. Anyway, this happens on Wayland only.
"This is also inconsistent as ``SUPER + 9` (`SUPER + Í`) was not problematic before but after 2 days of this happening it started to be. Also `SUPER + 2` (`SUPER + Ě`) was problematic in the beginning but is not anymore." I would try to investigate that consistent in time. Reproducing in VM/new user would also help.
I will try to once I have time. I now have really important things to do, so I'm unable to test it for more users on my machine, and in a vm/other distribution. I'll do it in probably a week or so.
Hello, sorry fol the long wait, but I had very little time for doing things like this. Anyways, I reinstalled my Arch system and the isse still persists.
I believe I have the same issue - my second layout is Hebrew, and I assigned the (non-default) keyboard shortcut CTRL+` to open and close the Yakuake window. On X11 it works well in all layouts, but on wayland this only works if the current layout is English. When switching to Hebrew, the shortcut no longer works. So here's the funny thing - I can workaround that problem by defining a second global shortcut of "pressing CTRL + the key under ESC while the Hebrew layout is active" - I can do that in System Settings, though not from the Yakuake configuration dialog which still uses the old styled shortcut configuration where adding additional shortcuts is complicated to impossible. The System Settings shortcuts KCM shows the new shortcut as CTRL+; (in the Hebrew layout, the key under ESC sends ";" instead if "`"). The problem now is that in QWERTY layout, the key to the right of L also sends ";" and indeed pressing CTRL+; under QWERTY now opens Yakuake... But that's not the really funny thing - the really funny thing is that CTRL + <the key to the right of the key marked with L> open Yakuake also when the layout is Hebrew, even though that key - when the Hebrew layout is active - sends a "ף", not a ";"!! 😲 So I opened the Kwin debug console, to the Input Events monitor and I can see that pressing the QWERTY key ` produces a "QT::Key code" of Key_QuoteLeft, while the same key under the Hebrew layout produces a "QT::Key code" of Key_SemiColon. OTOH, the QWERTY key ; produces Key_SemiColon while in Hebrew layout the monitor shows nothing for the "QT::Key code" field - but when pressing the key while holding CTRL, the monitor shows the "QT::Key code" Key_SemiColon! this works the same for some other letters - when pressed while CTRL is held they produce "QT::Key code" the same as under QWERTY - this is why META+ק works to launch Dolphin (Hebrew ק is the same key as QWERTY e), but not for everything - for example CTRL+W doesn't work to close tabs in Kate, while using the Hebrew layout, because it produces "QT::Key code" of Key_Apostrophe. I'm not sure if the global shortcuts actually use the "QT::Key code", but if they don't they probably use something that is broken in the same way.
Does it work for you with other layouts, for example with EN, RU?
Please see if it's duplicate of bug 375518 which was solved
(In reply to Andrey from comment #7) > Does it work for you with other layouts, for example with EN, RU? When using a Russian layout, I still get "English" QT key codes (i.e. Key_L, Key_R) when holding a modifier and pressing letters, but not when not holding a modifier (and that includes SHIFT). I think the main difference between the Russian layout and the really really weird behavior of the Hebrew layout (where pressing some letter keys, with a modifier, generates "English" QT key codes, but other letter keys generate punctuation QT key codes) is that the Hebrew layout moves punctuation around - e.g. ; is produced by the ` key and / is produced by the Q key. (In reply to Andrey from comment #8) > Please see if it's duplicate of bug 375518 which was solved I'm not sure about the original reporter, but the problem I reported in comment #6 is not solved by the fix to bug 375518 (or the QT bugs linked there). I'm running on Neon unstable with all packages updated for today. Specifically I can verify that the fixes to correctly handle ` under the Russian keyboard layout work well - but not under the Hebrew layout. As I mentioned above here - I believe the issue is that the Hebrew layout generates punctuation for the problematic keys and not letters, and thus ` QXkbCommon::lookupLatinKeysym()` does not translate these symbols to "QWERTY compatible" key syms.
(In reply to Oded Arbel from comment #9) > I'm not sure about the original reporter, but the problem I reported in > comment #6 is not solved by the fix to bug 375518 (or the QT bugs linked > there). I'm running on Neon unstable with all packages updated for today. I have verified that the issue in the original report's description is still much the case: META/SUPER + numbers global shortcuts don't work well in CZ layout. I also verified that the QT key codes for modifiers + numbers under CZ layout generate the "correct" Key_1,Key_2,etc symbols, so I don't know why it is broken and very likely not that related to my issue in comment #6. Just for completion, my test environment is: Linux/KDE Plasma: KDE neon Unstable Edition KDE Plasma Version: 5.26.80 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.7 Graphics Platform: Wayland
Both ` and ; are legitimate (Latin or even ASCII) symbols for shortcuts, so if one key generates them it seems impossible to solve without knowing what physical key was pressed? Do you have some solution in mind, other than obvious with creating different shortcuts for the same key?
(In reply to Andrey from comment #11) > Both ` and ; are legitimate (Latin or even ASCII) symbols for shortcuts, so > if one key generates them it seems impossible to solve without knowing what > physical key was pressed? Do you have some solution in mind, other than > obvious with creating different shortcuts for the same key? One possible solution to this in Qt would be try to switch to Latin layout during handling the shortcut unconditionally, even if legitimate Latin symbol comes to the input. For now, that switching occurs only if non-Latin symbol comes to the input. If so, that should be filed on Qt bugtracker with the link here.
(In reply to Andrey from comment #11) > Both ` and ; are legitimate (Latin or even ASCII) symbols for shortcuts, so > if one key generates them it seems impossible to solve without knowing what > physical key was pressed? Do you have some solution in mind, other than > obvious with creating different shortcuts for the same key? Well, as I've noted - adding duplicate shortcuts for the symbols generated by keys under alternative layouts is a poor workaround because the targeted symbols will also be generated in other use cases where I don't want the global shortcuts to trigger (or worse - I want other shortcuts to trigger, for example I may want different global shortcuts for CTRL+` vs CTRL+;). From looking at the Kwin debug console, I assume that what it calls "scan code" is the value from `QKeyEvent::nativeScanCode()` - and that seems to be stable for the physical key: i.e. the same physical key always generates the same scan code. A solution I think would be to store the scan code and trigger the global action when matching the scan code (and required modifiers) and not the letter. (In reply to Andrey from comment #12) > One possible solution to this in Qt would be try to switch to Latin layout I'm very confused about the term "Latin" to describe a layout (used here and in Qt code liberally) - there are many different Latin layouts (Dvorak comes to mind) and these don't map the same letters to the same key... As I noted in my comment on bug 355046, I think that in a multi-layout work environment global shortcuts (especially) should be mapped to keys in a "non-layout-specific" manner - i.e. use native scan codes. I believe this is how it works under X11.
For X11 it always fall-backs to the first layout defined because of internal Xorg peculiarity (bug), that is why it works there if the first is US or similar. For "Latin", Qt tests each of the configured layouts to see if it mostly contains Latin symbols, then it considered Latin and is used as fallback for non-Latin shortcuts. I think it's better to solve this problem in Qt so local shortcuts could benefit too.
(In reply to Andrey from comment #14) > I think it's better to solve this problem in Qt so local shortcuts could > benefit too. I've created QTBUG-108761 : https://bugreports.qt.io/browse/QTBUG-108761
Hello, I am not at the level where I can debug the issue myself so sorry if I'll talk nonsense. What I think is happening is that the shortcuts on X11 were based on physical keys and on Wayland they're based on the symbols that depend on the layout. It could make sense, now that I think of it, that `SUPER + 1` would not work if that would be the case as the `+` symbol is somewhere else on US layout than in CZ. Other do not exist on the US layout and it *may* fall back to the physical key on some of those? Because most of the ones that are not present on US layout work at least sometimes... If I can do anything to help please tell me. I do not have enough knowledge to figure out what data to collect myself.
(In reply to jiri.stefka from comment #16) > What I think is happening is that the shortcuts on X11 were based on > physical keys and on Wayland they're based on the symbols that depend on the > layout. > > It could make sense, now that I think of it, that `SUPER + 1` would not work > if that would be the case as the `+` symbol is somewhere else on US layout > than in CZ. Other do not exist on the US layout and it *may* fall back to > the physical key on some of those? Because most of the ones that are not > present on US layout work at least sometimes... According to what Andrey said (who I think is a developer that is in charge of at least some of that), that is more or less the case: on X11 it has the (incorrect) behavior of always parsing global shortcuts in the context of the "first" layout and as long as that is a US layout (which is rarely not the case), everything works. But its not the correct solution. On Wayland, there is no such assumption and Qt - that is responsible for understanding "what key was pressed" basically tries to translate keysyms that are not what you can expect from a US keyboard to the character that "a correct physical QWERTY key" would have generated. As far as I can tell, if the non-US keyboard layout emits keysyms that look like something a US keyboard can emit, then Qt (QXKBCommon) does no translation and you get an incorrect key value. > If I can do anything to help please tell me. I do not have enough knowledge > to figure out what data to collect myself. The Qt bug tracking system does not have any voting mechanism, but if you can go into the QTBUG I linked and register for watching it, that I believe will add to the visibility and put some more weight towards a Qt contributor fixing the problem.
(In reply to Oded Arbel from comment #17) > The Qt bug tracking system does not have any voting mechanism It does, see "Votes:" in the top right corner. For the reference - I provided possible solution in the Qt bug reported above. Needs checking. I'll close this bug as UPSTREAM as it seems fully Qt problem. Let's discuss it there.
Got it working with the patch I suggested upstream. Stay tuned.
(In reply to Andrey from comment #19) > Got it working with the patch I suggested upstream. Stay tuned. Great to hear! I'm sorry that I didn't get the chance to test the Qt patch.
That wasn't exactly the same patch, so it's OK )
I added the problematic layouts to our shortcuts test revealing the problem: https://invent.kde.org/plasma/kwin/-/merge_requests/3354/diffs?commit_id=31a640512093ff79673ca827ac46f46ea9739fb1
I have a question to all the reporters. The Qt patch I suggested upstream implies all the shortcuts on QWERTZ keyboard will behave as if they were on QWERTY, assuming US is the first layout: pressing Ctrl+z as it printed on the keycaps will produce Ctrl+Key_Y shortcut instead. This is not the behavior XOrg exposes: for Hebrew, Ctrl+; (a key below Esc) will generate Ctrl+` there, but for German Ctrl+z (where "Z" is on the keycap on QWERTZ) will still generate the same shortcut as printed. Do you think it's OK to deviate from XOrg behavior in a such way?
*** Bug 464183 has been marked as a duplicate of this bug. ***
Hello, I just, (2 minutes ago) installed `plasma-wayland-session` package on my main machine again, I've quickly tried switching virtual desktops (as I use the keyboard to organize everything) and the behavior did not stop. When I used `SUPER + 2` (or whatever else) it switched me to the correct desktop. But when I switched my layout to CZ it still has the same behavior (eg. `SUPER + +` = `SUPER + 1` on the US layout) does nothing. Should I reconfigure all my shortcuts again? Because if it's meant to "transfer over" those settings it either does not correctly or this is still not resolved. I should have more time and capabilities to run some tests on my machine, if you'll be so kind and walk through them as I've never done anything like that for Plasma, I'll be glad to provide more information.
Hi, please note: "Version Fixed In: Qt 6.6.0" above
*** Bug 405404 has been marked as a duplicate of this bug. ***
*** Bug 454668 has been marked as a duplicate of this bug. ***
About scheduling - this bug (and others) relies on updating Plasma 6 to Qt 6.6 - which I assume can't happen before the official Qt 6.6.0 release, that according to the Qt readmap is scheduled for end of September. I hope we won't have to wait a long time after that, so lets hold fingers for an update soon after September.
Hi there, not very bright news from me: the Qt patch I did to solve this and other similar issues has been "attacked" by Qt devs, and they want to revert it: https://codereview.qt-project.org/c/qt/qtbase/+/507078 I had personal meeting with Tor yesterday, but I'm not sure if I can protect the patch eventually. Effectively that means I need your help, help of interested parties - to step in. If we want to get it solved. The relevant Qt issue on Jira is here: https://bugreports.qt.io/browse/QTBUG-108761 You can show your voice there.
Andrey. Your patch has not been "attacked". There is technical disagreement on the validity of the patch. I suggest you approach this in a more constructive manner.
I'm sorry for reopening again but in the light of the patch being reverted I think that it's right to do so. I'd just like to clarify that this is about Wayland vs. X11 global shortcuts handling in Plasma. On X11 shortcuts behave more like physical keys and on Wayland they behave more like software keys (depending on your current layout). For my use case there's no workaround (that I know of) that would allow me to use the same (number row) keys under different layouts for the same shortcuts. I'm sorry if you feel like this should stay closed but from what I understand the proposed solution is being reverted and there's nothing else on the horizon. Reopening could be helpful if the fix will be in Plasma and not Qt in the end.
(In reply to jiri.stefka from comment #32) > I'm sorry for reopening again but in the light of the patch being reverted I > think that it's right to do so. It's alright with the reopening, as it effectively throw us to the beginning. > I'd just like to clarify that this is about Wayland vs. X11 global shortcuts > handling in Plasma. The problem is on CZ you indeed have issue with global shortcuts only, which as a last resort we could try to fix on Plasma side. But on Hebrew (and maybe some other layouts?) the very same problem exists for client Qt apps too, as apps-specific shortcuts are involved: https://bugreports.qt.io/browse/QTBUG-108761 The patch suggested could fix the both problems at once, but was disregarded. So do we have the report separately for apps? If not, let's file it then to make things clear. Thanks.
(In reply to jiri.stefka from comment #32) > I'd just like to clarify that this is about Wayland vs. X11 global shortcuts > handling in Plasma. (In reply to Andrey from comment #33) > But on Hebrew (and maybe some other layouts?) the very same problem exists > for client Qt apps too, as apps-specific shortcuts are involved: > https://bugreports.qt.io/browse/QTBUG-108761 > The patch suggested could fix the both problems at once, but was disregarded. Indeed, the problem with punctuation keys not being translated to the expected key codes is a problem - at least in the Hebrew layout - also on X11, and not only for Qt apps - I most often get annoyed by incorrect shortcuts on Firefox.
(In reply to Oded Arbel from comment #34) > not only for Qt apps - I most often get annoyed by incorrect > shortcuts on Firefox. Ok, the Firefox issue isn't a Qt/kwin issue - it reproduces on XFCE.
The default shortcut used to walk through windows of current application ( alt+` ) does not work with my keyboard. My keyboard layout is brazilian portuguese (abnt2) and ` is a dead key. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.90.0 KDE Frameworks Version: 5.246.0 Qt Version: 6.6.1 Graphics Platform: Wayland
As the Qt fix was discarded, the focus was shifted to try to solve it on XKB level: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/416
*** Bug 423796 has been marked as a duplicate of this bug. ***
*** Bug 485341 has been marked as a duplicate of this bug. ***
*** Bug 485451 has been marked as a duplicate of this bug. ***