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.
i took a look a this and decided it's probably better to do this a different way...copy the dconf settings over directly. we'll get a more complete reproduction of the users settings that way, and also it avoids having to have a way to read the current layout. I posted it here: https://github.com/rhinstaller/anaconda/pull/5056 I still haven't tested it completely, but I think it should work okay.
That's probably a good idea, but it's not sufficient because anaconda needs to know the current keyboard layout, and the settings are currently not enough to know that. See comment #7 for an example where all the settings may be copied successfully but the user will still be unable to unlock the installed system.
We just need to (a) modify gnome-control-center and gnome-initial-setup to also update the mru-sources setting (probably easiest), or (b) add some way (probably D-Bus) to ask gnome-shell for the current keyboard layout. I would favor (a).
ah right, yea (a) is probably the easiest way forward. I did have a pretty comprehensive keyboard layout api to gnome-kiosk for anaconda https://gitlab.gnome.org/GNOME/gnome-kiosk/-/blob/main/dbus-interfaces/org.gnome.Kiosk.xml. I should probably have put it in mutter, instead then we could have just used it...but that's water under the bridge. a seems like the best near term solution.
OK, I think we actually do not need any changes in gnome-initial-setup because gnome-initial-setup only allows selecting one input source and does not allow configuring multiple input sources or reordering them like gnome-control-center does. Whatever the user selects will be the only input source configured, so anaconda can read "mru-sources", see that it's empty, then fall back to reading "sources", and there is no problem. So the only problem here is if users can open gnome-control-center and change their input source configuration prior to launching anaconda. I'm not sure whether that is actually possible with the current installation workflow or not. My merge request https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/1893 will fix this if so. Ray, can you confirm whether we need to land this, please?
"I'm not sure whether that is actually possible with the current installation workflow or not" it is possible, yes. You can pick "Try" at the end of the pre-live g-i-s flow, then from the live desktop, there is still a launcher to run the installer.
"gnome-initial-setup only allows selecting one input source and does not allow configuring multiple input sources or reordering them like gnome-control-center does. Whatever the user selects will be the only input source configured" You still have to consider cases where it is normal to have multiple sources configured for a single language. e.g. when using Russian, you expect to have both a Russian and a US English keyboard layout available. When using Japanese, you expect to have an input source for Japanese available and a US English layout for typing Latin characters. Unfortunately, this has led me to discover that Nu-GIS gets this wrong. :( If I select Russian in g-i-s, it *only* configures the Russian layout. It does not also give me a US layout as it should. This means I literally cannot type Latin characters unless I go through "Try" at the end of install, then go to control center and add the US layout myself. This among other things means I cannot possibly type mount point names in Latin characters (as a Russian usually would), or set a passphrase in Latin characters (again this is typical, and in fact I thought anaconda is supposed to warn you if you type an anaconda passphrase without them, but it doesn't seem to. It lets you try, then blivet blows up when actually trying to create the encrypted device: File "/usr/lib/python3.12/site-packages/blivet/formats/luks.py", line 339, in _create context = blockdev.CryptoKeyslotContext(passphrase=self.__passphrase) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib64/python3.12/site-packages/gi/overrides/BlockDev.py", line 270, in __new__ ret = BlockDev.CryptoKeyslotContext.new_passphrase([ord(c) for c in passphrase]) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ OverflowError: 1088 not in range 0 to 255 I, uh, guess I have a few different bugs to file here!
(In reply to Adam Williamson from comment #15) > I, uh, guess I have a few different bugs to file here! Yeah. :( Please talk to Jens Petersen and the internationalization team to make sure they are happy with any proposed enhancement.
I agree with Adam here. I think that GIS should setup at least one xkb layout always. If only ibus is selected there should be one default xkb (English probably) so users are able to type passwords and create requested mount points. And Anaconda will take the current mru if available if not than the first xkb on the input-sources list (needs to be implemented yet).
Or better solution. Use langtable for finding the correct layout and pass the selection to langtable to get the input sources you should set to system.
We're talking about the intricacies of this over on the g-i-s and gnome-desktop pull requests, https://gitlab.gnome.org/GNOME/gnome-initial-setup/-/merge_requests/213 and https://gitlab.gnome.org/GNOME/gnome-desktop/-/merge_requests/159 . I love my annual trip down the keyboard layout rabbit hole...
btw, one interesting thing I discovered is that at least the default Japanese input method (anthy) has a kinda 'native' Latin input ability (on GNOME at least), so in theory you don't need a US layout configured to be able to type Latin characters. I don't know if this is actually sufficient or whether a native user would still expect a US layout configured as well, though. We'll need to ask an expert.
Also, taking "the first xkb on the input-sources list" may...not be correct. Remember how we do this on the old path in anaconda: https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/keyboard.py#L217 we actually put US *first* in the list when we're configuring a pair of xkb layouts, not the native layout - this was requested in https://bugzilla.redhat.com/show_bug.cgi?id=1039185 . Arguably, g-i-s should do the same (though I think as of right now it does not) - which means that anaconda will need to take the *second* item in the list in this case, not the first...
It's great that Japanese can type latin characters with ibus, however, it's not helpful to open these devices because vconsole keymap can't use ibus so we need to have US or other specified here too.
well, the good thing there is that ultimately everything falls back to US...including the console layout...
So the change to gnome-control-center has landed upstream. I don't think we need to track this further downstream because the problem here only occurs if the user opens gnome-control-center manually and starts reordering input sources (without adding or removing any input source) before starting anaconda, which is not very likely.
(In reply to Michael Catanzaro from comment #5) > 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?) We decided to always set mru-sources in gnome-initial-setup. So you can actually look at just that setting and none other. If mru-sources is unset, then it's English (US).
(In reply to Michael Catanzaro from comment #25) > We decided to always set mru-sources in gnome-initial-setup. So you can > actually look at just that setting and none other. If mru-sources is unset, > then it's English (US). (However, this change is not present in Fedora 39 yet.)
(In reply to Michael Catanzaro from comment #25) > (In reply to Michael Catanzaro from comment #5) > > So in org.gnome.desktop.input-sources, the 'current' setting is deprecated > > and ignored. So don't look at that at all. > > We decided to always set mru-sources in gnome-initial-setup. So you can > actually look at just that setting and none other. If mru-sources is unset, > then it's English (US). I think setting mru-sources should be right and also the current is set in gnome-shell.
(In reply to Adam Williamson from comment #20) > btw, one interesting thing I discovered is that at least the default > Japanese input method (anthy) has a kinda 'native' Latin input ability (on > GNOME at least), so in theory you don't need a US layout configured to be > able to type Latin characters. I don't know if this is actually sufficient > or whether a native user would still expect a US layout configured as well, > though. We'll need to ask an expert. I expect Anaconda could have two UIs of a session XKB layout and also a user (XKB or input method) layout. If a session layout is "JP" and user layout is "anthy", anthy works with "JP" layout. You could see /usr/share/ibus/component/simple.xml includes XKB layouts and each "layout" tag declares the XKB layout and /usr/share/ibus/component/anthy.xml runs `/usr/libexec/ibus-engine-anthy --xml` to get the user layout. the "default" layout means to inherit the session layout since anthy works with either ASCII layouts likes "JP". "US", "US(dvorak)".