SUMMARY I have two keyboard layouts (us and fr). The default is us and I use Caps Lock (while pressed) as the main shortcut to switch to fr. I also have the system tray icon which show the layout switching and which I can use to change the layout to fr as default (i.e. to write with the fr without having to press Caps Lock). On flatpak apps (I can't try snap as I don't use it), when I try to use the fr layout using the Caps Lock shortcut, it doesn't work (even though I can see the switch in the system tray icon and it works outside of the flatpack app). If I use the system tray icon to select the fr layout, then it works fine. STEPS TO REPRODUCE 1. Setup two kayboard layout 2. Assign the Caps Lock (while pressed) as the default shortcut to switch layout 3. Open a flatpak app and start typing pressing Caps Lock OBSERVED RESULT The layout doesn't change and it using the default layout EXPECTED RESULT The layout should change to the second layout like it does in non flatpak apps SOFTWARE/OS VERSIONS Operating System: Fedora Linux 40 KDE Plasma Version: 6.1.4 KDE Frameworks Version: 6.5.0 Qt Version: 6.7.2 Kernel Version: 6.10.5-200.fc40.x86_64 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 PRO 6650U with Radeon Graphics Memory: 30.7 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: HP Product Name: HP EliteBook 845 14 inch G9 Notebook PC
Also on Fedora 40, but with all KDE software built from source, I can't reproduce this issue as you've described it: Caps Lock succeeds at cycling through keyboard layouts in all apps, including Flatpak ones (tested Discord sand Telegram). While testing this, I also noticed something weird: pressing Caps Lock not only cycled through layouts, but also actually engaged the normal Caps Lock behavior, so every other I pressed it, allletters would become uppercase. I assume you've found a way to disable this behavior, as it's super annoying. Could you share how you did that? I suspect it may be the cause of the issue.
(In reply to Nate Graham from comment #1) > Also on Fedora 40, but with all KDE software built from source, I can't > reproduce this issue as you've described it: Caps Lock succeeds at cycling > through keyboard layouts in all apps, including Flatpak ones (tested Discord > sand Telegram). > > While testing this, I also noticed something weird: pressing Caps Lock not > only cycled through layouts, but also actually engaged the normal Caps Lock > behavior, so every other I pressed it, allletters would become uppercase. > > I assume you've found a way to disable this behavior, as it's super > annoying. Could you share how you did that? I suspect it may be the cause of > the issue. Hi Nate, Regarding the issue in this report. I've tried a few more things and realised the problem is only with flatpak Electron apps (e.g. Freetube and Signal), as it works fine with flatpak non electron apps. Are those apps you mentioned electron based (I don't use Discord or Telegram). I'm trying to install native (non flatpak electron app) to test and see if the problem is a combination of flatpak + electron or just electron. In any case there is a problem somewhere... Regarding the Caps Lock actually triggering capital letters, it somewhat rings a bell but I don't remember having had this problem anytime recently. It behaves as expected, that is, Caps Lock triggers the temporary layout change, and Alt + Caps Lock triggers original Caps Lock functionality (capital letters).
Ok I was able to install Signal natively from this repo https://software.opensuse.org/download.html?project=network:im:signal&package=signal-desktop and the issue is present! So it's not a problem that occurs with flatpaks but with Electron apps. I'll have change the bug report title to reflect this.
Discord is an Electron app, yeah. And I can't reproduce the issue there, but I do get the issue with Capt Lock also triggering letter case. I'd suggest investigating your settings to figure out why pressing Caps Lock only switches layouts, and doesn't also trigger letter case changes. Maybe you have an additional setting for it set in the advanced keyboard keybindings page?
Created attachment 172814 [details] Shortcut config 1
Created attachment 172815 [details] Shortcut config 2
(In reply to Nate Graham from comment #4) > Discord is an Electron app, yeah. And I can't reproduce the issue there, but > I do get the issue with Capt Lock also triggering letter case. I'd suggest > investigating your settings to figure out why pressing Caps Lock only > switches layouts, and doesn't also trigger letter case changes. Maybe you > have an additional setting for it set in the advanced keyboard keybindings > page? I've attached screenshots of my keyboard layout config. By default the Caps Lock (while pressed) shortcut to trigger keyboard layout change assigns Alt + Caps Lock to trigger the original Caps Lock function (this has been the case for ages, in Plasma 5 too)
And just to reiterate it case it got missed, the issue only occurs when I use the Caps Lock (while pressed). If I just change the layout by clicking on the system tray icon (which makes it change from us to fr), then the change applies and works for all apps (including electron ones).
(In reply to Gauthier from comment #7) > (In reply to Nate Graham from comment #4) > > Discord is an Electron app, yeah. And I can't reproduce the issue there, but > > I do get the issue with Capt Lock also triggering letter case. I'd suggest > > investigating your settings to figure out why pressing Caps Lock only > > switches layouts, and doesn't also trigger letter case changes. Maybe you > > have an additional setting for it set in the advanced keyboard keybindings > > page? > > I've attached screenshots of my keyboard layout config. By default the Caps > Lock (while pressed) shortcut to trigger keyboard layout change assigns Alt > + Caps Lock to trigger the original Caps Lock function (this has been the > case for ages, in Plasma 5 too) And in my case it works just fine (as intended and as it has done for years). Caps Lock changes the keyboard layout while I keep it pressed, while Alt + Caps Lock performs the original Caps Lock function (letter case change). Are you sure you didn't select just "Caps Lock" as a shortcut for layout change instead of "Caps Lock (while pressed)"? This would also explain why you can't reproduce the issue with the Electron apps as it seems to only be a problem with "temporary" (e.g. while pressed) types of layout change. It works fine when the layout change is more permanent (like when changing the layout by clicking on the system tray applet).
Looking at the screenshots, these options are handled by xkb, and not by kglobalacceld. Is this issue reproducible on x11? If not maybe this should be moved to kwin.
(In reply to fanzhuyifan from comment #10) > Looking at the screenshots, these options are handled by xkb, and not by > kglobalacceld. > > Is this issue reproducible on x11? If not maybe this should be moved to kwin. Thanks for the suggestion. I unfortunately cannot try X11 on my system right now. I'll try to wipe up a new VM in the next few days and test it out.
I cannot reproduce this issue. I tried VS Code (Electron), installed natively. I do not have issue with Caps characters either. Distro: OpenSUSE Tumbleweed xkeyboard-config: 2.42 Plasma 6.1.4 Could share your xkeyboard-config package version and your ~/.config/kxkbrc file, or at least its `Options` field? There are many XKB options which may have their labels changed in different XKB versions.
(In reply to Wismill from comment #12) > I do not have issue with Caps characters either. Just to make sure we're on the same page. I don't have problems with Caps characters (i.e. writing capital letters works fine inside electron apps using the shift key). I have an issue with changing keyboard layout to write in another language using the "Caps Lock (while pressed)" shortcut in Electron apps (works fine in any other apps). I can reproduce using Signal Desktop, Jitsi or Freetube. Though I guess it is to note that pressing Caps Lock in Electron apps does not change keyboard layout but also does not make capital letters, it just does nothing. The alternative shortcut Alt + Caps Lock to enable the original Caps Lock function (capital letters) does work fine inside Electron apps. > Could share your xkeyboard-config package version I have version 2.41 installed > and your ~/.config/kxkbrc [Layout] DisplayNames=, LayoutList=us,fr Options=grp:caps_switch ResetOldOptions=true Use=true VariantList=symbolic,
I managed to reproduce this on Wayland like this: 1. Use discord from flatpak 2. Set two keyboard layouts 3. Click Key Bindings -> Switching to another layout -> toggle on "Caps Lock (while pressed), Alt+Caps Lock for the original Caps Lock action", then apply 4. Select text field in discord 5. Type something, switch the layout 6. The old layout still stays on even the new one shows to be updated I am not sure if this is KDE bug or Flatpak bug or Electron bug, but the keyboard layout state is not properly updated when the key is pressed down. Operating System: Fedora Linux 40 KDE Plasma Version: 6.1.90 KDE Frameworks Version: 6.7.0 Qt Version: 6.7.2 Kernel Version: 6.10.10-200.fc40.x86_64 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 3600 6-Core Processor Memory: 15,5 GiB of RAM Graphics Processor: AMD Radeon RX 6600
(In reply to Akseli Lahtinen from comment #14) > I am not sure if this is KDE bug or Flatpak bug or Electron bug I can reproduce on Electron apps not installed as flatpaks...so I'd say it's either an Electron or KDE bug. Though since other ways to change keyboard layout do work fine in Electron apps (like if you just click on the layout icon on the system tray), I have a tendency to think it's related to how KDE sends the signal of the layout change in Electron apps when using "while pressed" type shortcuts.
Are your problematic applications running with native Wayland support or X11? I set *3* layouts us,fr,de I tried using Chromium (*not* flatpack) in both case and I observe the following: - chromium --ozone-platform=wayland: no issue - chromium --ozone-platform=x11: pressing Caps, - Having first layout US active: Q gives Q (expected A), Y gives Z (expected Y); - Having second layout FR active: Q gives Q (ok) but Y gives Y (expected Z) So it seems that the group modifier is applied twice. In the case without only two layouts, it actually wraps to the first layout, so you observe no effect. But wait, I can observe this behavior in Gtk apps using e.g. `GDK_BACKEND=x11 gnome-text-editor` and Qt app e.g. QT_QPA_PLATFORM=xcb kate`. This seems to be an X11 bug only. Keep in mind this is for a Wayland session only, I have not tried a proper X11 session.
(In reply to Wismill from comment #16) > Are your problematic applications running with native Wayland support or X11? > > I set *3* layouts us,fr,de > > I tried using Chromium (*not* flatpack) in both case and I observe the > following: > - chromium --ozone-platform=wayland: no issue > - chromium --ozone-platform=x11: pressing Caps, > - Having first layout US active: Q gives Q (expected A), Y gives Z > (expected Y); > - Having second layout FR active: Q gives Q (ok) but Y gives Y (expected Z) > > So it seems that the group modifier is applied twice. In the case without > only two layouts, it actually wraps to the first layout, so you observe no > effect. > > But wait, I can observe this behavior in Gtk apps using e.g. > `GDK_BACKEND=x11 gnome-text-editor` and Qt app e.g. QT_QPA_PLATFORM=xcb > kate`. > > This seems to be an X11 bug only. Keep in mind this is for a Wayland session > only, I have not tried a proper X11 session. I can reproduce this behaviour. I tried Chromium with --ozone-platform=wayland and it works fine. The app I tried were ungoogle chromium, chromium, Signal Desktop, Jitis, Freetube and they are indeed not running native wayland. The issue is now solved for all of them as I have flags so they start with wayland. Thank you!! I guess while this is a bug for X11 apps running under wayland, but whether or not it is worth fixing I'm not sure (niche case + workarounds available).
This should definitively be fixed, as it is still common to use X11 apps on Wayland (and will be for long, maybe forever). This could also a symptom of a deeper issue a with the keyboard state.