xkb protocol (setxkbmap tool) also has no Wayland equivalent

[kkofler]

One item I miss in your list here, and also in https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277, is the lack of a standard protocol for setting the keyboard layout. See the discussion under https://github.com/calamares/calamares/pull/2180. The official recommendation is to just set the keyboard layout through systemd locale1, but that is not actually going to work without a reboot (if at all) in most situations. Under X11, setxkbmap works instantly for the entire session (and, at least in an installer context, should in general be done in addition to a change to the global system configuration, doing just one will not work as expected). Some Wayland compositors such as kwin_wayland have their own non-standard ways to apply keyboard settings to running sessions, but those are entirely implementation-dependent.

[probonopd]

Thanks @kkofler. Very good point that I have missed so far.

Would you consider to send a pull request for README.md?

Thank you very much!

[myownfriend]

I'm not sure I understand why it would make sense to have Wayland protocol to set keyboard layout. It doesn't have anything to do with compositing, window management, or sending input to a client. This is better handled outside of Wayland so that the same solution could be used regardless of display server.

[kkofler]

Because the Wayland compositor is what processes input and passes it on to applications. It will normally use a library, libinput, for that, but the layout is selected by the compositor.

[myownfriend]

Because the Wayland compositor is what processes input and passes it on to applications. It will normally use a library, libinput, for that, but the layout is selected by the compositor.

Yes, the layout can generally be changed by the compositor but why does that make setting the keyboard layout something that's a good fit for Wayland? Generally when people set the keyboard layout, they don't want to do it just for an X11 session or just for a Wayland session, they want to set it per keyboard and have it apply to whatever gets input from the keyboard. I don't see why any client that sets the keyboard layout, like an installer, should need to use divergent methods depend on the display server/compositor because the display server/compositor seems irrelevant to keyboard layout. The keyboard layout would be just as relevant to terminal use as it would for a GUI.

How do other installers like Anaconda or Ubuntu's installer do it?

[kkofler]

Of course the installer also wants to set the layout systemwide, typically in the chroot in which the installed system resides. But it also at the same time wants to set the layout in its running session so you can type into the installer itself with the keyboard layout you just selected. These are 2 different things. The first is best done by writing configuration files in the chroot. The second is best done by running something like setxkbmap to immediately apply the settings to the running session. And that is where Wayland lacks a standardized method. Keep in mind that the installer typically needs to do both, it is not an either-or thing.

[ssokolow]

I'm not sure I understand why it would make sense to have Wayland protocol to set keyboard layout. It doesn't have anything to do with compositing, window management, or sending input to a client. This is better handled outside of Wayland so that the same solution could be used regardless of display server.

Because, if I remember correctly, the maintainer of libinput absolutely refused to be responsible for providing a desktop-agnostic bypass (eg. config file) to "the compositor that links against libinput is responsible for wrapping the various C APIs it exposes for configuration"... as such, there needs to be an agreed upon way for compositors to proxy those APIs out to work around the libinput dev's obstinacy.

In short, instead of libinput specifying a schema for a libinput.json that you can feed into something like set_config(char[] file_contents), it's Wayland's job to cook up an equivalent which, if it gets adopted broadly, will probably wind up turning the de facto standard way to do things into "Compositors link against libinputwrapper which links against libinput" in the grand Linux Audio Stack tradition.

[probonopd]

One of my least favorite aspects of X11 is that the keyboard layout inside X11 needs to be configured separately from the world outside of X11 (i.e., text console). So maybe it's best to have Wayland just use what the rest of the system uses, and not make Wayland a participant in defining the keyboard layout at all? (Probably I am overlooking some complex edge cases.)

[kkofler]

Well, xkb and libinput support a lot more options and special cases than the console keyboard layouts. Even the modern converted (from xkb layouts) console keyboard layouts (which are also not universally used, a lot of distributions still ship the old legacy console keyboard layouts) end up being only a subset due to all the options xkb supports on top of those layouts. The legacy console keyboard layouts are even fewer.