Resolute: Regression in keyboard autorepeat behaviour

Ubuntu Version:

26.04

Desktop Environment (if applicable):
GNOME 50

Problem Description:
I’ve updated from 24.04 to 26.04 and found a regression regarding keyboard autorepeat behaviour. When autorepeating one key and I switch to second key – without releasing the first key strictly serially first – the autorepeat for the second key won’t kick in. This can be reproduced with any two keys I assume, most prominently the cursor keys. I tried both terminal (Ptyxis) and a GTK app (Gnome Text Editor). I tried two keyboards connected to the same machine (internal notebook keyboard and external USB).

Test case:

  • Open any decently sized text file (e.g. log file) in either nano or Gnome Text Editor (or I assume any other editor). The cursor should by placed at the beginning of the file.
  • Press and hold key down until the key autorepeats. Cursor will move down continuously.
  • Without releasing down, press and hold right, then release down. The cursor will move one char right but autorepeat won’t kick in.

The issue wasn’t present in 24.04. One could argue you’re supposed to press keys strictly serially. But I’m afraid that’s not reality for most (somewhat advanced) keyboard users.

Is it a known issue? If so, is there a link to a bug report? Where should I report this?

This does look like a genuine regression rather than expected behavior.

Since you reproduced it across multiple applications (Ptyxis and GNOME Text Editor) and with both internal and external keyboards, this points away from hardware and more toward the input stack, likely Mutter/Wayland key repeat handling.

There is an older GNOME bug describing very similar behavior involving autorepeat handoff between simultaneously held keys:

https://bugzilla.gnome.org/show_bug.cgi?id=781285

Related duplicate:

https://bugzilla.gnome.org/show_bug.cgi?id=781896

Your reproduction sequence - holding one cursor key, pressing a second before releasing the first, and the second key failing to inherit repeat - sounds closely related, and may suggest a regression in similar logic in GNOME 50.

One thing worth testing first is whether it also happens in a GNOME on Xorg session. If it is Wayland-only, that would narrow it down considerably and strengthen a Mutter bug report.

If it reproduces there as well, I would report it upstream against Mutter on GNOME GitLab, and optionally as an Ubuntu regression. Your post already contains a solid minimal reproducer

Thanks for your help! My 26.04 doesn’t have X.org any more. So I reported it against the Ubuntu mutter package first, and can optionally take it to upstream as well depending on feedback on that issue.

Meanwhile I confirmed the issue exists also for an old USB keyboard and then connected that keyboard to a Bazzite Linux (stable, Gnome/Mutter 49) and noticed that system doesn’t have the issue with the same keyboard.