#504 Please support org.freedesktop.locale1 keyboard configuration for Anaconda on Live environment
Closed: Fixed 3 months ago by ngompa. Opened 5 months ago by jkonecny.

Hello, I’m contacting you on behalf of the Anaconda team to raise awareness that Anaconda has to change the backend which is used to control keyboard configuration of the Live environment. That means that we will depend on the org.freedesktop.locale1 D-Bus API and we are contacting you with a request to support this API. Currently Anaconda depends on libXklavier library, however, we are forced to migrated from this solution to Wayland compatible solution for various reasons:

Also, the Anaconda team got a lot smaller, so we are not in position to maintain both solutions based on the system. That would get us into more bugs in the future which we don’t have capacity to resolve. For that reason we are requesting all the SIGs owning spins on Fedora to implement support which will reflect this DBus API to the Live environment. More precisely, this API will be used by Anaconda to read and change the currently set keyboard layout configuration on Live media. Your Live environment should reflect on these changes and apply them to the running Live environment. I’ll create a system wide change soon to connect all the parties in one place but we wanted to reach all of you beforehand.

What you need to do:

  • Verify if you are already reflecting the systemd-localed keyboard configuration on your spin Live installation environment.
  • If the above is not correct, please implement this missing communication.

For more information please see this https://www.freedesktop.org/software/systemd/man/latest/org.freedesktop.locale1.html

We would like to get these changes together with Wayland to switch to Fedora 41 if possible. In case you won’t be able to add support for the DBus service, we will solve this situation with the same approach as described in bug above which means that Anaconda won’t be controlling your system keyboard configuration in the Live environment and users will be requested to set this in the Anaconda for the installed system only.

We are sorry for the inconvenience and we will try to help you with this migration process.


I think we are already set on this? I'm checking with @zzag and other kwin folks to be sure, though.

cc: @apol @ngraham

Metadata Update from @ngompa:
- Issue tagged with: experience, installation

5 months ago

Metadata Update from @ngompa:
- Issue set to the milestone: Fedora Linux 41

5 months ago

As far as I can tell, we already support this in KWin and Plasma.

Yeah, the trick is getting kwin to launch that way for the Plasma live session, as it currently does not.

Actually, when configuring the keyboard anaconda says:

⚠️ Changes here will only apply to the installed system. Use the desktop's tool to configure the keyboard for the installation process."

And that makes sense, because otherwise if we switch kwin to follow locale1 in livecd kcm_keyboard would become nonfunctional.

So we don't need to change kwin, and we already have systemd-localed dbus-activated so this should be already OK.

Yes, this message is outcome of the problematic configuration we have right now on Wayland. Most probably this message will go away after we will switch to locale1 solution.

Mh, so the live environment is meant to follow the configuration applied in anaconda?

Currently Anaconda won't touch the Live system configuration of the keyboard on Wayland systems. It is result of https://bugzilla.redhat.com/show_bug.cgi?id=2072941.

What we want to do is to use locale1 DBus API for configuration of the live systems and use this solution on all the variants. So this issue asks spins to listen configuration of locale1 and reflect that to the Live system so we are in charge of the keyboard configuration. If you don't do that, you will be in the same situation as you are right now => Anaconda does only the installed system keyboard configuration.

Just to clarify, the current situation is problematic, because if you change keyboard by Anaconda (to the installed system) and create user/luks password in Live installer you will have different keyboard configuration used for creating password and unlocking after the installation. That can easily result in unbootable system because you are not able to open the LUKS device. Example of such an issue: https://bugzilla.redhat.com/show_bug.cgi?id=2277585

We can easily make the live environment follow anaconda; the probably harder part is making the desktop's keyboard layout settings page to also work at the same time.

Should we try to drive some upstream work to get things in place for Plasma 6.1? It looks like that will be the version we ship in F41.

It sounds like most of these were merged. Does this still need to be tested to confirm this is fixed?

Metadata Update from @ngompa:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

3 months ago

Log in to comment on this ticket.

Metadata