I must correct myself. The keyboard switching in Live on Gnome Shell works as it should. Sorry for the mystification.

(In reply to Jiri Konecny from comment #0)
> Description:
> 
> Hello everyone. The Desktop team announced that they want to remove the
> libxklavier library support from Gnome Shell and remove the package from
> Fedora. The libxklavier library is used by Anaconda to handle keyboard
> layouts (reading, switching etc...). The reason for removing it, as far as I
> can tell, is that libxklavier was deprecated a long time ago, and it's
> another step towards moving to Wayland, where libxklavier will not work. 

Just to clarify, we are targeting the removal for RHEL 10 and not for RHEL 9.

Recently KDE Plasma got common layout switching DBus API for X11 and Wayland:
https://lxr.kde.org/source/kde/workspace/plasma-desktop/kcms/keyboard/keyboard_daemon.h

Maybe we could think about taking a step further and try to unify it with Gnome, etc., because I bet the goal of this API is pretty common.
For now it was designed just with keyboard layout indicator needs in mind.

I was hoping for something like that. It would be great to have one general to use solution for everyone.

Matthias, do you know if this would be a feasible solution also for Gnome?

I am not convinced that this is a general application task that warrants a 'common' api. Anaconda is really a very special case, and does it for historical reasons. Both kde and gnome offer layout switching UI that anaconda could just rely on when it runs in those environments...

So the link above doesn't work, but my expectation is that KDE and GNOME probably don't have completely compatible keyboard layout abstractions.

GNOME unifies ibus and xkb layouts into one combined list. I doubt KDE does?

At the moment GNOME Shell doesn't offer an API at all. It expects that it's the lone manager of keyboard layouts.

GNOME Kiosk offers an API, but if we really wanted to be standardized, we'd probably need to push the API down into mutter proper.

That would take a chunk of work to do, and I'm not sure we could do it in a way that matches what KDE needs anyway.

Furthermore, I think Matthias is right. There's a reason GNOME Shell doesn't provide an API... It's not something applications normally need to manage.  anaconda is special case when it's running in a standalone environment, but when it's running on a live install it probably just shouldn't have keyboard switching features of its own that duplicate desktop functionality.

If it's of any help, we do have another use-case for coming up with such a protocol, which is for sddm. In KDE's case (I don't know gnome's) the greeter and the compositor being in separate processes they need to coordinate it.

How does it work over there when you choose on gdm a keyboard layout?

gnome-shell provides the login screen for GDM.

(In reply to Ray Strode [halfline] from comment #6)
> Furthermore, I think Matthias is right. There's a reason GNOME Shell doesn't
> provide an API... It's not something applications normally need to manage. 
> anaconda is special case when it's running in a standalone environment, but
> when it's running on a live install it probably just shouldn't have keyboard
> switching features of its own that duplicate desktop functionality.

In https://pagure.io/fedora-workstation/issue/221 we have designs to move language and keyboard layout selection to gnome-initial-setup. The workflow would be:

gnome-initial-setup kiosk session (select language, select keyboard layout, ask user you want to install Fedora or try live?) -> optionally try live -> anaconda -> reboot to installed system -> gnome-initial-setup kiosk session to create user account etc.

In that workflow, the live anaconda would no longer need its own keyboard layout functionality at all. (Perhaps we could move timezone as well, then the only remaining anaconda spoke would be Installation Destination, which obviously has to be part of anaconda no matter what.)

That's the "triple session" design. There's also a "double session" design where anaconda itself prompts language -> keyboard layout -> do you want to install Fedora or try live? -> anaconda quits launches live session if user wants to try live. In that scenario, anaconda is still responsible for keyboard layout. Obviously that design would require more changes to anaconda.

The goal is to ensure users get a chance to set language and keyboard layout in a kiosk session *before* starting the real live session, since the live session is currently not very usable if you don't know English or don't have a qwerty keyboard.

(In reply to Michael Catanzaro from comment #10)
> That's the "triple session" design. There's also a "double session" design
> where anaconda itself prompts language -> keyboard layout -> do you want to
> install Fedora or try live? -> anaconda quits launches live session if user
> wants to try live. In that scenario, anaconda is still responsible for
> keyboard layout. Obviously that design would require more changes to
> anaconda.
> 
> The goal is to ensure users get a chance to set language and keyboard layout
> in a kiosk session *before* starting the real live session, since the live
> session is currently not very usable if you don't know English or don't have
> a qwerty keyboard.

We basically have to support the double session model, because that's the one that's compatible with all the desktop spins.

Ideally in the future, the triple session design can be used in both GNOME and KDE Plasma, but we're far away from that in GNOME and even further away from that right now in KDE Plasma.

(In reply to Michael Catanzaro from comment #10)
> That's the "triple session" design. There's also a "double session" design
> where anaconda itself prompts language -> keyboard layout -> do you want to
> install Fedora or try live? -> anaconda quits launches live session if user
> wants to try live. In that scenario, anaconda is still responsible for
> keyboard layout. Obviously that design would require more changes to
> anaconda.
> 
> The goal is to ensure users get a chance to set language and keyboard layout
> in a kiosk session *before* starting the real live session, since the live
> session is currently not very usable if you don't know English or don't have
> a qwerty keyboard.

I agree with what you are saying here but I don't think Anaconda should be the App who will prepare the Live environment. Let's try to not make Anaconda even heavier than it is now. I can imagine a small app specific for this purpose which could be extended by anyone who want to use it.

(In reply to Jiri Konecny from comment #12)
> I agree with what you are saying here but I don't think Anaconda should be
> the App who will prepare the Live environment. Let's try to not make
> Anaconda even heavier than it is now. I can imagine a small app specific for
> this purpose which could be extended by anyone who want to use it.

Yeah so that suggests the triple session design.

Neal has a good point though: the keyboard layout page is still needed for other desktop spins, which would not likely offer a D-Bus API for changing keyboard layout anyway.

I did some testing to know how much bigger it would be to have Live KDE DVD with gnome-kiosk. Test was done by taking the official KDE KS from spin-kickstarts, add gnome-kiosk package and increase '/' size otherwise I couldn't make the build working (dunno why). The results are:

without gnome-kiosk:

$ ls -l result/images/boot.iso
-rw-r--r--. 1 root root 2101542912 May 14 18:24 result/images/boot.iso

# to human readable form
$ bscalc 2101542912
2101542912 B
2052288.00 KiB
   2004.19 MiB
      1.96 GiB


with gnome-kiosk

ls -l result-gnome-kiosk/images/boot.iso
-rw-r--r--. 1 root root 2111864832 May 14 21:02 result-gnome-kiosk/images/boot.iso

# to human readable form
$ bscalc 2111864832
2111864832 B
2062368.00 KiB
   2014.03 MiB
      1.97 GiB


So the difference on Live KDE media is just about 10 MiB. I don't really think this is a big difference and because of that, I would suggest to just drop everything else from the InitialSetup and leave only gnome-kiosk support. It will be then hard-dependency of InitialSetup RPM package. This step should simplify everything a lot.

Do you know a reason why we shouldn't take steps described above?

For the Live media, I'm inclined to just drop the layout switching from there completely and leave that on the Live environment. In general, I don't think that Anaconda started as app should play with keyboard layout.

(In reply to Jiri Konecny from comment #14)
> I did some testing to know how much bigger it would be to have Live KDE DVD
> with gnome-kiosk. Test was done by taking the official KDE KS from
> spin-kickstarts, add gnome-kiosk package and increase '/' size otherwise I
> couldn't make the build working (dunno why). The results are:
> 
> without gnome-kiosk:
> 
> $ ls -l result/images/boot.iso
> -rw-r--r--. 1 root root 2101542912 May 14 18:24 result/images/boot.iso
> 
> # to human readable form
> $ bscalc 2101542912
> 2101542912 B
> 2052288.00 KiB
>    2004.19 MiB
>       1.96 GiB
> 
> 
> with gnome-kiosk
> 
> ls -l result-gnome-kiosk/images/boot.iso
> -rw-r--r--. 1 root root 2111864832 May 14 21:02
> result-gnome-kiosk/images/boot.iso
> 
> # to human readable form
> $ bscalc 2111864832
> 2111864832 B
> 2062368.00 KiB
>    2014.03 MiB
>       1.97 GiB
> 
> 
> So the difference on Live KDE media is just about 10 MiB. I don't really
> think this is a big difference and because of that, I would suggest to just
> drop everything else from the InitialSetup and leave only gnome-kiosk
> support. It will be then hard-dependency of InitialSetup RPM package. This
> step should simplify everything a lot.
> 
> Do you know a reason why we shouldn't take steps described above?
> 

Well, for one, KDE Plasma has its own kiosk mode we could use for this purpose. And we're not equipped to deal with bugs with gnome-kiosk in the KDE SIG.

> For the Live media, I'm inclined to just drop the layout switching from
> there completely and leave that on the Live environment. In general, I don't
> think that Anaconda started as app should play with keyboard layout.

There's some work going on to produce a kde-initial-system-setup tool to match the one GNOME has for KDE Plasma. However, you still don't get to not have this feature because every other spin lacks this capability. Especially plain WM spins would have no built-in functionality at all.

If you don't want Anaconda to handle it (which I don't think you can get away from), then the functionality Anaconda provides around this needs to be broken out into its own application.

Most spins, KDE included, rely on Anaconda to do these things for now.

Sorry for late response, i wanna give a short feedback about the situation with MATE-Compiz spin.
In general we're using gsettings to switch keyboard layout.
For example:
[rave@mother ~]$ gsettings get org.mate.peripherals-keyboard-xkb.kbd layouts
['de\tnodeadkeys']
And i want to say in general MATE in fedora like to follow GNOME.
But i have no idea i it is possible to use kiosk for Mate.
Personal i am not a real software developer and i am depending on Mate upstream for software changes.
Keep in mind that Mate is a small team and i am in doubt that Mate can switch to kiosk for f35, before other distros like debian/ubuntu are in the same situation.

So maybe it is possible that anaconda can write directly the gsettings key?

This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle.
Changing version to 35.

This message is a reminder that Fedora Linux 35 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '35'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 35 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13.

Fedora Linux 35 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.

This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle.
Changing version to 38.

It's been a couple of years, but a solution has somewhat emerged now: most compositors can now listen to org.freedesktop.locale1 to dynamically reconfigure keyboard layouts.

This is how gnome-initial-setup and sddm both do it, and I think it should work for Anaconda's case too.

Reference documentation: https://www.freedesktop.org/software/systemd/man/latest/org.freedesktop.locale1.html

Example implementations:

* gnome-initial-setup: https://gitlab.gnome.org/GNOME/gnome-initial-setup/-/blob/master/gnome-initial-setup/pages/keyboard/gis-keyboard-page.c
* KWin: https://invent.kde.org/plasma/kwin/-/merge_requests/2921
* Sway: https://github.com/alebastr/sway-systemd/blob/main/src/locale1-xkb-config
* Calamares: https://github.com/calamares/calamares/blob/881347b9c20a2529726fbf61edf986213011d5ba/src/modules/keyboard/Config.cpp#L250-L283

@ngompa13 I had a look to "org.freedesktop.locale1" and there is an important detail that doesn't make it suitable. From the docs:

> Note that SetVConsoleKeyboard() instantly applies the new key mapping to the console,
> while SetX11Keyboard() simply sets a default that may be used by later sessions.

So, while this interface can be used (and I think it is used) to store the keyboard layout for the installed system, it doesn't change the layout used in Anaconda, making it not suitable to, for example, enter passwords during installation.

I'm exploring gsettings (for example, `gsettings set org.gnome.desktop.input-sources sources "[('xkb', 'es'), ('xkb', 'us')]"`), but that refuses to work :S I might be missing a D-Bus call to SetInputSourcesFromSessionConfiguration (https://gitlab.gnome.org/GNOME/gnome-kiosk/-/blob/main/dbus-interfaces/org.gnome.Kiosk.xml?ref_type=heads#L42). I'll continue investigating tomorrow :)

(In reply to José Expósito from comment #22)
> @ngompa13 I had a look to "org.freedesktop.locale1" and there is
> an important detail that doesn't make it suitable. From the docs:
> 
> > Note that SetVConsoleKeyboard() instantly applies the new key mapping to the console,
> > while SetX11Keyboard() simply sets a default that may be used by later sessions.
> 
> So, while this interface can be used (and I think it is used) to store the
> keyboard layout for the installed system, it doesn't change the layout used
> in Anaconda, making it not suitable to, for example, enter passwords during
> installation.
> 

This is only true if the compositor isn't actively listening and updating based on the settings changes. KWin does when "--locale1" is passed in.

> I'm exploring gsettings (for example, `gsettings set
> org.gnome.desktop.input-sources sources "[('xkb', 'es'), ('xkb', 'us')]"`),
> but that refuses to work :S I might be missing a D-Bus call to
> SetInputSourcesFromSessionConfiguration
> (https://gitlab.gnome.org/GNOME/gnome-kiosk/-/blob/main/dbus-interfaces/org.
> gnome.Kiosk.xml?ref_type=heads#L42). I'll continue investigating tomorrow :)

gsettings are not respected by anything except GNOME, which makes it generally unsuitable for Anaconda.

(In reply to Neal Gompa from comment #23)
> (In reply to José Expósito from comment #22)
> > @ngompa13 I had a look to "org.freedesktop.locale1" and there is
> > an important detail that doesn't make it suitable. From the docs:
> > 
> > > Note that SetVConsoleKeyboard() instantly applies the new key mapping to the console,
> > > while SetX11Keyboard() simply sets a default that may be used by later sessions.
> > 
> > So, while this interface can be used (and I think it is used) to store the
> > keyboard layout for the installed system, it doesn't change the layout used
> > in Anaconda, making it not suitable to, for example, enter passwords during
> > installation.
> > 
> 
> This is only true if the compositor isn't actively listening and updating
> based on the settings changes. KWin does when "--locale1" is passed in.

That's interesting, I wasn't aware of KWin's command line option, thanks for the pointer Neal!

Unfortunately, it doesn't look like a similar option is available in Mutter/GNOME Kiosk, so it is not a 100% cross-DE solution :( 
Even if Mutter devs would be open to accept a PR adding a similar option, the same functionality would have to be added to all Fedora Spin's compositors...

For reference, libxklavier is used for 2 different functionalities: Display the list of available keyboard layouts and switch keyboard layouts.

I opened a PR replacing libxklavier with python3-xkbregistry to display the list of layouts:
https://github.com/rhinstaller/anaconda/pull/5441

It doesn't fully remove the dependency to libxklavier but it the first step.

(In reply to José Expósito from comment #24)
> (In reply to Neal Gompa from comment #23)
> > (In reply to José Expósito from comment #22)
> > > @ngompa13 I had a look to "org.freedesktop.locale1" and there is
> > > an important detail that doesn't make it suitable. From the docs:
> > > 
> > > > Note that SetVConsoleKeyboard() instantly applies the new key mapping to the console,
> > > > while SetX11Keyboard() simply sets a default that may be used by later sessions.
> > > 
> > > So, while this interface can be used (and I think it is used) to store the
> > > keyboard layout for the installed system, it doesn't change the layout used
> > > in Anaconda, making it not suitable to, for example, enter passwords during
> > > installation.
> > > 
> > 
> > This is only true if the compositor isn't actively listening and updating
> > based on the settings changes. KWin does when "--locale1" is passed in.
> 
> That's interesting, I wasn't aware of KWin's command line option, thanks for
> the pointer Neal!
> 
> Unfortunately, it doesn't look like a similar option is available in
> Mutter/GNOME Kiosk, so it is not a 100% cross-DE solution :( 
> Even if Mutter devs would be open to accept a PR adding a similar option,
> the same functionality would have to be added to all Fedora Spin's
> compositors...

There's a similar hook in place for Sway[1], I've also filed a request for Weston[2] and Magpie[3].

IIRC, this is already the default behavior in Mutter because this is how gnome-initial-setup changes the setting[4].

[1]: https://github.com/alebastr/sway-systemd/blob/main/src/locale1-xkb-config
[2]: https://gitlab.freedesktop.org/wayland/weston/-/issues/865
[3]: https://github.com/BuddiesOfBudgie/magpie/issues/19
[4]: https://gitlab.gnome.org/GNOME/gnome-initial-setup/-/blob/master/gnome-initial-setup/pages/keyboard/gis-keyboard-page.c

(In reply to Neal Gompa from comment #26)
> (In reply to José Expósito from comment #24)
> > Unfortunately, it doesn't look like a similar option is available in
> > Mutter/GNOME Kiosk, so it is not a 100% cross-DE solution :( 
> > Even if Mutter devs would be open to accept a PR adding a similar option,
> > the same functionality would have to be added to all Fedora Spin's
> > compositors...
> 
> There's a similar hook in place for Sway[1], I've also filed a request for
> Weston[2] and Magpie[3].

Nice! Once those requests get implemented this will be the path to follow.

> IIRC, this is already the default behavior in Mutter because this is how
> gnome-initial-setup changes the setting[4].

No, Mutter does not update the current layout using "org.freedesktop.locale1".
gnome-initial-setup has to use GSettings to change the keyboard layout:
https://gitlab.gnome.org/GNOME/gnome-initial-setup/-/blob/master/gnome-initial-setup/pages/keyboard/gis-keyboard-page.c#L196

^ update_input() calls set_input_settings() to set the GSettings

A similar feature request would be required for Mutter.

I filed a feature request for Mutter:
https://gitlab.gnome.org/GNOME/mutter/-/issues/3275

This bug appears to have been reported against 'rawhide' during the Fedora Linux 40 development cycle.
Changing version to 40.

I've submitted requests for labwc[1], Wayfire[2], and Mir[3].

[1]: https://github.com/labwc/labwc/issues/1588
[2]: https://github.com/WayfireWM/wayfire/issues/2177
[3]: https://github.com/canonical/mir/issues/3267

In an unrelated conversation (https://gitlab.gnome.org/GNOME/gnome-kiosk/-/merge_requests/38#note_2043009) @rstrode mentioned that "just using logind misses input methods", which is a very important consideration.

Systemd assumes the layout is a XKB layout. See `x11_context_verify_and_warn()` in `systemd/src/locale/localed-util.com`.

My understanding it that this would make it impossible to select an ibus input source, like we could do now with GNOME Kiosk's API.

As far as I know, Anaconda doesn't support ibus, but it could be an stopper. However, I'm not familiar myself with ibus input sources or whether they are available in Anaconda or not.
Thoughts on this topic? Do you think it could be a problem now or in the future?

Anaconda in its own code doesn't support input methods, no. You can't use one while installing from a traditional installer image.

This obviously isn't great. What we have told people to do up until now is install from a live image and configure your input method in the host desktop environment.

This is mitigated to some extent by the fact that almost anything you need to type in the installer you *probably* want to be in ASCII characters, and usually (AIUI) people who use input methods would tend to use a US keyboard layout to enter ASCII characters. Mostly what you type in the installer environment is usernames and passwords. These *can* technically be non-ASCII...mostly...but it doesn't entirely work and you can very easily wind up in a situation where you can't log in if you do that, so AIUI it isn't something people really *do*.

I've opened a pull request adding support for a "--locale1" flag, similar to KWin's, in GNOME Kiosk:
https://gitlab.gnome.org/GNOME/gnome-kiosk/-/merge_requests/39

Upstream PR dropping libxklavier. https://github.com/rhinstaller/anaconda/pull/5829

Fixed by: 

commit 4dcdcf61ee0294348a978bdefaea270eb2bfde4c
Author: Jiri Konecny <jkonecny>
Date:   Wed Aug 28 17:24:24 2024 +0200

    Switch keyboard management to Localed

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days