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

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

4 Likes

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.

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

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

What does this mean for the non wayland spins?

ie, xfce, i3, etc

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.

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.

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?

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.

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.

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

To find out more, please visit our Changes Policy documentation

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.