[server] Don't send key release for not pressed keys and no double key press
ClosedPublic

Authored by graesslin on Sep 15 2016, 7:35 AM.

Details

Summary

This change makes use of the internal key state in better way. If a
key is not considered pressed, no key release is sent. This can happen
for example if the compositor grabs a key press (global shortcut) but not
the release. The Wayland client cannot do anything with the release as it
never got the press. Thus it doesn't make sense to send the release.

Similar if a key is already pressed, it doesn't make sense to send
another press event. This ensures that if the server sends in repeating
key presses they are filtered out. Key repeat is handled on client side.
Also if several physical keys send the same key code, pressing them at
the same time won't send double press/release event.

This change might cause regressions in KWin in case KWin does not handle
the situation correctly. But that would be a bug in KWin which needs to
be fixed there. If it causes regressions the bug might have shown in
other situations as well.

BUG: 366625
FIXED-IN: 5.27

Diff Detail

Repository
R127 KWayland
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
graesslin updated this revision to Diff 6755.Sep 15 2016, 7:35 AM
graesslin retitled this revision from to [server] Don't send key release for not pressed keys and no double key press.
graesslin updated this object.
graesslin edited the test plan for this revision. (Show Details)
graesslin added reviewers: Plasma on Wayland, KWin.
Restricted Application added projects: Plasma on Wayland, KWin. · View Herald TranscriptSep 15 2016, 7:35 AM
Restricted Application added subscribers: kwin, plasma-devel. · View Herald Transcript

Sounds reasonable enough, but seems to point out an issue in wayland:

If clients "somehow" rely on balanced input, are there artificial releases when a client looses focus?
If not, do you end up with several clients in autorepeat (client side? really? with different behavior in every toolkit?) mode?
If yes, are there likewise artificial presses when gaining focus?
If yes, what happens for a shortcut where client A takes focus to client B on keypress X? X entered in B?

Sounds reasonable enough, but seems to point out an issue in wayland:

If clients "somehow" rely on balanced input, are there artificial releases when a client looses focus?

Yes, on gaining focus it's send all the currently hold keys. The client is supposed to stop all autorepeating etc. on focus loss.

mart accepted this revision.Sep 16 2016, 10:35 AM
mart added a reviewer: mart.
This revision is now accepted and ready to land.Sep 16 2016, 10:35 AM
This revision was automatically updated to reflect the committed changes.