After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 775681 - Honor the XKB_FIXED_LAYOUT/XKB_FIXED_VARIANT udev properties
Honor the XKB_FIXED_LAYOUT/XKB_FIXED_VARIANT udev properties
Status: RESOLVED OBSOLETE
Product: mutter
Classification: Core
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: mutter-maint
mutter-maint
Depends on:
Blocks:
 
 
Reported: 2016-12-06 02:23 UTC by Peter Hutterer
Modified: 2021-07-05 13:52 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Peter Hutterer 2016-12-06 02:23:41 UTC
See the systemd pull request here: https://github.com/systemd/systemd/pull/4778

TLDR: XKB_FIXED_LAYOUT and XKB_FIXED_VARIANT are set on devices that should not have their layout changed by the desktop environment.

These devices are usually non-keyboards that send keyboard events (e.g. a Yubikey) and expect to be in the default 'us' layout to work.
Comment 1 Jonas Ådahl 2016-12-06 02:44:06 UTC
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?
Comment 2 Peter Hutterer 2016-12-06 02:46:53 UTC
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.
Comment 3 Bastien Nocera 2016-12-06 09:36:56 UTC
(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?
Comment 4 Peter Hutterer 2016-12-06 10:49:24 UTC
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.
Comment 5 Rui Matos 2016-12-06 12:18:49 UTC
(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?
Comment 6 Peter Hutterer 2016-12-07 22:47:29 UTC
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.
Comment 7 Olivier Fourdan 2018-03-06 14:26:40 UTC
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...)
Comment 8 Olivier Fourdan 2018-03-08 09:07:05 UTC
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...
Comment 9 Jonas Ådahl 2018-03-13 03:57:15 UTC
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.
Comment 10 GNOME Infrastructure Team 2021-07-05 13:52:19 UTC
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.