As I've read somewhere, KWin is also responsible for keyboard layout switcher in Wayland, so I'm reporting this issue to KWin. Please correct me if I'm wrong. I use Ctrl+Shift shortcut for layout switching, and I have two layouts: "ru" (Russian) and "en" (English). The current behavior is following: assume current layout is English. I type, then I press Ctrl+Shift. Plasma shows a popup that layout is switched to Russian; however, it isn't; and I keep typing in English. I've found out, that it does switch if and only if I press one of modifier-keys (either Ctrl, Alt or Shift) after pressing Ctrl+Shift, so the shortcut really becomes "Ctrl+Shift Ctrl". It is 100% reproducible on my machine. BTW, it also suffers from notorious fd.o bug 865 (https://bugs.freedesktop.org/show_bug.cgi?id=865): it breaks "Ctrl+Shift+Something" shortcuts. Well, not really breaks, these shortcuts work. But it also switches layout, which isn't what I want. I'm not sure if it is known issue or should I open a new bug. Reproducible: Always
Yep it's correct that KWin is responsible for the layout switching. It's an interesting bug I have to say. What we need to figure out is whether it's "only" broken in clients or whether it's broken in general. For that a few things to test: 1. Please use present windows filter and try to switch layout there and see whether it gets applied instantly 2. Once with a Qt/Wayland application focused 3. Once with a XWayland application focused 4. Once with a GTK/Wayland (only supported on KWin master) focused Given the linked fd.o bug I could imagine that xkbcommon just cannot handle the layout switching with modifiers only.
(In reply to Martin Gräßlin from comment #1) > Yep it's correct that KWin is responsible for the layout switching. It's an > interesting bug I have to say. > > What we need to figure out is whether it's "only" broken in clients or > whether it's broken in general. > > For that a few things to test: > 1. Please use present windows filter and try to switch layout there and see > whether it gets applied instantly Do you mean the desktop effect? The layout switching works fine there. > 2. Once with a Qt/Wayland application focused Not yet sure how to tell if the application is using Wayland or XWayland. I've tried Dolphin, and it also works fine. ("About Dolphin" window says it's using wayland) > 3. Once with a XWayland application focused I've tried several GTK applications (with KWin 5.7.3; assuming they use XWayland), like Inkscape or Gimp; their behavior is wrong. Same for Yakuake (it says "The xcb windowing system" in the "About" dialog). > 4. Once with a GTK/Wayland (only supported on KWin master) focused I've just tried rebuilding KWin from master ("kwin_wayland --version" now says "kwin 5.7.90"), restarted and checked gimp and inkscape, they are still affected. But I'm still not sure if they were using XWayland or ran natively now. > Given the linked fd.o bug I could imagine that xkbcommon just cannot handle > the layout switching with modifiers only. Well, there is a proposed patch which does the thing. I was just hoping that this problem will disappear on Wayland. Or is xkbcommon related to Wayland too?
> Or is xkbcommon related to Wayland too? Yes xkbcommon is also used on Wayland for keyboard layouts.
Given the investigation it looks like being related to Xwayland windows. It works for Qt applications on Wayland, but not for those on X11, which would indicate a bug in Xwayland. The input handling in Xwayland changed a lot for 1.19 and there are many bugs fixed. Before I report it upstream I need to verify that it's not already fixed.
Just gave it a try. I'm using XWayland 1.18.4 + some patches from XWayland 1.19. I added ctrl+shift as layout switcher in keyboard configuration module, and tried it on this Firefox (X11) window: layout switched correctly. Given that I assume that this will be fixed with XWayland 1.19. If you still encounter it once you have 1.19 (release is schedule for the next month) please reopen.