I'm not to familiar how layouts work on X11, but on Wayland, does this mean we should temporarly switch to the us layout when receiving events from such a device?

In X the devices each have their own layout and the server does the magic to send out the notifies as you change between them. So this will basically work out of the box.

For Wayland we only expose a single keyboard so yeah, we would have to switch layouts temporarily.

(In reply to Peter Hutterer from comment #2)
> For Wayland we only expose a single keyboard so yeah, we would have to
> switch layouts temporarily.

Doesn't that have performance problems?

I don't think that matters *too* much in this case. The performance problem is largely from switching between layouts, so as long as you don't type on two keyboards simultaneously the hit will be quite small.

(In reply to Peter Hutterer from comment #2)
> In X the devices each have their own layout and the server does the magic to
> send out the notifies as you change between them. So this will basically
> work out of the box.
> 
> For Wayland we only expose a single keyboard so yeah, we would have to
> switch layouts temporarily.

Does it need to be a "clean" us xkb keymap or could we just switch the layout group index on the existing xkb keymap if it includes the us layout?

I'd go with the clean keymap, simply because it's the easiest case to do. As soon as variants and options are in the mix (and potentially run-time modifications like those by xmodmap) it's harder to keep track of the clean maps, so a full switch seems the easiest solution here.

Note to self: the values for XKB_FIXED_LAYOUT and XKB_FIXED_VARIANT are quoted, meaning that we need to remove the quotes before passing the values from udev_device_get_property_value() to xkb_keymap_new_from_names() otherwise the compilation of the keymap fails (please don't ask how I found out...)

So I was looking into this, getting the udev props and creating a per-device keymap when relevant is fairly easy, switching keymaps when needed in mutter not so much.

This cannot be done in the ClutterInputDevice or even ClutterInputDeviceEvdev layers, because there is another keymap in Wayland and that one wouldn;t be updated by the backend.

This cannot be done in MetaWaylandKeyboard or MetaWaylandSeat either, because, while this works for Wayland clients, it doesn't work for gnome-shell itself (so using a yubikey to connect to the VPN won't work, for example)

So best place would be to switch keymaps in meta_display_handle_event() where we route all key events, where we can call clutter_evdev_set_keyboard_map() and then meta_backend_notify_keymap_changed() so all relevant keymaps are updated synchronously, but then this crashes in libxkbcommon...

We need to make sure we don't cause the shell to update the UI showing the layout though. Maybe we should start filter key events in the backend before passing them to the MetaDisplay, and add two "levels" of keymaps (one "selected" and one "active") and make code that listens to the current signal to listen to one of those. We'd then, in the backend, switch the "active" layout depending on the device the event originated from.

GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/mutter/-/issues/

Thank you for your understanding and your help.