Handle modifier updates in the same sequence as Wayland does

Authored by graesslin on Apr 14 2017, 7:08 PM.



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.

BUG: 377155

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

Diff Detail

R108 KWin
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.
graesslin created this revision.Apr 14 2017, 7:08 PM
Restricted Application added a project: KWin. · View Herald TranscriptApr 14 2017, 7:08 PM
Restricted Application added subscribers: kwin, plasma-devel. · View Herald Transcript

Tested on XWayland 1.19.2 and it works.

mart accepted this revision.Apr 24 2017, 9:38 AM
This revision is now accepted and ready to land.Apr 24 2017, 9:38 AM
This revision was automatically updated to reflect the committed changes.