Wrong (non modified) key under Wayland when multiple events combined in single SYN_REPORT

[Carlos Garnacho]

Hi!,

On Tue, Sep 13, 2022 at 11:36 AM Hans de Goede <hdegoede at redhat.com> wrote:
>
> Hi,
>
> On 9/12/22 23:20, Peter wrote:
> > Hi all,
> >
> >
> > Op maandag 12 september 2022 om 15:14:09 +0200 schreef Juerd Waalboer <juerd at tnx.nl>:
> >> Hans de Goede skribis 2022-09-12  7:16 (+0200):
> >>> During a big hacker event in the Netherlands this summer (MCH) the logistics
> >>> team used custom barcodes to keep track of inventory. These custom barcodes
> >>> contain a # symbol.
> >>
> >> In other barcodes, @ symbols. Quite possibly anything with shifted characters; I vaguely recall a mixed case (ascii) string where the uppercasing was on the wrong letter.
> >
> > Yes, that definitely also happened.
> >
> >>
> >>> Juerd, we did not discuss how you were running Wayland (which compositor),
> >>> I guess you were using GNOME3 when you hit this ?
> >>
> >> I'm not sure, as I only encountered the bug as an end user and suggested changing to X to work around it (which worked). I've added Peter Hazenberg to the CC list; he installed and maintained the computers, and is familiar with the bug. Peter, can you confirm that we were using GNOME 3 in both Wayland and X?
> >
> > Yes, we used gnome 3. It was mostly a boring default Fedora 36 Workstation installation.
> >
> > Good to hear Hans already reproduced the issue at the mentioned hackerspace, I assume with the exact same hardware
>
> Yes I reproduced it on my own laptop inside a terminal under GNOME3. I suspect that it reproduces on any (VTE based?) terminal running under GNOME3 Wayland when using the right barcode-scanner model and scanning specific barcodes.

Thanks Hans/Juerd/Peter. I can reproduce this issue on GNOME Shell
with the evemu logs provided. From my multiple tries, the libinput
debug output seems pretty much consistent and in line with the evemu
output (i.e. press shift, release 't', press '3', release shift), so
there does not seem to be any issue there. At the wayland level, the
wl_keyboard.modifier events received by the client are somewhat amiss
though.

Amusingly, running on plain Mutter (e.g. `mutter --wayland
--display-server` on a TTY) does also seem to fix the issue. The most
immediate difference I can think of is the involvement of input
methods.

Since this does not seem to be a generic Wayland issue, feel free to
file a bug at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues and
move discussion there, this might still end up in Mutter, or in IBus,
unclear yet.

Cheers,
  Carlos