F41 Change Proposal: Anaconda as native Wayland application (System Wide)

Project Discussion Change Proposals
,
1

Anaconda as native Wayland application

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

:link: Summary

Currently, Anaconda is still an X11 application, which we would like to fix and make Anaconda Wayland native application to allow us drop of the X11 dependencies from installation ISO images. However, this change is not just a simple switch and we need to do some adjustments during the path which will impact user experience.

:link: Owner

:link: Detailed Description

Anaconda is required to migrate to Wayland native application to drop dependencies from the installation ISO images which are deprecated. Package owners want to drop libXklavier from Fedora (see 1955025 – Anaconda needs to change keyboard layout switching library ) but also Xorg server from CentOS Stream and RHEL. However, this change won’t be just simple switching from X11 to Wayland, we also need to change a few things in Anaconda to be able to remove the X11 dependencies. This will have two main visible impacts listed below.

:link: VNC switch to RDP for remote GUI installations

Anaconda has to remove ‘TigerVNC’ which is used for VNC connection to be able to install your machine remotely with graphical UI. Reason is that TigerVNC is built from the Xorg server sources, so we would still depend on the Xorg server with this project. As replacement, we follow the recommendation of the Fedora Workstation to switch to Gnome Remote Desktop (grd) with a better protocol Remote Desktop Protocol (RDP) which gives users better performance and security.

This will have an impact on current vnc kickstart commands and kernel boot options of Anaconda. This will impact only the Anaconda installation environment (boot.iso).

:link: Consistent keyboard control

Currently, Anaconda experiences difficulties in handling keyboard layouts in the installation environment, particularly on Wayland. Formerly, libXklavier was utilized by Anaconda to manage keyboard layout configuration, however, it proved unstable on Wayland. As a result, Anaconda has disabled keyboard handling during Wayland Live media installations due to unexpected behavior (refer to 2016613 – When running anaconda on Wayland with two keyboard layouts configured, hitting any modifier key with the second layout selected switches to the first layout ). This approach may lead to situations when users encountering issues while unlocking LUKS devices or using user passwords in the installed system because installation was done with a different keyboard layout.

To exacerbate the situation, there is no universally applicable solution for keyboard handling on Wayland systems, as Wayland lacks a unified API for keyboard management. It means that each Fedora Desktop Environment developed their own API. Unfortunately, the Anaconda team is not able to maintain a custom solution for each Fedora spin. Some Desktop environments started to use systemd-localed DBus API to address this issue and similar issues. The systemd-localed API seems to be the best approach currently, so we want to promote it as a shared solution for all Fedora spins.

The plan is:

  • All Fedora spins and Anaconda listen on org.freedesktop.locale1 and reflect configuration on the currently running system (might be only for Live media if desired)
  • All Fedora spins and Anaconda reflect their configuration to org.freedesktop.locale1
  • In case Fedora spin will not support org.freedesktop.locale1, the keyboard configuration of Anaconda won’t be reflected in the current system and the situation will be similar to the current Live Wayland experience

All the spin owners were notified about this request:

:link: Feedback

We have some feedback from the SIG owners for the keyboard handling (see the links above). We don’t have feedback for the VNC to RDP switch yet.

:link: Benefit to Fedora

  • This change will enable removal of X11 dependencies from the Anaconda which may result in reduction of installed software to the system when installing from Live ISO where ISO content is copied to the installed system (depends on the spin dependencies).
  • Switching from VNC to RDP allow users to use remote graphical installations which are more secure and have better performance .

:link: Scope

  • Proposal owners: The Anaconda team will implement changes required in the Anaconda project. More specifically:

    • Switch Anaconda code to start Wayland environment on boot.iso instead of X11
    • Change keyboard switching logic to use systemd-localed DBus instead of libXklavier
    • Switch remote graphical installations from VNC (TigerVNC) to RDP (GRD)

  • Other developers: Fedora SIG owners needs to add support for their environment to listen and use systemd-localed DBus API to reflect current state of the DE/WM or they won’t have support of keyboard layout switching in Anaconda.

  • Release engineering: #12138

  • Policies and guidelines: Yes should be done after the implementation (Fedora Server remote interactive installation guide :: Fedora Docs should switch to RDP)

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with the Fedora Strategy:

:link: Upgrade/compatibility impact

This will impact only Fedora installations so no compatibility or upgrade issues.

:link: Early Testing (Optional)

We will reach Fedora QE to coordinate testing approach.

:link: How To Test

  1. Download any installation media
  2. Run the installation
  3. Look for breakages during the installation

Testing should be especially focused on:

  • Changing resolution with inst.resolution kernel boot option
  • Test new RDP solution (API will be clarified)
    • Password can be set to the RDP
    • Username can be set to the RDP
  • Test keyboard layout switching works correctly
    • On Live media, Anaconda should react on keyboard layout change in the DE and set that to the installed system
    • On Live media, Anaconda should be able to set the keyboard layout changes to the live environment
    • In the network installation (boot.iso) Anaconda should correctly reflect keyboard layouts changes so text in the Anaconda is written by the correct layout
    • Check if specific keyboard layouts are configured and installed as expected

:link: User Experience

The only visible change to user should be:

  • Remote graphical installations will use RDP instead of VNC.
  • Anaconda will be able to control keyboard layouts in the Wayland environment on Live ISOs. This will improve user experience when installing Fedora Workstation, Fedora KDE, Fedora Sway and other Wayland based environments.

:link: Dependencies

No dependencies of this package related to this change.

:link: Contingency Plan

  • Contingency mechanism: Postpone this change to next Fedora release. Revert landed changes in Anaconda if required.
  • Contingency deadline: 100% code completion deadline
  • Blocks release? No

:link: Documentation

No documentation yet. However, there are a few PRs ready for merge for CentOS Stream 10:

:link: Release Notes

TBD

Last edited by @amoloney 2024-05-31T08:37:22Z

5 Likes
2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply giving that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

I dont mind GRD, but for sticking with VNC, why not use KRFB?

4

As written in the proposal we are following Workstation recommendation. Also, we don’t want to get into situation when we have to support something on Fedora and something else on CentOS / RHEL.

1 Like
5

What does this mean for the non wayland spins?

ie, xfce, i3, etc

6

We need to test impact of these changes there but so far I don’t expect any issues with X11 Live environments. Anaconda is still an app running there and we won’t be starting our environment there. On the same note remote GUI access to the installer is not supported on Live environment, so it should be also fine.

What will impact non Wayland spins will be new requirement of keyboard handling depending on systemd-localed DBus API but that shouldn’t be a problem to implement shared solution for X11 keyboard handling.

7

We need to test impact of these changes there but so far I don’t expect any issues with X11 Live environments. Anaconda is still an app running there and we won’t be starting our environment there. On the same note remote GUI access to the installer is not supported on Live environment, so it should be also fine.

ok. I just wanted to make sure this was not moving to wayland only
As long as anaconda runs fine with a X session thats fine…

What will impact non Wayland spins will be new requirement of keyboard handling depending on systemd-localed DBus API but that shouldn’t be a problem to implement shared solution for X11 keyboard handling.

Yeah.

8

Similar to F41 Change Proposal: Wayland-only GNOME Workstation Media (self-contained) - #4 by adamwill , has there been any consideration of cases where Wayland apparently just flat out does not work? There are several such cases flagged in gdm’s udev rules, for instance. Would this mean the netinst and server DVD become unusable (or, I guess, text only) in such circumstances?

9

Wayland was previously unusable because we didn’t have SimpleDRM, I don’t think that’s an issue now, since all Wayland compositors can work even with nomodeset.

10

Hi, we won’t be able to keep both solution support. It’s a big change.
So no, we don’t plan to have fallback for Wayland currently.

11

This change proposal has now been submitted to FESCo with ticket #3219 for voting.

To find out more, please visit our Changes Policy documentation

12

There’s only one other edge case I can remember of where GDM falls back to the X11 session… when the user has the nvidia proprietary driver installed and configured to use s0ix sleep. I actually fixed that upstream… it should be on 46.2.
Assuming the user is getting the nvidia driver from rpmfusion (and follows the instructions properly if they make any configuration change), it should never trigger the GDM X11 fallback.

No idea how the VM stuff would behave though… It probably needs to be tested.

13

This change has been accepted by FESCo for Fedora Linux 41. A full list of approved changes to date can be found on the Change Set Page.

To find out more about how our changes policy works, please visit our docs site.

14

Hi everyone, after a discussion in a team and with Fedora QE we have decided to postpone this change to Fedora 42.

We have the code nearly ready, however, we have already missed the testable deadline and are approaching the 100% Code Completion deadline. We want to ensure sufficient time for proper testing rather than rushing the feature into Fedora. To avoid burdening the teams during the Fedora 41 branching, we’ve decided to push this code to Rawhide only and delay the change until Fedora 42. Ideally, we would also like to organize a proper test day on Rawhide.

4 Likes
15

Will this keep Orca working?

16

I’m not aware of any reason why it shouldn’t but would be great to test this on Rawhide when it lands.

17

On Wayland apps cannot read other app’s contents without a permission or portal. Afaik this breaks orca.

a workaround that the System76 people building COSMIC thought of was to just run Orca through XWayland until the push-like system is there.

this takes time and accessibility cant just wait, or can it?

18

It seems that Orca is not working in Anaconda for quite a while now :frowning: :
Orca does not read anaconda app under Wayland (did not tested it yet)

And Mate-compiz is the recommended approach:
if I’m reading the sources correctly:

This should be definitely tested but I guess nothing will change to the current state?

1 Like
19

I think it is good that this is postponed.

Visual Accessibility should not be a secondary option.

Afaik it doesnt work on Wayland at all, because even if the protocol is there, apps (toolkits) need to implement it all.

GNOME got a bigger donation to invest in this field, and I hope they work on methods that not only support GTK.

I also dont know about the accessibility state of the new WebUI.

20

Hi all,

I have a question about approach we want to take about Anaconda feature to warn user that we are not able to control keyboard layouts from system.

Current situation:
Anaconda will tell user that the keyboard switching is not possible from Anaconda and the keyboards after installation might be different than what is used by the Live media. This check basically detects Wayland because we knew that Wayland based systems are broken.

Unsupported keyboard layout switching (for example on Fedora Workstation Live ISO):

anaconda-disabled-keyboard-switching
anaconda-disabled-keyboard-switching1280×800 61.2 KB

Supported keyboard layout switching looks like:

anaconda-enable-keyboard-switching
anaconda-enable-keyboard-switching1280×800 63.5 KB

Also the icon for keyboard layout switching in the top right corner is visible everywhere in the Anaconda. This button is changing layouts in the system.

Situation with this change:
The original detection is wrong now (which is good because we support Wayland systems now), however, new solution with localed can’t be detected. Anaconda can’t tell if someone listens on the localed DBus API.

Solutions:

  1. Disable this feature with no replacement:
    If the spin doesn’t support systemd-localed for the keyboard layout switching functionality Anaconda won’t know that and behave as it is supported. This could be confusing for users.
  2. Force spins to have flag file signaling Anaconda that this feature is supported.
    It gives a bit more work to spins maintainers and it could be forgotten.

My recommendation would be 2.nd point as it could be easily implemented by kickstart, so that Live ISO. However, it might be that I don’t see something. Any feedback?