In Anaconda Web UI we would like to start sourcing Live system keyboard configuration. The work is almost done and it's working great except one bug I found during my testing. The ``` gsettings get org.gnome.desktop.input-sources mru-sources ``` returns value `@a(ss) []` when multiple layouts are set but yet not switched. That means if you start Live session and configure multiple layouts in keyboard configuration you will get the output above from mru-sources. I think this is a bug because most recently used is the currently set layout even if it wasn't switched yet. This breaks Virtual Console Keymap solution as implemented now by https://github.com/rhinstaller/anaconda/pull/4976. If the current solution is merged without this fix, we would end up in broken keyboard layout used to open LUKS devices during boot. Reproducible: Always Steps to Reproduce: 1. Boot Fedora Workstation Live media 2. Configure multiple keyboard layouts in Settings (optional step?) 3. Run `gsettings get org.gnome.desktop.input-sources mru-sources` Actual Results: Returns: `@a(ss) []` Expected Results: Returns the same value as `gsettings get org.gnome.desktop.input-sources sources` execution with currently selected layout as first value. I think configuring multiple layouts is an optional step because the returned value shouldn't be empty even if you have just one layout set.
I think this is expected. The setting is set to its default value, an empty array. @a(ss) is the type of the value (array of tuples, each tuple containing two strings) and [] indicates the value is an empty array. When the setting is empty, anaconda can simply skip copying the input sources configuration, and then the installed system with no configuration would wind up with English (US). -------------- BTW, there are two relevant settings in org.gnome.desktop.input-sources: * sources: this is the authoritative source for which input sources are configured. It may be empty. * mru-sources: this one is for tracking which sources are most recently used. It may be empty. I think you should probably use 'sources' instead of 'mru-sources', so that the the list on the installed system is in the same order as the list on the live system?
Hi based on my testing that is not possible. I need information about currently used source to properly set virtual console keymap, which is used for LUKS unlocking during boot. So, defaulting to English might result in not being able to unlock your system on the first boot after the installation. I can't use `sources` for that because it doesn't give me information about the currently used. Example of wrong input: 1. After boot go to settings (default is EN) 2. Add at least one more layout (let's use CZ in this example) 3. Change the newly added layout to the top of the list (so the new order is [("xkb", "cz"), ("xkb", "en")] ) The ordering change would result in this output: 'sources' output: "cz", "en" 'mru' output : "@a(ss) []" current layout : "en" In other words, the list of sources is reordered based on the user preference but the current layout is still "en", however, the first in the list is "cz". In this situation Anaconda don't know, what is layout used during the installation to set passwords. We can quess that it's always English, however, if you remove English layout from the list and keep others, we are still getting empty value for 'mru'. In this case, it's completely wrong configuration because the layout is not even available to user during installation.
I'm going to investigate this more closely before replying again. :)
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle. Changing version to 39.
(In reply to Jiri Konecny from comment #2) > Hi based on my testing that is not possible. > > I need information about currently used source to properly set virtual > console keymap, which is used for LUKS unlocking during boot. So, defaulting > to English might result in not being able to unlock your system on the first > boot after the installation. I can't use `sources` for that because it > doesn't give me information about the currently used. > > Example of wrong input: > 1. After boot go to settings (default is EN) > 2. Add at least one more layout (let's use CZ in this example) > 3. Change the newly added layout to the top of the list (so the new order is > [("xkb", "cz"), ("xkb", "en")] ) > > > The ordering change would result in this output: > 'sources' output: "cz", "en" > 'mru' output : "@a(ss) []" > current layout : "en" > > > In other words, the list of sources is reordered based on the user > preference but the current layout is still "en", however, the first in the > list is "cz". In this situation Anaconda don't know, what is layout used > during the installation to set passwords. So in org.gnome.desktop.input-sources, the 'current' setting is deprecated and ignored. So don't look at that at all. Use the 'mru-sources' setting to determine the current input source (and decide how to configure the vconsole keymap). The first source listed there is the one that is currently selected. If this setting is empty, then the user has never switched from the first input source to any other input source, so in that case the current source would be the first source from 'sources' instead. And if 'sources' is also empty, then it's English (US). Use 'sources' to decide what locale to install into localed. Since localed only supports configuring a single locale, I suppose you can just take the first one from the list, and the user will have to manually add back any other configured input sources after installation. (Ray, do you agree?)
> Use 'sources' to decide what locale to install into localed. Since localed only supports configuring a single locale, I suppose you can just take the first one from the list, and the user will have to manually add back any other configured input sources after installation. (Ray, do you agree?) I meant: "use 'sources' to decide what X11 Layout and X11 Variant to install into localed" (The VC Keymap would have to come from mru-sources because otherwise the user would be unable to enter the LUKS passphrase prompt.)
As described at comment 2, your suggestion will not work. The issue is that in Gnome Settings you can change ordering of the keyboard layouts. Which breaks your suggested logic. Example: layouts: [cz, us, es] current: cz however if I change the order: layouts: [us, es, cz] current: cz Without switching the layout which will set mru-sources we don't have a clue what is the current layout after re-ordering because we don't know what was the order before reordering.
OK, I see the problem. For now, please assume the logic I suggested works (even though it doesn't). We'll need to update mru-sources when the input sources are reordered, not only when they are changed.