Bug 377155 - [Wayland] Caps Lock does not run on XWayland applications
Summary: [Wayland] Caps Lock does not run on XWayland applications
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: input (show other bugs)
Version: 5.9.3
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL: https://phabricator.kde.org/D5452
Keywords:
: 378511 378709 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-03-03 10:47 UTC by tromzy
Modified: 2017-04-27 04:54 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:
mgraesslin: Wayland+
mgraesslin: X11-
mgraesslin: ReviewRequest+


Attachments
attachment-23606-0.html (37 bytes, text/html)
2017-03-03 16:28 UTC, Martin Flöser
Details
attachment-32394-0.html (50 bytes, text/html)
2017-03-03 19:06 UTC, Martin Flöser
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tromzy 2017-03-03 10:47:27 UTC
I use the Caps Lock key to make french accents on capital letters. It works perfectly on Wayland applications in Wayland, but it does not work on XWayland applications.
Comment 1 Martin Flöser 2017-03-03 16:28:09 UTC
Created attachment 104342 [details]
attachment-23606-0.html

Which XWayland version are you using?
Comment 2 tromzy 2017-03-03 17:21:37 UTC
It's XWayland 1.19.1.
Comment 3 Martin Flöser 2017-03-03 19:06:32 UTC
Created attachment 104354 [details]
attachment-32394-0.html

Hmm, so far I thought 1.19 fixed all those issues.
Comment 4 tromzy 2017-03-04 09:58:40 UTC
I upgraded to XWayland 1.19.2 and the problem is still there.
Comment 5 poofeg 2017-04-14 06:43:38 UTC
I have the same issue on XWayland 1.19.3.
Comment 6 poofeg 2017-04-14 07:02:22 UTC
I have to press any of Ctrl, Shift or Alt key after Caps Lock or Num Lock have pressed to state actually changed.
So it is like:
1. Caps Lock (or Num Lock) have turned off state
2. I press Caps Lock key in any XWayland window
3. Led is turning on
4. Caps Lock state is not actually changed in XWayland window
5. I press any of Ctrl, Shift or Alt or change focus to other window
6. Caps Lock state is actually changed
Comment 7 Martin Flöser 2017-04-14 13:48:11 UTC
I can confirm the steps to reproduce. It is not only affecting caps lock, but at least also num lock.

I will verify how weston behaves.
Comment 8 Martin Flöser 2017-04-14 14:01:50 UTC
> I will verify how weston behaves.

On Weston I am not able to reproduce.
Comment 9 Martin Flöser 2017-04-14 14:14:37 UTC
Found a difference in behavior between KWin and Weston.
On KWin the event sequence for caps lock press followed by release is:
1. modifier update (caps lock on)
2. key update (press)
3. modifier update (caps lock off)
4. key update (release)

On Weston it is:
1. key update (press)
2. modifier update (caps lock on)
3. key update (release)
4. modifier update (caps lock off)

Now if we assume that Xwayland reacts on both the modifier state change and the key press we have in the KWin a caps lock enable (through modifier) followed by a capslock disable (through key press).

Interestingly Xwayland 1.18 - which I have on this system - has no problem with the sequence. Personally I find the sequence KWin sends more logical, but whatever ;-)
Comment 10 Martin Flöser 2017-04-14 19:09:48 UTC
Created a patch at: https://phabricator.kde.org/D5452

Please test and verify that it fixes the issue. I currently don't have access to a system with Xwayland 1.19 (as I thought to try to switch to Qt 5.9 which broke my complete system).
Comment 11 Martin Flöser 2017-04-14 19:11:58 UTC
*** Bug 378511 has been marked as a duplicate of this bug. ***
Comment 12 Andrius Štikonas 2017-04-14 19:26:35 UTC
(In reply to Martin Gräßlin from comment #11)
> *** Bug 378511 has been marked as a duplicate of this bug. ***

Hi, yes this is the same issue. Both Num Lock and Caps Lock now work with that patch applied. Thanks!
Comment 13 Martin Flöser 2017-04-14 20:16:21 UTC
Thanks for such quick testing!
Comment 14 Martin Flöser 2017-04-24 19:01:27 UTC
Git commit a039c2760f6458059dfc91b035a5e03022a31d12 by Martin Gräßlin.
Committed on 24/04/2017 at 19:00.
Pushed by graesslin into branch 'master'.

Handle modifier updates in the same sequence as Wayland does

Summary:
Consider the case that capslock gets pressed and released.
In the case of Weston we have a sequence of:
 1. Key press event
 2. Modifier changed event
 3. Key release event
 4. Modifier changed event

KWin however used to send the events in the following sequence:
 1. Modifier changed event (on key press)
 2. Key press event
 3. Modifier changed event (on key release)
 4. Key release event

It looks like Xwayland is not able to properly process the sequence
sent by KWin. And in fact KWin's sequence is wrong as it sends a state
which does not match. We report that the caps lock is pressed in the
modifiers prior to the application getting informed about the key press
of caps lock.

This change aligns KWin's implementation to the behavior of Weston. The
main difference is that when modifiers change Xkb internally caches the
serialized modifier states. And KeyboardInputRedirection just forwards
the modifiers to KWayland::Server::SeatInterface once the processing has
finished. SeatInterface ignores the forwarding if no states changes, so
it is fine to do it that way.

Test Plan:
Not yet tested with an affected Xwayland as I only have 1.18 and the
problem started with 1.19. But verified the sequence of events with WAYLAND_DEBUG
and caps lock stil working in QtWayland clients and Xwayland 1.18

Reviewers: #kwin, #plasma

Subscribers: plasma-devel, kwin

Tags: #kwin

Differential Revision: https://phabricator.kde.org/D5452

M  +2    -0    keyboard_input.cpp
M  +21   -9    xkb.cpp
M  +11   -0    xkb.h

https://commits.kde.org/kwin/a039c2760f6458059dfc91b035a5e03022a31d12
Comment 15 Martin Flöser 2017-04-27 04:54:56 UTC
*** Bug 378709 has been marked as a duplicate of this bug. ***