Bug 1955025 - Anaconda needs to change keyboard layout switching library
Summary: Anaconda needs to change keyboard layout switching library
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-04-29 09:47 UTC by Jiri Konecny
Modified: 2021-05-06 14:33 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)

Description Jiri Konecny 2021-04-29 09:47:18 UTC
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

Comment 1 Jiri Konecny 2021-04-29 10:08:59 UTC
I must correct myself. The keyboard switching in Live on Gnome Shell works as it should. Sorry for the mystification.

Comment 2 Tomas Popela 2021-04-29 10:15:59 UTC
(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.

Comment 3 Andrey 2021-04-29 15:17:03 UTC
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.

Comment 4 Jiri Konecny 2021-04-30 08:37:57 UTC
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?

Comment 5 Matthias Clasen 2021-05-05 15:37:12 UTC
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...

Comment 6 Ray Strode [halfline] 2021-05-05 15:52:05 UTC
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.

Comment 7 Aleix Pol 2021-05-05 16:41:14 UTC
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?

Comment 8 Ray Strode [halfline] 2021-05-05 17:07:29 UTC
gnome-shell provides the login screen for GDM.

Comment 9 Michael Catanzaro 2021-05-05 17:56:57 UTC
(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.)

Comment 10 Michael Catanzaro 2021-05-05 18:00:00 UTC
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.

Comment 11 Neal Gompa 2021-05-06 04:20:09 UTC
(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.

Comment 12 Jiri Konecny 2021-05-06 09:16:57 UTC
(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.

Comment 13 Michael Catanzaro 2021-05-06 14:33:46 UTC
(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.


Note You need to log in before you can comment on or make changes to this bug.