Description of problem:
Anaconda on KDE does not switch keyboard layout correctly on the User creation pane. When a secondary keyboard layout is selected and then clicked into the Full name field, any press of the modifier (Ctrl, Shift, Alt) switches the layout back to the primary layout (us) which does not leave any option to type in a capitalized character -> it is not possible to type a full name using non-English characters, such as "Šárka Švrčinová" or "Jörg Kräppfütter".
There is a workaround to switch the layout to the secondary layout after the capitalized letters have been typed in and then continue typing, but it is not convenient.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot the KDE RC ISO
2. Start Anaconda.
3. Select the English language and proceed.
4. On the Keyboard pane, add a secondary layout (leave it on the second line).
5. On the User creation pane, select the secondary layout and click into the Full name entry field.
6. Try to type any name that requires to use shift, such as "John" or "Ursula".
The layout changes back to the primary (us) layout immediately.
7. Select the secondary layout again.
8. Click into the Full name field and try to type any modifier (Shift, Alt, Ctrl).
The layout changes back to the primary (us) layout immediately.
No possibility to enter a capitalized character into the Full name entry field using the secondary layout.
Secondary layout stays selected no matter which keys are pressed.
On Server DVD ISO or Everything ISO, the problem DOES NOT exist, so it must be some KDE interaction.
In journalctl, errors like this (see below) appear when users interact with Anaconda:
plasmashell: invalid image 0
plasmashell: kf.plasma.quick: Couldn't create KWindowShadow for ToolTipDialog(0x5587aa60a70)
Proposed as a Blocker for 35-final by Fedora user lruzicka using the blocker tracking app because:
I am proposing this because it hinder the basic usage criterion.
is this an anaconda bug or a KDE bug? I don't think anaconda handles layout switching itself in the live environment, it's up to the desktop...
So I tested this and I can reproduce it, it also happens when selecting a language that automatically picks multiple layouts (e.g. Russian) - you don't have to do the layout configuration yourself.
However, it also reproduces with F34 - it's not a new bug. I think we have much older bugs in this area, too. It's *sort of* odd that the KDE live image exposes this mechanism at all, because it's competing with the running desktop's own input method handling. The spoke is intentionally suppressed on the Workstation live image, you're supposed to configure layouts through the desktop if you want something other than us during installation, and ditto after installation.
I haven't yet figured out more about the detailed mechanics here, but it may not be something we can fix in a couple of days.
This is not just about KDE, also happens in Workstation (it's just that the User Creation spoke isn't there, so it's not that obvious). If you go into the Keyboard spoke, add a secondary layout, switch to it using the toggle up right, and that use the "test the layout configuration below" box to type stuff, any time that you press shift/alt/ctrl, the layout gets switched to the primary one. Of course, in Workstation installer, you don't really mind, because you don't type texts mostly anywhere, except for partition labels (and the disk encryption password must be typed in using the primary layout anyway, as a nearby warning box says).
Huh, I actually thought we hid the keyboard setup spoke on WS live. I need to find the old bugs about this, I'm sure it's come up before.
OK, https://bugzilla.redhat.com/show_bug.cgi?id=1389959 is the existing issue in this area. Per that, for a long time the known situation has been that switching as configured by anaconda just *doesn't work* on Wayland (so, nowadays, on both WS and KDE lives).
So, it seems something changed there such that now pressing any modifier key reverts from secondary to primary layout (but doesn't switch the other way), which is, yeah...odd. I don't know what changed, yet.
Discussed during the 2021-10-25 blocker review meeting: 
The decision to classify this bug as an "AcceptedBlocker (Final)" was made as it violates the following criterion:
"If a particular keyboard layout has been configured for the system, that keyboard layout must be used: ..."
"in the installer" is not listed in that criterion, but we agree this is an oversight and it is intended to be covered (we will rectify this later).
OK, so, heh, on further testing - this hasn't actually got any worse lately. The bug reproduces exactly as described all the way back to Fedora 25.
The only difference is that KDE went to Wayland by default in F34, so the bug showed up in KDE lives first in F34. And as discussed above, it's a bit more likely to be a practical problem on the KDE live where you can do user creation during install than on the WS live where you can't.
But we don't need to go looking in changes in the F35 or F34 cycles for the cause of this; it's probably been this way since we first imported wayland.
Oh, I did also figure a funny workaround for typing with a modifier key in the second layout: with the primary layout selected, hold down the modifier key *first*, then - without releasing it! - click the layout indicator to change to the secondary layout, type the character, and release the modifier key. As soon as you release the modifier key it will flip back to the primary layout, but as long as you keep it held down, you can type modified characters in the secondary layout.
AFAICS, this has nothing to do with modifiers, pressing just any key will revert to the default keyboard layout,
The reason for this is because Anaconda is still an X11 application, meaning that it is running on Xwayland.
X11 applications cannot change the keyboard layout in Wayland (simply because X11 applications talk to Xwayland which is not the display server, the display server is the Wayland compositor), only the Wayland compositor can, so changing the keyboard layout in Anaconda running on Xwayland has no actual effect, and when pressing any key, the Wayland compositor will just resend the xkb-layout resetting it to the default.
It's the same as trying to change the keyboard layout with setxkbmap, it just cannot work in Wayland as it's an X11 tool using X11 protocols (https://gitlab.freedesktop.org/xorg/app/setxkbmap/-/merge_requests/1)
GNOME has a gsettings key to select the index in the list of configured the keyboard layouts, Anaconda should use it in GNOME Shell, I don't know if KDE has a similar interface though, this is a question I'll leave for KDE developers to answer.
A web search reveals that something like that should work in kde:
qdbus org.kde.keyboard /Layouts setLayout "…"
Adam please remove the blocker state for this bug. This can't be fixed easily and it should be ideally fix by bug 1955025.
(In reply to Olivier Fourdan from comment #10)
> AFAICS, this has nothing to do with modifiers, pressing just any key will
> revert to the default keyboard layout,
Olivier, that's not the case here. In the Keyboard test area, I can easily write special characters using the secondary layout, *until* I press a modifier key (then the layout reverts to the primary one). Also clicking on the GNOME's top bar (or probably switching to a different window in general) resets the layout.
(In reply to Jiri Konecny from comment #13)
> Adam please remove the blocker state for this bug. This can't be fixed
> easily and it should be ideally fix by bug 1955025.
Just a note, there's no need to remove the blocker proposal. It can stay a blocker and we can still waive it on the grounds that it's hard to fix. It will then become a blocker for the next milestone (F36 Beta).
(In reply to Kamil Páral from comment #14)
> (In reply to Olivier Fourdan from comment #10)
> > AFAICS, this has nothing to do with modifiers, pressing just any key will
> > revert to the default keyboard layout,
> Olivier, that's not the case here. In the Keyboard test area, I can easily
> write special characters using the secondary layout, *until* I press a
> modifier key (then the layout reverts to the primary one). Also clicking on
> the GNOME's top bar (or probably switching to a different window in general)
> resets the layout.
That bug is about KDE (comment 0) so I tested in KDE :)
Olivier: it's the same in KDE.
(In reply to Adam Williamson from comment #16)
> Olivier: it's the same in KDE.
What is the same? I can see the xkb-layout being changed with any key in KDE, not just modifiers.
Anyway, whether the KDE or GNOME Wayland compositor resend the keymap on modifiers or regular key press is not relevant for the bug, what matters is that anaconda is using an X11 API that just cannot work with the Wayland compositor (comment 10).
Thanks for explanation Kamil.
I'm also convinced that this is the Wayland "issue". Based on my investigation we are getting signal that x-state-changed which is then reflected in the Anaconda. So the environment is forcing us the keyboard layout set by the environment not by Anaconda.
Olivier: what's "the same" is what Kamil described. in anaconda, you can type as much as you like in the secondary map, without it switching back to the primary map - but as soon as you press or release a modifier key, it switches back to the primary map.
We know that anaconda needs to use a different API for things to work *properly* (e.g. for key combination-based switching to actually work), but for a while I thought that at least the switch-on-modifier-key-press thing might be new behaviour. On further investigation it isn't, though.
Created attachment 1837523 [details]
bug demonstration video
Olivier, just to make sure we're on the same page, I created a video. It's from KDE, but it works exactly the same way in Workstation. When I type "shift now" and "alt now", I then press the modifier, and you can see the layout changes (but not before). You can also see I can use the secondary layout just fine (pressing numbers on a US keyboard produces special Czech characters with a Czech layout).
(In reply to Kamil Páral from comment #21)
> Olivier, just to make sure we're on the same page, I created a video. It's
> from KDE, but it works exactly the same way in Workstation.
OK, what I am trying to say is this is not important, it is not a problem with the modifiers per se.
The actual keymap is controlled by the Wayland compositor which passes it to its clients using the keyboard mapping event , so _whenever_ the Wayland compositor decides to send this keyboard mapping event (wl_keyboard_send_keymap).
When the compositor sends that keymap, any keymap change made by an X11 client using the X11 protocol will simply be discarded in Xwayland because the Wayland compositor is the only one in charge here.
From my testing, the same behavior happens in Fedora 34 Live WS.
Jens: I already confirmed that it's the same all the way back to Fedora Workstation 25.
The only 'recent' change here is that the KDE live went to Wayland in F34. This bug is more noticeable in the KDE live because it exposes more spokes where you might actually want to type something in the secondary layout (notably the User spoke). But the actual behaviour has not changed. We thought it was new at first but we were mistaken.
Once F35 is signed off and the excitement dies down we can probably combine this with https://bugzilla.redhat.com/show_bug.cgi?id=1389959 as a general 'keyboard layout stuff on lives is weird until we port to a library that understands Wayland' bug.
In today's Go/No-Go meeting, agreed to waive this to F36 Beta under the "difficult to fix" exception:
I'm in middle of the looking for a possible solutions but right now the best possible solution is to avoid keyboard changing in Live with Wayland and leave that on DE / WM where the Anaconda is running. So, I would maybe first concentrate on that to unblock the Fedora and then I can do a bigger picture part.
There are of course things to be solved.
Do we want to install layouts based on the Live settings and completely hide the spoke?
We need to make clear that the flag (to switch layouts) is not visible and users should use the DE instead.
Any idea why that would be a problem?
Hi Jiri, a couple of thoughts/concerns related to hiding the keymap spoke and leaving it to all to DE:
* Anaconda would need to instruct users to configure their keymaps in the DE, because otherwise it's not obvious that that's the expected approach. No other desktop changes are transferred to the installed system, so this would be an unexpected exception.
* It might be non-trivial for people to figure out how to configure the keymap, especially when they're not experienced with that DE. Imagine a first time Linux user who wants to install Fedora, but hasn't worked with GNOME before. The keymap switcher is not visible by default, and it takes some effort to find it in system settings. Even slightly experienced users might not know where to find it, because they never needed before. (E.g. If I pick Czech keymap in F35's Anaconda, I get a Czech keymap in the installed system, but no keymap switcher is visible, because Czech is the only layout enabled -> such an user would've never interacted with the OS switcher before).
* How do you determine the default keymap? That's important e.g. for disk encryption, there's a prominent warning related to it. Anaconda should guide users to encrypt their disks using the default keymap, display which one it is, and the users need to know how to change it if needed.
The first two items could perhaps be solved by keeping the keymap spoke, but replacing the configuration widgets with instructions for the particular DE. Perhaps even a button to open the DE's configuration, like executing `gnome-control-center keyboard`. I don't know about the third one.
In the future, we want the workflow to be:
gnome-initial-setup runs to offer language and keyboard layout selection -> user boots to live desktop -> user starts anaconda -> anaconda should obviously not offer language or keyboard layout selection -> user installs and reboots -> user gets the rest of gnome-initial-setup, then gnome-tour
So in the long run, hiding the keyboard layout selection is actually consistent with our workflow goals. But we're not there yet, and nobody is working on it right now. If you remove keyboard layout from anaconda today, then as Kamil says, it's going to be very hard for anyone with a non-US keyboard layout to install Fedora. I would just give up and switch to Ubuntu. So not a good idea to do that today.
Michael: that also only considers the GNOME case. anaconda is the installer on *every* live image, for *every* desktop we ship, so the solution needs to work for all of them, so unless they all want to introduce an initial setup step to the live environment, we still have a problem.
Unfortunately it does seem a bit tricky to come up with a solution, unless we can get some kind of universal interface for anaconda to use for Wayland desktops like it had for X. I wonder what other distros are doing about this? Presumably they have the same problem.
Oh yeah... for some reason I was thinking other desktops used non-live installers, but that's not true.
I understand your points, however, if you read bug 1955025 there is no reasonable solution for Anaconda to control Wayland DE/WM. There is nothing like one API to set everything because Wayland based DE/WM don't want to have that. The system should be in control of this that is the logic around that and that is exactly what I'm trying to achieve here.
I see the proposed solution as the least painful one. Also about the other WM/DE, as I said this will take into account only in case when there is Wayland in play.
The other solutions:
- we wanted to do this but it would be significant overhaul and required help from each Wayland based DE/WM. Still one of the best solutions. That would be, that Anaconda would create one DBus API which will be there for just Anaconda (means Live system) and implemented by the current DE/WM (not by us).
- we would try to use Initial Setup to what Michael described above. (not sure if that is doable and honestly I don't know if we want to add Initial Setup to more places)
(In reply to Kamil Páral from comment #27)
> Hi Jiri, a couple of thoughts/concerns related to hiding the keymap spoke
> and leaving it to all to DE:
Also we don't have to hide the spoke. However, in that case we have to make sure that the keyboard layout used in the Live env is the same as being installed to the system (selected by the spoke). Which could be problematic and pretty confusing to people.
I actually see another problem hidden between Jiri's suggestion and Kamil's reply. Kamil replied "No other desktop changes are transferred to the installed system, so this would be an unexpected exception", but Jiri didn't actually say that would happen, and I don't think it would be easy to do it. As well as there being no API for anaconda to control the keyboard config in Wayland, I don't think there's a single standard configuration system either - I think each desktop handles configuration differently.
So I don't think it'd be easy at all for anaconda to actually transfer any keyboard config you made in the live desktop to the installed system. We probably wouldn't want to try, honestly, because it'd be a big pile of bug-prone code. So any settings you make in the live DE are probably going to be transient - you'll have to recreate them on the installed system. Which could be a problem in the case of setting encryption passphrases.
Honestly, the more I think about this the more I just see insoluble problems :(
I can only said - welcome to my world. --- However, I might have a possible solution. I just need to test it a bit today before confuse people here.
Although reading your post again I wonder. Is it really that there is not a consistent configuration file for the Wayland systems? I wonder because from the code, and I have to verify that, we are basically copy configuration files from a specific place in the installation environment to the installed system and I never heard that this logic is not working.
Are you sure about the configuration Adam?
Nope! Is that /etc/vconsole.conf ? That's the config for systemd-localed, and yeah, it might be that desktops are picking that up. I have not actually tested it. But what I mean is, when you select a keyboard layout or input method *in GNOME* or *in KDE*, I'm not sure whether they write it back to that, or configure it in their own config systems.
Keyboard layout configuration in GNOME:
$ gsettings get org.gnome.desktop.input-sources sources
That's all there is to it.
You've have to look at the keyboard layout configuration page in gnome-initial-setup to see exactly how it interacts with localed. I think localed is only used to set the default value that gets preselected when you run gnome-initial-setup.
I've spent more time on this issue and unfortunately I don't have good news.
* I looked on localectl if that could be used:
No, it can't be used because it's system configuration. Anaconda is using this to create the default *system* configuration which is read by the environment on the first boot but it's not used after that. If you change the layout on the Live then it's *not* reflected in the localectl configuration and vice-versa, so this is not the way to go.
* Copy the environment configuration file:
As I understand it, every environment is storing the keyboard layout settings their own way, so we don't have any simple way to use that.
* Use environment specific API to read system configuration:
That could work, however, there is no single data specification for that, so again we had to have implementation for every environment or they have to provide that to us. And based on the other discussions I had there is no intention to have public API to set keyboard layout configuration. Still a possibility but it will need big changes and as I said not sure if we want to follow this or not.
* Open system configuration on a keyboard configuration /tab/ from Anaconda:
Not doable on the KDE by Anaconda because we can't start the application from the xWayland app (Anaconda) which is started as root. We can workaround that by having other App with DBus connection or maybe something similar.
* Set Anaconda in a mode that we can't change the keyboard configuration and try to make that visible to user:
Implemented in the simple form (hide existing layout indicator and warning in the keyboard spoke). Honestly, I see this as the only reasonable solution right now. This can be improved by adding warnings on place where you write passwords or similar things.
I'm adding screenshots of the "not handle keyboard configuration in Anaconda" solution. Just for info. I would like to know your idea what solution would you prefer, right now I think we need to decide before moving further.
Created attachment 1861776 [details]
Created attachment 1861777 [details]
I was kinda afraid we'd end up here, yeah.
I agree this may be the way to go, unfortunately. The fancy dbus solution would be nice but it's committing someone to a reasonable degree of work, and requires buy-in from at least KDE and GNOME...
If we're going with the 'just not allowed' approach, I'd like the warning to be a bit more high profile, I think. And maybe have it reinforced on spoke close, like we do for other cases where we really want you to confirm something before you leave a spoke...
I think GNOME could live with this as long as anaconda gets the default keyboard layout to use from localed instead of just assuming en_US. That would allow us to pass along the correct keyboard layout from gnome-initial-setup to anaconda via localed.
gnome-initial-setup doesn't run on boot of the live image, though. Is that changing?
Not imminently, but hopefully eventually. See: comment #28
Ok, I also have another, yet not a beautiful solution.
What if Anaconda provided an overlay graphical keyboard (or perhaps a character table) that would allow to choose special characters using users' mice?
I don't think that would be less confusing or better UX than disconnecting the control of the keyboard configuration between system and Anaconda.
Copying this message from ticket https://pagure.io/fedora-qa/blocker-review/issue/577 -- seems to be missed there.
I guess we are in the situation that we have to decide about the solution here. There are two ways to "solve" this which I'm able to find out.
One is to disconnect keyboard control between Live system and Anaconda. So Anaconda will handle after installation keyboard configuration and Live will handle current Live.
- this will solve the current bug issue
- could be confusing to people
- it's not really a fix
Another solution is to leave it as it is. I know it's broken but AFAIK there is no fix in the Anaconda project to solve this. In general there is no fix I could create which would not be additional work for Live maintainers.
- not a solution
- not really sure if this is worse or better solution than the above
I honestly don't mind about any of these solution but I would like to know your input if you think it's better to fix this or not. My personal preference is to go with the second option, it's less disruptive for people who use English for the installation.
Also if we are going with the first fix. Do we want to use this for all the Wayland systems or just KDE where it's currently the biggest issue?
P.S.: I think there could be a better solution in general but that is more about F38+ it would be a bigger change on more than just Anaconda but could improve the overall experience for Live maintainers and Anaconda. The solution is in discussion with all the required parties and I have ACK from them that it's doable and they are fine to do that. I'll contact Fedora community but this is not a correct place to do that.
I slightly prefer #1, but I agree it's still not exactly a great result.
(In reply to Jiri Konecny from comment #47)
> One is to disconnect keyboard control between Live system and Anaconda. So
> Anaconda will handle after installation keyboard configuration and Live will
> handle current Live.
I'm OK with anaconda not respecting user-specific (desktop-specific) keyboard layout changes made in the live system. It seems like a practical approach to sidestep this problem.
I hope anaconda will default to the keyboard layout declared by localed so that initial setup tools that run before anaconda can pass config along to anaconda. For Workstation, we will most likely suppress the keyboard layout spoke entirely, and if it doesn't pick up keyboard layout config via localed, we'll have a problem. At least localed is only one system-wide configuration with a stable API, nothing desktop-specific or user-specific.
Hi, ok, in that case, I'll finish my keyboard configuration split on Live and fix this soon. I also think that the correct approach here is to disable it for the whole Wayland so Gnome and KDE.
Honestly, as I briefly described we are looking on a way how to get Anaconda out of the Live environment completely (not killing Live images nor having it separate from the installation ISO). However, I still need to discuss some more pieces. If this will be the thing, the Initial Setup on the Live media will not be important to Anaconda. However, let's move this discussion to the proper place when I'll collect all the required information.
To answer your question, Anaconda is using localed to store the configuration right now, it shouldn't be too problematic to extend that also to read the default from that.
(In reply to Jiri Konecny from comment #50)
> Honestly, as I briefly described we are looking on a way how to get Anaconda
> out of the Live environment completely (not killing Live images nor having
> it separate from the installation ISO). However, I still need to discuss
> some more pieces. If this will be the thing, the Initial Setup on the Live
> media will not be important to Anaconda. However, let's move this discussion
> to the proper place when I'll collect all the required information.
We were actually discussing this quite recently in #workstation:fedoraproject.org. I think a *separate* live session that only runs anaconda would be a good idea. You probably still have to run under GNOME, though; otherwise, you'd need to reimplement too many features provided by the top bar. We particularly do not want to lose the battery status or accessibility features that are currently only available in the live installer.
> To answer your question, Anaconda is using localed to store the
> configuration right now, it shouldn't be too problematic to extend that also
> to read the default from that.
The PR for this is submitted already in fact, but sitting around for a week...
PR: https://github.com/rhinstaller/anaconda/pull/3912 -- finally finished
FEDORA-2022-840ea87072 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-840ea87072
FEDORA-2022-840ea87072 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-840ea87072`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-840ea87072
See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Unfortunately the change here just flat out doesn't work in my testing. I grabbed the live image that openQA built, booted it locally, confirmed it has anaconda-36.16.2-3.fc36.x86_64 in it, confirmed that GNOME was running on Wayland, ran the installer, and chose Russian.
Result: the layout indicator is still displayed on every installer screen, the keyboard layout configuration spoke is present and lets you do stuff, and clicking on the indicator still tries to change the layout. The bug is still present, too - selecting 'ru' and hitting the shift key switches to 'us'.
Ah. I think I see the problem. The upstream commit adds `Requires: xisxwayland` to anaconda.spec.in , but when the fix was backported to F36, the actual live F36 spec file did not have that dependency added. So the live image does not include xisxwayland , and anaconda decides it's *not* running on Wayland.
If I do 'dnf install xisxwayland' before running the live installer, things work as expected.
I'll do another build of the F36 package with the Requires: xisxwayland added.
OK, looks better with the new build.
FEDORA-2022-840ea87072 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.
This needs verification with Beta 1.2 image.
I already verified the fix above...
Well you said it "looks better", which could mean many things :-) And you didn't switch it to verified, so I wasn't sure what to make of it. I assume it's fully tested, then, closing.