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. **This does not mean that the deprecation will take place in the next Fedora.** We have to find a way to properly solve this issue before the deprecation, however. Just to make things clear, Anaconda is switching from Metacity to Gnome kiosk in a few weeks on Rawhide[0]. Gnome Kiosk provides us the DBus API for keyboard layout handling which we may use in the future (not used by the current implementation). Anaconda in boot.iso should be able to switch to the new DBus API without problems. However, InitialSetup and Live media are more complicated. InitialSetup: This uses code for keyboard layout switching from Anaconda, and it has (will have) support for “gnome-kiosk”, "metacity", "kwin_x11", "kwin", "xfwm4", "openbox", "marco" to be able to run properly for all Fedora spins. The biggest issue with InitialSetup is that this tool is one of the main tools used on ARM devices. That means spins like KDE which also have ARM support are affected by this change. Live media: We don't have a simple solution for this yet. The keyboard layout switching on Gnome Shell Live is broken even now. My suggestion is to remove the keyboard layout switching support from Anaconda on Live and the keyboard layout work on the Live environment. Because of the above, I would like to use this bug to find the best solution which would work for Desktop team, Gnome and spins. Anaconda doesn't have resources or know-how to take care of the libxklavier library. So I think we have a few possible options here. - Community will take over libxklavier from the Desktop team. - This would mean that Anaconda has to support both Gnome kiosk and libxklavier for interacting with the keyboard layouts. - Another pain point is how we will work on Wayland for other spins like KDE, because they don’t implement the DBus API or gsettings provided by Gnome. - Wayland will have a library for keyboard layout handling which is not specific to a DE or WM. - There will be a library which would abstract all the different keyboard layout handling for Gnome Shell, KDE on X/Wayland, Xfce, i3 etc.... - Drop keyboard support from InitialSetup. - Run the InitialSetup in gnome-kiosk all the time. - This would simplify the situation a lot but it would also drag unwanted dependencies into the installed system when InitialSetup will be used. If there is already an existing solution or if there are other options that are worth exploring, please feel free to make note of it here, so that we can investigate/discuss it. [0]: https://github.com/rhinstaller/anaconda/pull/3307
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.