Please support org.freedesktop.locale1 keyboard configuration for Anaconda on Live environment

jkonecny commented

2024-05-02 15:12:10 +00:00

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:

The libXklavier library is deprecated (https://bugzilla.redhat.com/show_bug.cgi?id=1955025 )
Anaconda have to migrate to Wayland native solution which makes libXklavier to crash
The libXklavier doesn’t work great in some situations on Wayland environment
- Anaconda was forced to not be able to configure keyboards which makes user experience worse https://bugzilla.redhat.com/show_bug.cgi?id=2072941

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.

A note, this change is already in progress:
https://gitlab.gnome.org/GNOME/gnome-kiosk/-/merge_requests/39

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: * The libXklavier library is deprecated (https://bugzilla.redhat.com/show_bug.cgi?id=1955025 ) * Anaconda have to migrate to Wayland native solution which makes libXklavier to crash * The libXklavier doesn’t work great in some situations on Wayland environment * Anaconda was forced to not be able to configure keyboards which makes user experience worse https://bugzilla.redhat.com/show_bug.cgi?id=2072941 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. A note, this change is already in progress: https://gitlab.gnome.org/GNOME/gnome-kiosk/-/merge_requests/39

ngompa commented

2024-05-02 15:34:33 +00:00

Owner

Metadata Update from @ngompa:

Issue set to the milestone: Fedora 41
Issue tagged with: experience, installation

**Metadata Update from @ngompa**: - Issue set to the milestone: Fedora 41 - Issue tagged with: experience, installation

ngompa commented

2024-05-02 15:37:15 +00:00

Owner

It looks like this was done for GNOME Kiosk in GNOME 46, and the remaining thing to do is to add it to GNOME Shell for GNOME 47.

jkonecny commented

2024-05-02 15:39:28 +00:00

Author

Yes, to my understanding there is missing Javascript code to make this working on Gnome Shell. We were already talking about this during the Wayland migration.

jexposit commented

2024-05-30 15:49:47 +00:00

Yes, GNOME Kiosk is ready. As explained in the merge request, when no session configuration is available, i.e, gsettings set org.gnome.desktop.input-sources sources "[]", system configuration (org.freedesktop.locale1) is used.

GNOME Shell could follow the same or it could follow a KDE like approach, allowing to opt-in using an environment variable or a command line argument.

org.freedesktop.locale1 is already used in GDM:
https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/main/js/ui/status/keyboard.js#L364

        if (Main.sessionMode.isGreeter)
            this._settings = new InputSourceSystemSettings();
        else
            this._settings = new InputSourceSessionSettings();

One easy way to implement it would be changing the first if to if (Main.sessionMode.isGreeter || <opt_in_condition>), but of course, the final implementation needs to be discussed with the community upstream.

Yes, GNOME Kiosk is ready. As explained in the [merge request](https://gitlab.gnome.org/GNOME/gnome-kiosk/-/merge_requests/39), when no session configuration is available, i.e, `gsettings set org.gnome.desktop.input-sources sources "[]"`, system configuration (`org.freedesktop.locale1`) is used. GNOME Shell could follow the same or it could follow a KDE like approach, allowing to opt-in using an environment variable or a command line argument. `org.freedesktop.locale1` is already used in GDM: https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/main/js/ui/status/keyboard.js#L364 ``` if (Main.sessionMode.isGreeter) this._settings = new InputSourceSystemSettings(); else this._settings = new InputSourceSessionSettings(); ``` One easy way to implement it would be changing the first if to `if (Main.sessionMode.isGreeter || <opt_in_condition>)`, but of course, the final implementation needs to be discussed with the community upstream.

jkonecny commented

2024-06-04 12:51:04 +00:00

Author

Hi, just for the record, I asked @catanzaro to bring this to Gnome upstream.

catanzaro commented

2024-06-04 14:34:01 +00:00

Owner

Upstream issue report

[Upstream issue report](https://gitlab.gnome.org/GNOME/mutter/-/issues/3275)

catanzaro commented

2024-07-25 17:23:54 +00:00

Owner

Metadata Update from @catanzaro:

Issue tagged with: meeting-request

**Metadata Update from @catanzaro**: - Issue tagged with: meeting-request

ngompa commented

2024-07-30 00:08:54 +00:00

Owner

Metadata Update from @ngompa:

Issue untagged with: meeting-request
Issue tagged with: meeting

**Metadata Update from @ngompa**: - Issue **un**tagged with: meeting-request - Issue tagged with: meeting

catanzaro commented

2024-07-30 14:16:52 +00:00

Owner

Workstation WG discussed this today and we agree that the Anaconda developers' plan seems good to us, though some details need to be worked out.

We'd like to see this implemented upstream.

Workstation WG discussed this today and we agree that the Anaconda developers' plan seems good to us, though some details need to be worked out. We'd like to see this implemented upstream.

catanzaro commented

2024-07-30 14:17:15 +00:00

Owner

Metadata Update from @catanzaro:

Issue untagged with: meeting

**Metadata Update from @catanzaro**: - Issue **un**tagged with: meeting

ngompa commented

2024-11-05 14:48:38 +00:00

Owner

Metadata Update from @ngompa:

Issue set to the milestone: Fedora 42 (was: Fedora 41)

**Metadata Update from @ngompa**: - Issue set to the milestone: Fedora 42 (was: Fedora 41)

ngompa commented

2024-11-05 14:48:46 +00:00

Owner

Metadata Update from @ngompa:

Issue tagged with: meeting

**Metadata Update from @ngompa**: - Issue tagged with: meeting

ngompa commented

2024-11-12 14:43:10 +00:00

Owner

Metadata Update from @ngompa:

Issue untagged with: meeting

**Metadata Update from @ngompa**: - Issue **un**tagged with: meeting

petersen commented

2025-02-05 08:26:34 +00:00

Owner

We should probably discuss/sync up on this for F42 now?

jkonecny commented

2025-02-20 15:49:08 +00:00

Author

Hi, I filed this to bugzilla so it is tracked there:
https://bugzilla.redhat.com/show_bug.cgi?id=2346830

Hi, I filed this to bugzilla so it is tracked there: https://bugzilla.redhat.com/show_bug.cgi?id=2346830

jkonecny commented

2025-03-28 14:08:43 +00:00

Author

Hi, after this was implemented in some environments, we have started to face issues about getting information from the compositor to Localed. Often, we hit a problem that it is not easy to decide the current layout for the Anaconda window, also we found that required APIs are pretty often not present or broken. Based on these issues, we have decided to disable keyboard shortcuts for switching keyboard layouts in Anaconda which is the only requirement using information from the compositor.

Outcome:
Compositor does not need to reflect its configuration to Localed anymore. Compositor is still required to listen on Localed and reflect localed configuration to the compositor.

Hi, after this was implemented in some environments, we have started to face issues about getting information from the compositor to Localed. Often, we hit a problem that it is not easy to decide the current layout for the Anaconda window, also we found that required APIs are pretty often not present or broken. Based on these issues, we have decided to disable keyboard shortcuts for switching keyboard layouts in Anaconda which is the only requirement using information from the compositor. Outcome: Compositor does not need to reflect its configuration to Localed anymore. Compositor is still required to listen on Localed and reflect localed configuration to the compositor. You can read more details here: https://discussion.fedoraproject.org/t/f41-change-proposal-anaconda-as-native-wayland-application-system-wide/118550/30

catanzaro commented

2025-10-09 16:19:35 +00:00

Owner

Hey, we might have a problem here. Our plan was to change gnome-initial-setup to run twice: once in live user mode, then it launches anaconda, then the users reboots into installed system, then gnome-initial-setup runs again. The point of running it in live user mode is to prompt user for language and keyboard layout selection before running the live desktop, and also to replace the current Fedora-specific tool that asks the user whether to launch live desktop or run anaconda directly. Then we want to avoid redundancy, so we would not ask for keyboard layout configuration again when running gnome-initial-setup the second time; anaconda would be responsible for writing the language and keyboard layout to the installed system. I had been thinking: "this is fine, after we fix https://pagure.io/fedora-workstation/issue/430 as requested by anaconda team, then anaconda will read the language and keyboard layout we have provided to localed and everything should work."

Problem is we forgot about input methods. localed doesn't store input method configuration; the only place we have for that is GNOME-specific GSettings. So I'm afraid the plan to use localed is going to fail; there's just no way to make this work unless anaconda reads the GNOME settings. Sorry for not noticing this sooner. :(

Maybe we could enhance localed to understand input methods. That might be nicer than trying to add yet another competing place to configure input settings.

Hey, we might have a problem here. Our plan was to change gnome-initial-setup to run twice: once in live user mode, then it launches anaconda, then the users reboots into installed system, then gnome-initial-setup runs again. The point of running it in live user mode is to prompt user for language and keyboard layout selection _before_ running the live desktop, and also to replace the current Fedora-specific tool that asks the user whether to launch live desktop or run anaconda directly. Then we want to avoid redundancy, so we would not ask for keyboard layout configuration again when running gnome-initial-setup the second time; anaconda would be responsible for writing the language and keyboard layout to the installed system. I had been thinking: "this is fine, after we fix https://pagure.io/fedora-workstation/issue/430 as requested by anaconda team, then anaconda will read the language and keyboard layout we have provided to localed and everything should work." Problem is we forgot about input methods. localed doesn't store input method configuration; the only place we have for that is GNOME-specific GSettings. So I'm afraid the plan to use localed is going to fail; there's just no way to make this work unless anaconda reads the GNOME settings. Sorry for not noticing this sooner. :( Maybe we could enhance localed to understand input methods. That might be nicer than trying to add yet another competing place to configure input settings.

catanzaro commented

2026-03-23 21:22:10 +00:00

Owner

I've mentioned this problem in the upstream issue report.

I've mentioned this problem in the [upstream issue report](https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7761).

catanzaro self-assigned this

2026-05-05 14:36:09 +00:00

Rows
Columns

Please support org.freedesktop.locale1 keyboard configuration for Anaconda on Live environment #430