To reproduce, boot a KDE live image with anaconda-webui-54-1.fc44, run the installer, and try installing in French, or Russian, or really anything non-English. It should default to a sensible xkb layout configuration - for Russian it defaults to us,ru , for French it defaults to fr(oss). That's great. However, when you proceed to the encryption screen, it will show that the layout to be used at boot is "English (USA)" (translated). That's not great. And it's not a lie: it seems that no matter what xkb config you choose during install, anaconda-webui configures the console layout as 'us'. Obviously it shouldn't do that. For a Russian install it should set 'ru', for a French install it should set 'fr-oss' (I think), etc etc.
Our current behavior in WebUI for KDE is alligned with the behavior of GTK I believe. THe logic for the default xlayouts comes from the backend, common to both GTK and WebUI [1]. When a language is chosen whose default layout does not support ASCII (see Russian) we prepend the us (default) layout in the XLayouts list [2]. WebUI takes the first item in XLayouts and sets it for VConsole. So the behavior you see is actually the intended for us. [1] https://github.com/rhinstaller/anaconda/pull/6704 [2] https://github.com/rhinstaller/anaconda/blob/72d232b94032b6724fd8ad4443f3946370c05391/pyanaconda/modules/localization/localization.py#L455
Maybe there is a mis-understanding here. In the Disk encryption screen we show the VConsoleLayout that will be used for LUKS unlocking. The keyboards you choose or are preselected in the Welcome screen are the ones that will be configured for the target system.
> Our current behavior in WebUI for KDE is alligned with the behavior of GTK I believe No, it isn't. > When a language is chosen whose default layout does not support ASCII (see Russian) we prepend the us (default) layout in the XLayouts list [2] Yes, this is correct. > WebUI takes the first item in XLayouts and sets it for VConsole This is wrong. What you are supposed to do is ask localed "what is the correct console layout for this xkb configuration?", and it will go through that little nightmare of code I pointed you at last week - https://github.com/systemd/systemd/blob/main/src/shared/vconsole-util.c#L519 - and tell you what the correct console layout is. If you ask localed for the correct console layout for the xkb config "us,ru" it will tell you "ru", which is correct. This is all about the thing where layout switching doesn't work the same in kbd and xkb. In kbd it's all done within a single layout map, because kbd has no concept of fast switching between multiple loaded layouts. So there's no kbd implementation of "load us and ru and allow switching between them". Instead, for kbd, most of the keys on the keyboard have *four* mappings, like this: keycode 20 = +t shift keycode 20 = +T altgr keycode 20 = U+0435 # CYRILLIC SMALL LETTER IE altgr shift keycode 20 = U+0415 # CYRILLIC CAPITAL LETTER IE that means "if you hit the key alone, you get a 't'. If you hit shift+the key, you get a 'T'. If you hit altgr+the key, you get a 'е'. If you hit altgr+shift+the key, you get a 'Є'. You're probably familiar with the caps lock key, which effectively locks shift on. Switched mappings implement an "AltGr lock": keycode 29 = Control shift keycode 29 = AltGr_Lock altgr shift keycode 29 = AltGr_Lock that is, if you press ctrl+shift (with or without altgr), it toggles the AltGr lock on and off. So ctrl+shift effectively 'switches' between Latin and Cyrillic input, and whichever one you're in, you can input a character from the other by holding AltGr. Notice also that it's the *Latin* characters that are mapped without AltGr, which means they're the default: when you first boot the system, you're entering Latin characters if you type without AltGr. So the console 'ru' layout is the equivalent of the xkb 'us,ru' configuration. So: you can't ever take shortcuts like 'the first layout must be the right console one' or anything like that. We have to have some kind of sophisticated conversion setup, and localed is where we keep it. The relevant GTK UI code here starts in pyanaconda/modules/localization/utils.py - https://github.com/rhinstaller/anaconda/blob/main/pyanaconda/modules/localization/utils.py#L25 It covers all possible combinations of 'have xkb config' and 'have kbd config', because it's actually possible to hit all of them (or it has been at some point, anyway), but the typical case is 'have xkb config, don't have kbd config', which is handled by calling `_resolve_missing_by_conversion` in the same file, which does: vc_keymap = localed_wrapper.convert_layouts(x_layouts) log.debug("Missing virtual console keymap value %s converted from %s X layouts", vc_keymap, x_layouts) you can trace that out yourself to see exactly how it works, but just from the names you can see that it's doing what I said: giving localed the xkb config and asking it for the matching kbd config.
Sorry, I missed a logical link in the above. "Instead, for kbd, most of the keys on the keyboard have *four* mappings, like this" should read "Instead, for kbd, 'switched' layouts are implemented entirely within the 'native' keymap. For example, in the 'ru' kbd layout, most of the keys on the keyboard have *four* mappings, like this".
Update here: it seems like we fortunately already expose the necessary bits for webui to use (as GetKeyboardConfigurationWithTask and GetMissingKeyboardConfigurationTask), and the GNOME path already uses them. Probably all we need to do here is use them on the non-GNOME path as well. Katerina is looking at that now.
Upstream fix attempted at: https://github.com/rhinstaller/anaconda-webui/pull/1054
FEDORA-2025-d70e047fbf (anaconda-webui-58-1.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2025-d70e047fbf
FEDORA-2025-d70e047fbf (anaconda-44.6-1.fc44 and anaconda-webui-59-1.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.