On my laptop, KEY_POWER is reported both through event4 (Power Button) and event6 (Keyboard). A single press triggers events from both devices. KWin forwards both events to applications without discarding duplicates. On XWayland, events are reported once so it seems to coalesce. This issue is important on compact keyboards where it is common to remap the power key, for example to Delete. I see two options to solve: - Ignore Power button devices as they are not relevant for Wayland input - Discard additional events for same key at same time from different devices Reproducible: Always
Tricky. KWin processes events one by one, thus it doesn't know that it's the same key event. And I'm not aware of anything in libinput which would allow so. Also we cannot just ignore all power button events as we need the events from there if it does not also trigger the event on the keyboard. Unfortunately my notebooks don't have any power button which would trigger an event... I see two other possibilities: * when going through the xkb translation filter the event out if it didn't change the state (I assume that's what XWayland does) * make it possible to disable input devices
Created attachment 100560 [details] attachment-2802-0.html Weston also correctly handle this, by ignoring press on pressed keys (input.cc:1647). I think this is the way to go for KWin too. Is there already a key state list somewhere ? If I understand correctly, the list, and filter, should be added to KeyboardInputRedirection which is the first object to receive events from all devices. On Thu, Aug 11, 2016 at 2:08 PM, Martin Gräßlin via KDE Bugzilla < bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=366625 > > --- Comment #1 from Martin Gräßlin <mgraesslin@kde.org> --- > Tricky. KWin processes events one by one, thus it doesn't know that it's > the > same key event. And I'm not aware of anything in libinput which would > allow so. > > Also we cannot just ignore all power button events as we need the events > from > there if it does not also trigger the event on the keyboard. Unfortunately > my > notebooks don't have any power button which would trigger an event... > > I see two other possibilities: > * when going through the xkb translation filter the event out if it didn't > change the state (I assume that's what XWayland does) > * make it possible to disable input devices > > -- > You are receiving this mail because: > You reported the bug.
> Weston also correctly handle this, by ignoring press on pressed keys (input.cc:1647). My master checkout has only a modifier change ignore there (function notify_modifiers). As that file is rather large: can you tell me the function name to look at?
Created attachment 100561 [details] attachment-6003-0.html Sorry, that was 1.11.0. it's notify_key:1794 On Fri, Aug 12, 2016 at 4:36 PM, Martin Gräßlin via KDE Bugzilla < bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=366625 > > --- Comment #3 from Martin Gräßlin <mgraesslin@kde.org> --- > > Weston also correctly handle this, by ignoring press on pressed keys > (input.cc:1647). > > My master checkout has only a modifier change ignore there (function > notify_modifiers). As that file is rather large: can you tell me the > function > name to look at? > > -- > You are receiving this mail because: > You reported the bug. >
Hmm the implementation in Weston also doesn't look completely correct to me. It only filters out key presses. Multiple repeats are not filtered out. Similar key state tracking for passing to applications is in KWayland/server/seat_interface.cpp. If we only want to ensure applications don't get duplicate events that would be the place to modify. On the other hand if we don't want KWin to process them at all (e.g. don't trigger global shortcuts), it would be KWin which needs to track all key states and ignore them. Both seems sensible to me, I'm undecided.
I decided to implement the change in KWayland: https://phabricator.kde.org/D2786 So inside KWin such events might still be processed double.
Git commit 98628f9387ff9628b3c7c3fa66b0db4b01ef67c8 by Martin Gräßlin. Committed on 15/09/2016 at 07:35. Pushed by graesslin into branch 'master'. [server] Don't send key release for not pressed keys and no double key press 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. FIXED-IN: 5.27 Reviewers: #plasma_on_wayland, #kwin Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2786 M +15 -0 autotests/client/test_wayland_seat.cpp M +12 -4 src/server/seat_interface.cpp M +1 -1 src/server/seat_interface_p.h http://commits.kde.org/kwayland/98628f9387ff9628b3c7c3fa66b0db4b01ef67c8