| Summary: | Keyboard layout switcher not working correctly | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Igor Poboiko <igor.poboiko> |
| Component: | input | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version First Reported In: | 5.7.3 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Igor Poboiko
2016-08-13 09:36:57 UTC
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. |