On Wayland, applications are responsible for implementing key repeat behavior. In Qt, this is handled by `mRepeatTimer` in `QWaylandInputDevice::Keyboard`.

We’ve observed [an issue in Krita](https://bugs.kde.org/show_bug.cgi?id=506141) where the Wayland event loop stalls immediately after a key press (due to some "heavy computations" immediately triggered by the key press), while we stops reading wayland events, user lifts the keypress, and the `mRepeatTimer` (and its callback) continues running, causing QT to incorrectly fires a autorepeat event (`QKeyEvent` with `autorepeat=true, count=1`) after user has already lift their hand from keyboard.

I understand that it's questionable that Krita's application logic manages to block the wayland event loop for a extended period of time (~1 second) that's longer than key autorepeat threshold, but nonetheless I think QT as a framework ideally should defend against this.

I didn't dig into how the event loop stall happened and I have no idea about QT's wayland event handling. But a potential workaround I can think of is to move Wayland event polling to a location less affected by application-level stalls.