375518 2017-01-24 20:22:40 +0000 global shortcuts do not work for non-Latin symbols of foreign keyboard layouts 2026-03-04 15:26:57 +0000 1 1 4 Plasma kwin input git master Compiled Sources Linux RESOLVED WAITINGFORINFO https://bugs.kde.org/show_bug.cgi?id=350816 https://bugs.kde.org/show_bug.cgi?id=435651 https://bugs.kde.org/show_bug.cgi?id=309193 https://bugs.kde.org/show_bug.cgi?id=453461 https://bugs.kde.org/show_bug.cgi?id=434949 https://bugs.kde.org/show_bug.cgi?id=453661 https://bugs.kde.org/show_bug.cgi?id=415995 https://bugs.kde.org/show_bug.cgi?id=462274 https://bugreports.qt.io/browse/QTBUG-90611 VHI normal --- 1 akreuzkamp butirsky 80p3fy75dc aspotashev bharadwaj.raju777 bizyaev butirsky contact desintegr dev dmayr.dev dmitry.ashkadov eugene.savitsky genet h.klene igor.poboiko jany.belluz kirill.bogdanenko kiwiiii lemondejojo leonard mail mail nate notuxius nowrep praveen ticket.kde.djr4kjpch5320z5k tony.ducrocq xalt7x.service zir0faive zvova7890 https://invent.kde.org/plasma/kwin/commit/91f47c909237437e93ceb84326ae1eead0c3e3e7 Plasma 5.22 with a Qt version that has https://codereview.qt-project.org/c/qt/qtbase/+/339895 merged 0 oldest_to_newest 1656480 0 akreuzkamp 2017-01-24 20:22:40 +0000 I'm using a EU (US + special keys) keyboard layout, but occasionally I switch to a greek layout to enter greek symbols. On X11 I used to use CTRL+ALT+K to switch to greek and CTRL+ALT+K again to switch back. On Wayland, I can use CTRL+ALT+K to switch to greek, but I can't switch back. Probably this is, because I now effectively enter CTRL+ALT+Kappa. I'm not 100% sure, how global shortcuts are supposed to work with foreign keyboard layouts, but especially in regards of the "switch keyboard layout" shortcut this is odd. Maybe CTRL+ALT+Kappa is simply missing as a trigger for the shortcut or KWin's handling should be different here. 1656611 1 mgraesslin 2017-01-25 09:53:08 +0000 On Wayland we use the actual keyboard layout. Which is something which in my opinion makes a lot of sense. If you enter ctrl+alt+k it's using the config printed on they keyboard and the user does not have to know where the k key is on the English layout. So this is in my opinion a huge improvement over X11. Especially as on X11 it was inconsistent or just broken. AFAIK on X11 global shortcuts just does not notice when the layout changes. If you would start with greek layout as primary layout, it should be also broken. Now the problem is tricky. Do you know whether there is a key in the layout which renders a "k"? Or whether the k key actually generates multiple keysyms? If it generated kappa and k, we could change the code to support all syms. 1660187 2 igor.poboiko 2017-02-10 20:01:10 +0000 Same here with russian layout (which is obviously completely different from english). (In reply to Martin Gräßlin from comment #1) > Now the problem is tricky. Do you know whether there is a key in the layout > which renders a "k"? Or whether the k key actually generates multiple > keysyms? If it generated kappa and k, we could change the code to support > all syms. I suppose Greek layout just doesn't have a "k" symbol at all. Does such layouts even exist (where the same symbol is placed on the some place in one layout and on another place on second layout)? Can we just bind it not to the symbol but to key ("scan code") instead? (however, it might break if user attaches another keyboard...) Or just map everything to English layout? (it might be weird if user isn't familiar with latin alphabet) Or maybe iterate over all configured layouts and check if pressed key code corresponds to a shortcut on any of it? 1660262 3 mgraesslin 2017-02-11 06:44:11 +0000 Am 10. Februar 2017 21:01:10 MEZ schrieb Igor Poboiko <bugzilla_noreply@kde.org>: >https://bugs.kde.org/show_bug.cgi?id=375518 > >Igor Poboiko <igor.poboiko@gmail.com> changed: > > What |Removed |Added >---------------------------------------------------------------------------- > CC| |igor.poboiko@gmail.com > >--- Comment #2 from Igor Poboiko <igor.poboiko@gmail.com> --- >Same here with russian layout (which is obviously completely different >from >english). > >(In reply to Martin Gräßlin from comment #1) >> Now the problem is tricky. Do you know whether there is a key in the >layout >> which renders a "k"? Or whether the k key actually generates multiple >> keysyms? If it generated kappa and k, we could change the code to >support >> all syms. > >I suppose Greek layout just doesn't have a "k" symbol at all. Does such >layouts >even exist (where the same symbol is placed on the some place in one >layout and >on another place on second layout)? > >Can we just bind it not to the symbol but to key ("scan code") instead? Unfortunately not. It's all keysym based. >(however, it might break if user attaches another keyboard...) >Or just map everything to English layout? (it might be weird if user >isn't >familiar with latin alphabet) Requires the English layout to be part of the Keymap. So not a general solution. >Or maybe iterate over all configured layouts and check if pressed key >code >corresponds to a shortcut on any of it? In general I like this idea, but I fear it's technically not possible. I think the best solution would be to start translating the shortcuts. 1771073 4 notuxius 2018-08-09 09:20:48 +0000 Ctrl+Alt+K shortcut switches keyboard layouts from Ukrainian to Russian and from Russian to English in X11 but not in Wayland Distribution: KDE neon Developer Edition Kernel: 4.15.0-29-generic Plasma: 5.13.80 Apps: 18.11.70 Qt: 5.11.1 Frameworks: 5.48.0 1791096 5 h.klene 2018-10-01 21:19:52 +0000 *** Bug 365812 has been marked as a duplicate of this bug. *** 1791100 6 h.klene 2018-10-01 21:29:49 +0000 Does killing & restarting /usr/bin/kglobalaccel5 help? see: bug 350816 1791153 7 mgraesslin 2018-10-02 04:00:58 +0000 (In reply to Holger from comment #6) > Does killing & restarting /usr/bin/kglobalaccel5 help? > > see: bug 350816 Certainly not: this is Wayland and kglobalaccel is not used. 1848133 8 igor.poboiko 2019-04-02 09:57:15 +0000 Related link to the same bug in Qt: https://bugreports.qt.io/browse/QTBUG-66497 1866297 9 igor.poboiko 2019-06-30 11:06:00 +0000 *** Bug 407703 has been marked as a duplicate of this bug. *** 1990631 10 butirsky 2021-01-03 17:14:01 +0000 Could someone try it on other compositor? It's still not clear to me if it KWin or Qt bug 1997553 11 butirsky 2021-01-25 16:46:07 +0000 I've opened Qt bug report: https://bugreports.qt.io/browse/QTBUG-90611 1999636 12 leonard 2021-02-02 14:27:49 +0000 Have you tried switching the order of layouts? In https://bugs.kde.org/show_bug.cgi?id=432367 I observe related issues that only occur if US layout is on position 1 in the settings screen and my custom layout is on position 2. However, when moving the custom layout to position 1 and US layout to position 2 fixes there are no problems. Note that the Layout Settings have Move Up/Down buttons to change layout order. 2008207 13 bharadwaj.raju777 2021-03-03 11:17:15 +0000 >> Or maybe iterate over all configured layouts and >> check if pressed key code corresponds to a shortcut on any of it? > In general I like this idea, but I fear it's technically not possible. Would it be a decent solution to allow the user to configure which of their layouts is used to interpret global shortcuts? 2008212 14 butirsky 2021-03-03 11:45:11 +0000 (In reply to Bharadwaj Raju from comment #13) > Would it be a decent solution to allow the user to configure which of their > layouts is used to interpret global shortcuts? Qt already handles this by searching for a Latin1 shortcut for a key unconditionally, it occurs in special private library: https://code.woboq.org/qt5/qtbase/src/platformsupport/input/xkbcommon/qxkbcommon.cpp.html#525 We are going to just link to that library so the behavior will be consistent. 2015563 15 bug-janitor 2021-03-15 18:01:53 +0000 A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/786 2019666 16 nate 2021-03-26 14:47:59 +0000 *** Bug 434949 has been marked as a duplicate of this bug. *** 2019679 17 nate 2021-03-26 16:07:34 +0000 *** Bug 318666 has been marked as a duplicate of this bug. *** 2019681 18 nate 2021-03-26 16:07:59 +0000 *** Bug 167428 has been marked as a duplicate of this bug. *** 2019683 19 nate 2021-03-26 16:08:26 +0000 *** Bug 252594 has been marked as a duplicate of this bug. *** 2019685 20 nate 2021-03-26 16:08:51 +0000 *** Bug 260260 has been marked as a duplicate of this bug. *** 2019687 21 nate 2021-03-26 16:09:39 +0000 *** Bug 176514 has been marked as a duplicate of this bug. *** 2019689 22 nate 2021-03-26 16:10:10 +0000 *** Bug 177321 has been marked as a duplicate of this bug. *** 2019691 23 nate 2021-03-26 16:10:29 +0000 *** Bug 182434 has been marked as a duplicate of this bug. *** 2019693 24 nate 2021-03-26 16:10:34 +0000 *** Bug 187730 has been marked as a duplicate of this bug. *** 2019695 25 nate 2021-03-26 16:11:08 +0000 *** Bug 320612 has been marked as a duplicate of this bug. *** 2019699 26 nate 2021-03-26 16:13:17 +0000 *** Bug 422329 has been marked as a duplicate of this bug. *** 2022582 27 butirsky 2021-04-05 19:43:10 +0000 Git commit 91f47c909237437e93ceb84326ae1eead0c3e3e7 by Andrey Butirsky. Committed on 05/04/2021 at 19:39. Pushed by butirsky into branch 'master'. fix global shortcuts for non-Latin symbols Re-use Qt's implementation of handling non-Latin layouts here For full ASCII range support (Alt+`, etc.) Qt needs to be patched still, see QTBUG-90611 M +2 -0 CMakeLists.txt M +1 -0 autotests/CMakeLists.txt M +83 -0 autotests/integration/globalshortcuts_test.cpp M +0 -21 autotests/test_xkb.cpp M +1 -0 src/CMakeLists.txt M +4 -5 src/input.cpp M +3 -2 src/keyboard_input.cpp M +26 -22 src/xkb.cpp M +5 -4 src/xkb.h D +0 -312 src/xkb_qt_mapping.h https://invent.kde.org/plasma/kwin/commit/91f47c909237437e93ceb84326ae1eead0c3e3e7 2022589 28 butirsky 2021-04-05 20:03:01 +0000 Note: For full ASCII range support (Alt+`, etc.) Qt needs to be patched still: [QTBUG-90611](https://bugreports.qt.io/browse/QTBUG-90611), fix: https://codereview.qt-project.org/c/qt/qtbase/+/339895. Without patched Qt, only alphabetical key shortcuts (on any layout) brought back to work. 2026262 29 bharadwaj.raju777 2021-04-20 09:30:52 +0000 *** Bug 309193 has been marked as a duplicate of this bug. *** 2026271 30 butirsky 2021-04-20 09:43:25 +0000 Good catch. Thanks! (still, please pay attention this bug is about global shortcuts) 2026276 31 bharadwaj.raju777 2021-04-20 09:53:27 +0000 (In reply to Andrey from comment #30) > Good catch. Thanks! > (still, please pay attention this bug is about global shortcuts) Yes, however the non-global i.e. application shortcuts problem is fixed as of now (tested on Neon unstable), and the only remaining part was the global shortcuts bit (fixed here). 2026284 32 butirsky 2021-04-20 10:00:52 +0000 Yes, that's because global and non-global ones are now using the same internal Qt function which handles this. 2032427 33 nate 2021-05-13 17:08:27 +0000 *** Bug 437043 has been marked as a duplicate of this bug. *** 2054248 34 nate 2021-08-18 16:03:25 +0000 *** Bug 441103 has been marked as a duplicate of this bug. *** 2131025 35 lemondejojo 2022-06-14 14:04:58 +0000 Dear all, This bug had been reported to be fixed over a year ago, but I am still experiencing it on all my installs. I opened a bug request (448154) five months ago, that was closed duplicate immediately, yet the bug remains, although I am running the latest Kubuntu with KDE backports. I am basically unable to use accented chars such as ç or é in global keyboard shortcuts, which makes a lot of my keys useless for <Ctrl>+key bindings. Can you tell me what the state is? Thanks a lot!!! Operating System: Ubuntu 22.04 KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.3 Kernel Version: 5.15.0-37-generic (64-bit) Graphics Platform: X11 2131627 36 butirsky 2022-06-15 21:36:06 +0000 Johannes, please note the bug was filed for Wayland, please see if you still can reproduce the issue there. 2131746 37 lemondejojo 2022-06-16 08:28:06 +0000 You are right: I don't experience the bug in Wayland! Sorry that I did not realise that it was Wayland specific here! But that's not an honest point because several bug files that have been marked duplicate of this one imply X11, and were closed regardless. Besides, the bug isn't really a purely Xorg thing as accented keyboard shortcuts only break in KDE under Xorg, not in Gnome or Cinnamon using Xorg. I am therefore re-closing that one (sorry!) and will awake another one that is more Xorg specific! 2164790 38 mail 2022-10-24 10:56:08 +0000 Global hotkey Shift+Win+2 is still broken for me on layout switch to non-English with other Shift+2 symbol (english has @ there, my layout has ") in Wayland , it worked on X11. Wayland just tries to insert ". Operating System: Debian GNU/Linux Testing (Bookworm) KDE Plasma Version: 5.26.0 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.4 Kernel Version: 5.19.0-2-amd64 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5800U with Radeon Graphics Memory: 15.0 GiB of RAM Graphics Processor: RENOIR Manufacturer: HP Product Name: HP Pavilion Aero Laptop 13-be0xxx 2164802 39 mail 2022-10-24 11:55:36 +0000 (In reply to George Melikov from comment #38) > Global hotkey Shift+Win+2 is still broken for me on layout switch to > non-English with other Shift+2 symbol (english has @ there, my layout has ") > in Wayland , it worked on X11. Wayland just tries to insert ". > > Operating System: Debian GNU/Linux Testing (Bookworm) > KDE Plasma Version: 5.26.0 > KDE Frameworks Version: 5.98.0 > Qt Version: 5.15.4 > Kernel Version: 5.19.0-2-amd64 (64-bit) > Graphics Platform: Wayland > Processors: 16 × AMD Ryzen 7 5800U with Radeon Graphics > Memory: 15.0 GiB of RAM > Graphics Processor: RENOIR > Manufacturer: HP > Product Name: HP Pavilion Aero Laptop 13-be0xxx Ah, even more interesting - it doesn't work only when there is active input focus, for ex. if input focus is on browser's url field, Shift+win+2 will be interpreted as shift+2 and " will be added in url field. If there is no active input field - global hotkey works. 2164964 40 butirsky 2022-10-24 20:39:04 +0000 Please try on dirsto with patched Qt: https://community.kde.org/Qt5PatchCollection 2164972 41 mail 2022-10-24 20:50:17 +0000 (In reply to Andrey from comment #40) > Please try on dirsto with patched Qt: > https://community.kde.org/Qt5PatchCollection Looks like I already have this commit https://salsa.debian.org/qt-kde-team/qt/qtwayland/-/merge_requests/5/diffs?commit_id=d5955f471ef19686137b4f5f835d45fedc0eaa08 (Add patches from KDE's Qt 5 Patch Collection up to 2022-05-14) in my system https://packages.debian.org/bookworm/qtwayland5 , so it's reproducible on Qt5PatchCollection from 2022-05-14. Can't guarantee for 100% Qt5PatchCollection identity though. 2166152 42 butirsky 2022-10-27 22:19:17 +0000 (In reply to George Melikov from comment #39) > Ah, even more interesting - it doesn't work only when there is active input > focus, for ex. if input focus is on browser's url field, Shift+win+2 will be > interpreted as shift+2 and " will be added in url field. > If there is no active input field - global hotkey works. Maybe it's a different issue then? Could you file it separately? The one here didn't work regardless of the focus. 2172171 43 bug-janitor 2022-11-11 05:20:03 +0000 Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! 2177950 44 bug-janitor 2022-11-26 05:17:38 +0000 This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! 2182047 45 butirsky 2022-12-06 17:45:16 +0000 (In reply to George Melikov from comment #41) > (In reply to Andrey from comment #40) > > Please try on dirsto with patched Qt: > > https://community.kde.org/Qt5PatchCollection > > Looks like I already have this commit > https://salsa.debian.org/qt-kde-team/qt/qtwayland/-/merge_requests/5 You haven't, it's even wrong repo. Unfortunately, Debian applies KDE's Qt patches just partially. This is the source of many confusions, apparently. When I realized it, I immediately initiated inclusion of the patch in question but it happened just recently: it will be part of qtbase-opensource-src 5.15.6+dfsg-5. I also asked the Debian's Qt maintainer to apply all the patches in the future: https://salsa.debian.org/qt-kde-team/qt/qtwayland/-/merge_requests/5#note_358970 Please provide the feedback when you get the patch needed. 2187808 46 butirsky 2022-12-21 16:17:17 +0000 (In reply to George Melikov from comment #38) > Global hotkey Shift+Win+2 is still broken for me on layout switch to > non-English with other Shift+2 symbol (english has @ there, my layout has ") > in Wayland , it worked on X11. Wayland just tries to insert ". Right, this case is still broken but has a separate report: bug 453661 Essentially, if a key produces different Latin symbol on other layout, the shortcut won't work (but it will if the symbol is not Latin). 2282481 47 xalt7x.service 2024-01-22 23:13:06 +0000 (In reply to Andrey from comment #46) > (In reply to George Melikov from comment #38) > > Global hotkey Shift+Win+2 is still broken for me on layout switch to > > non-English with other Shift+2 symbol (english has @ there, my layout has ") > > in Wayland , it worked on X11. Wayland just tries to insert ". > Right, this case is still broken but has a separate report: > bug 453661 > > Essentially, if a key produces different Latin symbol on other layout, the > shortcut won't work (but it will if the symbol is not Latin). So basically: - if my keyboard has non-Latin (e.g. Cyrillic) symbol on the same place as the Latin symbol - shortcut will work - If my keyboard has some other Latin symbol - shortcut won't work and I will need to create another shortcut using different keyboard keyboard For me "Walk Through Windows of Current Application" is broken by default since Ukrainian keyboard layout has another Latin symbol (apostrophe) on the same place as QuoteLeft/Grave symbol. Is there any hope to workaround it on the KDE side? I also wonder, why do we need a separate issue (https://bugs.kde.org/show_bug.cgi?id=453661) for this case. This issue is also about Wayland session but it's more noticeable and has more useful information. 2282904 48 butirsky 2024-01-24 14:31:34 +0000 (In reply to Yevhen from comment #47) > Is there any hope to workaround it on the KDE side? It was an attempt to solve that on Qt side once and for all but that was failed, read up from here: https://bugs.kde.org/show_bug.cgi?id=453661#c30 (In reply to Andrey from comment #37) https://bugs.kde.org/show_bug.cgi?id=453661#c37 > 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 If (and only if) that fails too, we could think about customizing KWin behavior, as a _very_ last resort. There is a hope but needs to be tested: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/428 2500597 49 eugene.savitsky 2026-03-04 15:26:57 +0000 It was fixed upstream: https://github.com/xkbcommon/libxkbcommon/pull/929 What should KDE do to implement it?