Calling it two times should not matter.

• Pressing Alt -> + 1
• Pressing Tab -> + 2
• Releasing Tab -> +1
• Releasing Alt -> 0

How should that get out of sync? Either something generates an additional event or we lose an event. The question is why and how?

In D4164#77875, @graesslin wrote:

• Releasing Tab -> +1

In this step updateKey is called multiple times. I can't say much more, because I don't know where the function is called from (since it's exported from another program?).

Observation in detail:

• When I press Alt alone or Tab alone or other combinations of Alt+<key> or <mod key>+Tab, updateKey is not called multiple times
• When I hold Alt and only press + release Tab and after this with some meantime release Alt the function is called twice only for the release of Tab.
• When I release Alt and Tab roughly at the same moment, the function is even called for each of the two keys two times (e.g. four times in total on release of both keys)

EDIT: So for now we can say atleast that we don't lose events, but some events are doubled.

updateKey gets called from plugins/platforms/x11/standalone/xinputintegration.cpp - we have there two code paths which generate a key press. I assume there the doubling gets generated.

Ok, so I tested it:

XInputEventFilter and XKeyPressReleaseEventFilter both override the event function of X11EventFilter. I.e. both code paths get executed on every event. Normally the condition ke->event == ke->root stops further execution in XKeyPressReleaseEventFilter, but it is true on Alt+Tab release, which leads to the double decreasing of m_modOnlyShortcut.pressCount.

Why do we need XKeyPressReleaseEventFilter besides XInputEventFilter at all? XInputEventFilter seems to filter all relevant events already alone.

I thought about the problem a little bit and I think we have a conceptional problem in how we detect changes. We try to count the key press/release and just assume it will match up. Bullshit!

Instead we need to track for each key code whether it's pressed. If we get a key code for an already pressed key code, we need to ignore that. If we get a key release for a not pressed key code, we need to ignore that. That's something we already do in KWayland Server for example to not confuse clients by sending double key codes.

Now that will mean a larger change where I am not sure whether it's too much for 5.8 or whether we should combine that with an already in the work refactoring I'm currently working on.

Well, apparently the impact is very minimal, since on most keyboards it's working, so I wouldn't say it's high priority. But something else is, that bug https://bugs.kde.org/show_bug.cgi?id=370920 could be related aswell.

When pressing Ctrl+Alt+F<VT #>, the presses are registered, but not the releases on another VT.

In D4164#90314, @aacid wrote:

Given that T5220 is marked as done, does this need to be commited or can it be discarded?

I can't test the malfunctioning keyboard right now for some other reason. After I've tested it together with D4617 I'll eventually discard the Diff.