Wiki - https://fedoraproject.org/wiki/Changes/Anaconda_As_Native_Wayland_Applicatio... Discussion Thread - https://discussion.fedoraproject.org/t/f41-change-proposal-anaconda-as-nativ...
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.
== 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.
== Owner == * Name: Anaconda team ([[User:jkonecny| Jiří Konečný]]) * Email: jkonecny@redhat.com
== 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 https://bugzilla.redhat.com/show_bug.cgi?id=1955025 ) 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.
=== 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).
=== 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 https://bugzilla.redhat.com/show_bug.cgi?id=2016613 ). 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: * https://pagure.io/fedora-workstation/issue/430 * https://pagure.io/fedora-kde/SIG/issue/504 * https://gitlab.com/fedora/sigs/sway/SIG/-/issues/36 * https://bugzilla.redhat.com/show_bug.cgi?id=2278655 * https://bugzilla.redhat.com/show_bug.cgi?id=2278658 * https://bugzilla.redhat.com/show_bug.cgi?id=2278656 * https://bugzilla.redhat.com/show_bug.cgi?id=2278864 * https://bugzilla.redhat.com/show_bug.cgi?id=2278866 * https://bugzilla.redhat.com/show_bug.cgi?id=2278869 * https://bugzilla.redhat.com/show_bug.cgi?id=2278874 * https://pagure.io/fedora-cosmic/SIG/issue/1 * https://pagure.io/fedora-budgie/project/issue/4 * https://pagure.io/fedora-lxqt/SIG/issue/4 * https://pagure.io/i3-sig/Fedora-i3-Spin/issue/70
== 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.
== 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 .
== 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: [https://pagure.io/releng/issue/12138 #12138]
* Policies and guidelines: Yes should be done after the implementation (https://docs.fedoraproject.org/en-US/fedora-server/installation/interactive-... should switch to RDP)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
This will impact only Fedora installations so no compatibility or upgrade issues.
== Early Testing (Optional) ==
We will reach Fedora QE to coordinate testing approach.
== How To Test ==
# Download any installation media # Run the installation # 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
== User Experience ==
The only visible change to a 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.
== Dependencies ==
No dependencies of this package related to this change.
== Contingency Plan ==
* Contingency mechanism: Postpone this change to the next Fedora release. Revert landed changes in Anaconda if required. * Contingency deadline: 100% code completion deadline * Blocks release? No
== Documentation ==
No documentation yet. However, there are a few PRs ready for merge for CentOS Stream 10: * https://github.com/rhinstaller/anaconda/pull/5463 * https://github.com/rhinstaller/anaconda/pull/5470 * https://github.com/rhinstaller/anaconda/pull/5485 * https://github.com/rhinstaller/anaconda/pull/5498
== Release Notes ==
TBD
On 31 May 2024, at 09:36, Aoife Moloney amoloney@redhat.com wrote:
Anaconda is required to migrate to Wayland native application to drop dependencies from the installation ISO images which are deprecated.
Do you expect this to be an issue for users with nvidia GPUs?
Barry
To my knowledge it shouldn't be. Fedora Workstation is already running on Wayland by default for quite some time and even Live ISO is already Wayland. To my knowledge Wayland don't have issues with graphics cards in general.
The only exception to my knowledge is Sway, where this is an upstream project issue they are trying to resolve. However, Sway is Wayland only so again no impact from this change.
But maybe someone who has more knowledge about compositors and GPU drivers would answer this better than me.
Best Regards, Jirka
On 31. 05. 24 10:58, Barry wrote:
On 31 May 2024, at 09:36, Aoife Moloney amoloney@redhat.com wrote:
Anaconda is required to migrate to Wayland native application to drop dependencies from the installation ISO images which are deprecated.
Do you expect this to be an issue for users with nvidia GPUs?
Barry
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
To my knowledge it shouldn't be. Fedora Workstation is already running on Wayland by default for quite some time and even Live ISO is already Wayland. To my knowledge Wayland don't have issues with graphics cards in general.
GNOME has a fallback mechanism where it automatically runs the X.org session if the Wayland session doesn't work. I believe that is active on the live image. Of course, as telemetry is evil, we have absolutely no idea how many Fedora users actually hit this mechanism.
Sounds good!
Leslie Satenstein
On Friday, May 31, 2024 at 11:05:14 a.m. EDT, Adam Williamson adamwill@fedoraproject.org wrote:
On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
To my knowledge it shouldn't be. Fedora Workstation is already running on Wayland by default for quite some time and even Live ISO is already Wayland. To my knowledge Wayland don't have issues with graphics cards in general.
GNOME has a fallback mechanism where it automatically runs the X.org session if the Wayland session doesn't work. I believe that is active on the live image. Of course, as telemetry is evil, we have absolutely no idea how many Fedora users actually hit this mechanism.
On 6/1/24 1:04 AM, Adam Williamson wrote:
On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
To my knowledge it shouldn't be. Fedora Workstation is already running on Wayland by default for quite some time and even Live ISO is already Wayland. To my knowledge Wayland don't have issues with graphics cards in general.
GNOME has a fallback mechanism where it automatically runs the X.org session if the Wayland session doesn't work. I believe that is active on the live image. Of course, as telemetry is evil, we have absolutely no idea how many Fedora users actually hit this mechanism.
One comment I would make is that VirtualBox doesn't *properly* support Wayland [yet] requiring GNOME to be run as an Xorg session (of course not an issue for Xfce etc).
If Anaconda is to be Wayland, my concern is that it may make all DEs uninstallable, even ones like Xfce far removed from Wayland.
-- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney
On Tue, 2024-06-04 at 13:39 +1000, Ian Laurie via devel wrote:
On 6/1/24 1:04 AM, Adam Williamson wrote:
On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
To my knowledge it shouldn't be. Fedora Workstation is already running on Wayland by default for quite some time and even Live ISO is already Wayland. To my knowledge Wayland don't have issues with graphics cards in general.
GNOME has a fallback mechanism where it automatically runs the X.org session if the Wayland session doesn't work. I believe that is active on the live image. Of course, as telemetry is evil, we have absolutely no idea how many Fedora users actually hit this mechanism.
One comment I would make is that VirtualBox doesn't *properly* support Wayland [yet] requiring GNOME to be run as an Xorg session (of course not an issue for Xfce etc).
If Anaconda is to be Wayland, my concern is that it may make all DEs uninstallable, even ones like Xfce far removed from Wayland.
Looking at the change, it's not totally clear to me, but it looks like this is actually mainly about how anaconda is run in the installer environment - netinst, server DVD, and ostree installer images. It's not about live images.
I *think* anaconda would continue to run as an X app if launched from a live desktop running on X. But it would be nice to have that clarified in the Change scope, and any changes to how it would behave in such an environment.
On 04. 06. 24 8:21, Adam Williamson wrote:
On Tue, 2024-06-04 at 13:39 +1000, Ian Laurie via devel wrote:
On 6/1/24 1:04 AM, Adam Williamson wrote:
On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
To my knowledge it shouldn't be. Fedora Workstation is already running on Wayland by default for quite some time and even Live ISO is already Wayland. To my knowledge Wayland don't have issues with graphics cards in general.
GNOME has a fallback mechanism where it automatically runs the X.org session if the Wayland session doesn't work. I believe that is active on the live image. Of course, as telemetry is evil, we have absolutely no idea how many Fedora users actually hit this mechanism.
One comment I would make is that VirtualBox doesn't *properly* support Wayland [yet] requiring GNOME to be run as an Xorg session (of course not an issue for Xfce etc).
If Anaconda is to be Wayland, my concern is that it may make all DEs uninstallable, even ones like Xfce far removed from Wayland.
Looking at the change, it's not totally clear to me, but it looks like this is actually mainly about how anaconda is run in the installer environment - netinst, server DVD, and ostree installer images. It's not about live images.
I *think* anaconda would continue to run as an X app if launched from a live desktop running on X. But it would be nice to have that clarified in the Change scope, and any changes to how it would behave in such an environment.
Is it better now? I tried to extend the Scope section of the change.
Best Regards, Jirka
On Tue, 2024-06-04 at 14:23 +0200, Jiri Konecny wrote:
On 04. 06. 24 8:21, Adam Williamson wrote:
On Tue, 2024-06-04 at 13:39 +1000, Ian Laurie via devel wrote:
On 6/1/24 1:04 AM, Adam Williamson wrote:
On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
To my knowledge it shouldn't be. Fedora Workstation is already running on Wayland by default for quite some time and even Live ISO is already Wayland. To my knowledge Wayland don't have issues with graphics cards in general.
GNOME has a fallback mechanism where it automatically runs the X.org session if the Wayland session doesn't work. I believe that is active on the live image. Of course, as telemetry is evil, we have absolutely no idea how many Fedora users actually hit this mechanism.
One comment I would make is that VirtualBox doesn't *properly* support Wayland [yet] requiring GNOME to be run as an Xorg session (of course not an issue for Xfce etc).
If Anaconda is to be Wayland, my concern is that it may make all DEs uninstallable, even ones like Xfce far removed from Wayland.
Looking at the change, it's not totally clear to me, but it looks like this is actually mainly about how anaconda is run in the installer environment - netinst, server DVD, and ostree installer images. It's not about live images.
I *think* anaconda would continue to run as an X app if launched from a live desktop running on X. But it would be nice to have that clarified in the Change scope, and any changes to how it would behave in such an environment.
Is it better now? I tried to extend the Scope section of the change.
Yes, that does look clearer. Thanks.
Hi Ian,
On 6/4/24 5:39 AM, Ian Laurie via devel wrote:
On 6/1/24 1:04 AM, Adam Williamson wrote:
On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
To my knowledge it shouldn't be. Fedora Workstation is already running on Wayland by default for quite some time and even Live ISO is already Wayland. To my knowledge Wayland don't have issues with graphics cards in general.
GNOME has a fallback mechanism where it automatically runs the X.org session if the Wayland session doesn't work. I believe that is active on the live image. Of course, as telemetry is evil, we have absolutely no idea how many Fedora users actually hit this mechanism.
One comment I would make is that VirtualBox doesn't *properly* support Wayland [yet] requiring GNOME to be run as an Xorg session (of course not an issue for Xfce etc).
I'm a bit surprised by this. I use VirtualBox both as host under a GNOME wayland session and the guests inside that VirtualBox host also use Wayland.
The only feature which I'm aware of which does not work is the mode where only the guest windows are shown. Everything else works fine.
What exactly is not working for you when you run a GNOME Wayland session inside a VirtualBox guest ?
Regards,
Hans
On Tue, Jun 4, 2024 at 4:34 AM Hans de Goede hdegoede@redhat.com wrote:
Hi Ian,
On 6/4/24 5:39 AM, Ian Laurie via devel wrote:
On 6/1/24 1:04 AM, Adam Williamson wrote:
On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
To my knowledge it shouldn't be. Fedora Workstation is already running on Wayland by default for quite some time and even Live ISO is already Wayland. To my knowledge Wayland don't have issues with graphics cards in general.
GNOME has a fallback mechanism where it automatically runs the X.org session if the Wayland session doesn't work. I believe that is active on the live image. Of course, as telemetry is evil, we have absolutely no idea how many Fedora users actually hit this mechanism.
One comment I would make is that VirtualBox doesn't *properly* support Wayland [yet] requiring GNOME to be run as an Xorg session (of course not an issue for Xfce etc).
I'm a bit surprised by this. I use VirtualBox both as host under a GNOME wayland session and the guests inside that VirtualBox host also use Wayland.
The only feature which I'm aware of which does not work is the mode where only the guest windows are shown. Everything else works fine.
What exactly is not working for you when you run a GNOME Wayland session inside a VirtualBox guest ?
There have been significant issues with GNOME and KDE Plasma on VirtualBox over the past few years. Honestly, we need to start regularly testing it, because the guest integration is brittle and nobody notices until it's too late. I personally do testing on VMware for KDE Plasma because otherwise it'd never get tested and issues would never get fixed.
The most recent issue is that it's unbearably slow and sometimes suffers serious graphics corruption unless 3D acceleration is turned on.
-- 真実はいつも一つ！/ Always, there's only one truth!
On 6/4/24 6:56 PM, Neal Gompa wrote:
The most recent issue is that it's unbearably slow and sometimes suffers serious graphics corruption unless 3D acceleration is turned on.
Current best practice appears to be that 3D must be turned off. With it on, nothing works, not even an Xorg session. However, it is fickle, depending on the GNOME stack, there have been times when 3D on was better. With 3D off, and GNOME in an Xorg session, it almost works.
-- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney
On 6/4/24 6:34 PM, Hans de Goede wrote:
What exactly is not working for you when you run a GNOME Wayland session inside a VirtualBox guest ?
Hi Hans,
Sadly in my case I suffer the full range of problems, blocky massive empty cursor, Old TV style loss of horizontal sync (video buffer overlap problem apparently).... basically I have all the issues outlined below with screen shots shown, topics posted relate to Ubuntu but I have the issue on Fedora (in my case, host is Fedora-Xfce-40 and guest is Fedora-GNOME-40):
https://forums.virtualbox.org/viewtopic.php?t=110882
https://forums.virtualbox.org/viewtopic.php?t=110982
https://www.virtualbox.org/ticket/21955
The above links have many other links, but see comment 22 on the ticket.
On my recent failed attempt for a GNOME VM under VirtualBox, I converted the VM to QEMU/KVM via a raw image (not a difficult procedure). Under QEMU/KVM the exact same VM install works flawlessly. So it wasn't that my installation went wrong.
-- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney
Ian Laurie via devel venit, vidit, dixit 2024-06-05 01:47:47:
On 6/4/24 6:34 PM, Hans de Goede wrote:
What exactly is not working for you when you run a GNOME Wayland session inside a VirtualBox guest ?
Hi Hans,
Sadly in my case I suffer the full range of problems, blocky massive empty cursor, Old TV style loss of horizontal sync (video buffer overlap problem apparently).... basically I have all the issues outlined below with screen shots shown, topics posted relate to Ubuntu but I have the issue on Fedora (in my case, host is Fedora-Xfce-40 and guest is Fedora-GNOME-40):
https://forums.virtualbox.org/viewtopic.php?t=110882
https://forums.virtualbox.org/viewtopic.php?t=110982
https://www.virtualbox.org/ticket/21955
The above links have many other links, but see comment 22 on the ticket.
On my recent failed attempt for a GNOME VM under VirtualBox, I converted the VM to QEMU/KVM via a raw image (not a difficult procedure). Under QEMU/KVM the exact same VM install works flawlessly. So it wasn't that my installation went wrong.
Doesn't this prove that it's really a VirtualBox problem, not a Fedora problem?
I mean, we still want Fedora to run "everywhere", but the previous discussion indicated a "Fedora problem", and your observations put things into perspective.
Michael
On 6/5/24 4:57 PM, Michael J Gruber wrote:
Doesn't this prove that it's really a VirtualBox problem, not a Fedora problem?
I mean, we still want Fedora to run "everywhere", but the previous discussion indicated a "Fedora problem", and your observations put things into perspective.
Virtual machines have to sneak out of their virtual existence and interact with the real world now and then, or they would be pointless, so virtualization is ultimately a fudge. The graphics side of it being the most complex part of the fudge.
I agree it is the task of the virtualization engine to keep up with guests developments and keep the fudge working, but Xorg works, and Wayland doesn't, and as a user I don't really care who is at fault.
If there were a little more give and take there could be fewer problems. As I understand things, the rush to run Anaconda in Wayland is going to break workflows because many folks DL the Everything-Netinstall ISOs and use it to install anything. Since the move to Wayland is unnecessary, it seems like it could be delayed until Wayland is better supported by the wider ecosystem.
Of all things, the installation mechanism should be chosen to be as broadly compatible with as much as possible, and frankly Wayland is currently not that.
That said, if my whole life was Linux, I would move to a QEMU/KVM only workflow, but I still have one pesky Win box in my life that I can't get rid of (at work) so VirtualBox for me still makes sense.
-- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney
On Tue, 2024-06-04 at 10:34 +0200, Hans de Goede wrote:
Hi Ian,
On 6/4/24 5:39 AM, Ian Laurie via devel wrote:
On 6/1/24 1:04 AM, Adam Williamson wrote:
On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
To my knowledge it shouldn't be. Fedora Workstation is already running on Wayland by default for quite some time and even Live ISO is already Wayland. To my knowledge Wayland don't have issues with graphics cards in general.
GNOME has a fallback mechanism where it automatically runs the X.org session if the Wayland session doesn't work. I believe that is active on the live image. Of course, as telemetry is evil, we have absolutely no idea how many Fedora users actually hit this mechanism.
One comment I would make is that VirtualBox doesn't *properly* support Wayland [yet] requiring GNOME to be run as an Xorg session (of course not an issue for Xfce etc).
I'm a bit surprised by this. I use VirtualBox both as host under a GNOME wayland session and the guests inside that VirtualBox host also use Wayland.
The only feature which I'm aware of which does not work is the mode where only the guest windows are shown. Everything else works fine.
What exactly is not working for you when you run a GNOME Wayland session inside a VirtualBox guest ?
I think kde sessions and sddm-wayland as guest and VirtualBox as server on KDE , are all broken with wayland
Also this may impact on this subject (Anaconda as native Wayland application)
We receive an email from a user report that reports that: https://lists.rpmfusion.org/archives/list/rpmfusion-users@lists.rpmfusion.or...
I don't want to start this discussion again, but I think people should be aware of what's going on around them.
And Hans, you are the only person I know who has the knowledge to fix this.
Thank you and best regards,
Regards,
Hans
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Sat, Jul 6, 2024 at 7:55 AM Sérgio Basto sergio@serjux.com wrote:
On Tue, 2024-06-04 at 10:34 +0200, Hans de Goede wrote:
Hi Ian,
On 6/4/24 5:39 AM, Ian Laurie via devel wrote:
On 6/1/24 1:04 AM, Adam Williamson wrote:
On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
To my knowledge it shouldn't be. Fedora Workstation is already running on Wayland by default for quite some time and even Live ISO is already Wayland. To my knowledge Wayland don't have issues with graphics cards in general.
GNOME has a fallback mechanism where it automatically runs the X.org session if the Wayland session doesn't work. I believe that is active on the live image. Of course, as telemetry is evil, we have absolutely no idea how many Fedora users actually hit this mechanism.
One comment I would make is that VirtualBox doesn't *properly* support Wayland [yet] requiring GNOME to be run as an Xorg session (of course not an issue for Xfce etc).
I'm a bit surprised by this. I use VirtualBox both as host under a GNOME wayland session and the guests inside that VirtualBox host also use Wayland.
The only feature which I'm aware of which does not work is the mode where only the guest windows are shown. Everything else works fine.
What exactly is not working for you when you run a GNOME Wayland session inside a VirtualBox guest ?
I think kde sessions and sddm-wayland as guest and VirtualBox as server on KDE , are all broken with wayland
Also this may impact on this subject (Anaconda as native Wayland application)
We receive an email from a user report that reports that: https://lists.rpmfusion.org/archives/list/rpmfusion-users@lists.rpmfusion.or...
I don't want to start this discussion again, but I think people should be aware of what's going on around them.
And Hans, you are the only person I know who has the knowledge to fix this.
For KDE Plasma, you need to enable 3D acceleration (which is not on by default).
See this post: https://pointieststick.com/2024/03/08/psa-enable-3d-acceleration-in-your-vir...
On 06/07/2024 14:06, Neal Gompa wrote:
For KDE Plasma, you need to enable 3D acceleration (which is not on by default).
What about KVM/qemu? AFAIK, 3D acceleration is still not supported without forwarding a physical GPU into a VM.
On Sat, Jul 6, 2024 at 8:22 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 06/07/2024 14:06, Neal Gompa wrote:
For KDE Plasma, you need to enable 3D acceleration (which is not on by default).
What about KVM/qemu? AFAIK, 3D acceleration is still not supported without forwarding a physical GPU into a VM.
Both modes work reasonably okay for me in GNOME Boxes and Virtual Machine Manager, though no-acceleration is still faster.
Am 06.07.24 um 15:22 schrieb Neal Gompa:
On Sat, Jul 6, 2024 at 8:22 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 06/07/2024 14:06, Neal Gompa wrote:
For KDE Plasma, you need to enable 3D acceleration (which is not on by default).
What about KVM/qemu? AFAIK, 3D acceleration is still not supported without forwarding a physical GPU into a VM.
Both modes work reasonably okay for me in GNOME Boxes and Virtual Machine Manager, though no-acceleration is still faster.
Looking forward to RHEL, where such fancy feature are all stripped away, does this impact RHEL10 deployments?
On Sat, 2024-07-06 at 08:06 -0400, Neal Gompa wrote:
On Sat, Jul 6, 2024 at 7:55 AM Sérgio Basto sergio@serjux.com wrote:
On Tue, 2024-06-04 at 10:34 +0200, Hans de Goede wrote:
Hi Ian,
On 6/4/24 5:39 AM, Ian Laurie via devel wrote:
On 6/1/24 1:04 AM, Adam Williamson wrote:
On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
To my knowledge it shouldn't be. Fedora Workstation is already running on Wayland by default for quite some time and even Live ISO is already Wayland. To my knowledge Wayland don't have issues with graphics cards in general.
GNOME has a fallback mechanism where it automatically runs the X.org session if the Wayland session doesn't work. I believe that is active on the live image. Of course, as telemetry is evil, we have absolutely no idea how many Fedora users actually hit this mechanism.
One comment I would make is that VirtualBox doesn't *properly* support Wayland [yet] requiring GNOME to be run as an Xorg session (of course not an issue for Xfce etc).
I'm a bit surprised by this. I use VirtualBox both as host under a GNOME wayland session and the guests inside that VirtualBox host also use Wayland.
The only feature which I'm aware of which does not work is the mode where only the guest windows are shown. Everything else works fine.
What exactly is not working for you when you run a GNOME Wayland session inside a VirtualBox guest ?
I think kde sessions and sddm-wayland as guest and VirtualBox as server on KDE , are all broken with wayland
Also this may impact on this subject (Anaconda as native Wayland application)
We receive an email from a user report that reports that: https://lists.rpmfusion.org/archives/list/rpmfusion-users@lists.rpmfusion.or...
I don't want to start this discussion again, but I think people should be aware of what's going on around them.
And Hans, you are the only person I know who has the knowledge to fix this.
For KDE Plasma, you need to enable 3D acceleration (which is not on by default).
See this post: https://pointieststick.com/2024/03/08/psa-enable-3d-acceleration-in-your-vir...
For VitualBox as server seems that doesn't work Frédéric replied
"Thanks for the tip. You are right, I did not have acceleration enabled. However, it did not help to make it work with wayland."
-- 真実はいつも一つ！/ Always, there's only one truth!
On 04. 06. 24 5:39, Ian Laurie via devel wrote:
On 6/1/24 1:04 AM, Adam Williamson wrote:
On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
To my knowledge it shouldn't be. Fedora Workstation is already running on Wayland by default for quite some time and even Live ISO is already Wayland. To my knowledge Wayland don't have issues with graphics cards in general.
GNOME has a fallback mechanism where it automatically runs the X.org session if the Wayland session doesn't work. I believe that is active on the live image. Of course, as telemetry is evil, we have absolutely no idea how many Fedora users actually hit this mechanism.
One comment I would make is that VirtualBox doesn't *properly* support Wayland [yet] requiring GNOME to be run as an Xorg session (of course not an issue for Xfce etc).
If Anaconda is to be Wayland, my concern is that it may make all DEs uninstallable, even ones like Xfce far removed from Wayland.
You should be able to install from Live ISO which we are not modifying (depends on environment set by SIG owners). However, we won't support X11 together with Wayland on boot.iso. That would be hard to achieve given to the big amount of changes we are required to do now to support Wayland.
Jirka
-- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Tue, 2024-06-04 at 14:26 +0200, Jiri Konecny wrote:
On 04. 06. 24 5:39, Ian Laurie via devel wrote:
On 6/1/24 1:04 AM, Adam Williamson wrote:
On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
To my knowledge it shouldn't be. Fedora Workstation is already running on Wayland by default for quite some time and even Live ISO is already Wayland. To my knowledge Wayland don't have issues with graphics cards in general.
GNOME has a fallback mechanism where it automatically runs the X.org session if the Wayland session doesn't work. I believe that is active on the live image. Of course, as telemetry is evil, we have absolutely no idea how many Fedora users actually hit this mechanism.
One comment I would make is that VirtualBox doesn't *properly* support Wayland [yet] requiring GNOME to be run as an Xorg session (of course not an issue for Xfce etc).
If Anaconda is to be Wayland, my concern is that it may make all DEs uninstallable, even ones like Xfce far removed from Wayland.
You should be able to install from Live ISO which we are not modifying (depends on environment set by SIG owners). However, we won't support X11 together with Wayland on boot.iso. That would be hard to achieve given to the big amount of changes we are required to do now to support Wayland.
If you can't support X11 together with Wayland on boot.iso , why you want move to Wayland ? it is stupid break Linux user experience just because Wayland is fancy , what we get with Wayland that we don't get with X11 ? if you need remove X11 to add Wayland, don't do it ! . Don't break the other Linux user systems . Is difficult understand that you should not remove components without agreement of everyone ?
Linux should support all kind of hardware, if Wayland don't, you should provide at least fall backs , and not just ignore the others .
The removal of X11 from KDE , just because KDE SIG decide without consent of many members of Fedora which contribute to Fedora KDE , should not be acceptable .
Waste my energy discussing things that should be obvious , make me think if I still should contribute to this project .
Like Linus says "DON'T BREAK THE USER SPACE"
Best regards,
Jirka
-- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Am 11.06.24 um 14:52 schrieb Sérgio Basto:
On Tue, 2024-06-04 at 14:26 +0200, Jiri Konecny wrote:
On 04. 06. 24 5:39, Ian Laurie via devel wrote:
On 6/1/24 1:04 AM, Adam Williamson wrote:
On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
To my knowledge it shouldn't be. Fedora Workstation is already running on Wayland by default for quite some time and even Live ISO is already Wayland. To my knowledge Wayland don't have issues with graphics cards in general.
GNOME has a fallback mechanism where it automatically runs the X.org session if the Wayland session doesn't work. I believe that is active on the live image. Of course, as telemetry is evil, we have absolutely no idea how many Fedora users actually hit this mechanism.
One comment I would make is that VirtualBox doesn't *properly* support Wayland [yet] requiring GNOME to be run as an Xorg session (of course not an issue for Xfce etc).
If Anaconda is to be Wayland, my concern is that it may make all DEs uninstallable, even ones like Xfce far removed from Wayland.
You should be able to install from Live ISO which we are not modifying (depends on environment set by SIG owners). However, we won't support X11 together with Wayland on boot.iso. That would be hard to achieve given to the big amount of changes we are required to do now to support Wayland.
If you can't support X11 together with Wayland on boot.iso , why you want move to Wayland ? it is stupid break Linux user experience just because Wayland is fancy , what we get with Wayland that we don't get with X11 ?
Security! Maintained ...
if you need remove X11 to add Wayland, don't do it ! . Don't break the other Linux user systems . Is difficult understand that you should not remove components without agreement of everyone ?
Linux should support all kind of hardware, if Wayland don't, you should provide at least fall backs , and not just ignore the others .
+1, the user base is diverse, so should the solutions.
The removal of X11 from KDE , just because KDE SIG decide without consent of many members of Fedora which contribute to Fedora KDE , should not be acceptable .
Waste my energy discussing things that should be obvious , make me think if I still should contribute to this project.
You should - this issue is only a tiny part of the whole project. Its a great project with great people.
Like Linus says "DON'T BREAK THE USER SPACE"
Its easy to say that when walking only in kernel space.
On Tuesday 11 June 2024 14:52:19 CEST Sérgio Basto wrote:
I had enough with you an your attitude. You have been abusing the good will and temperament of many Fedora contributors for too long. Somebody must put a stop to your comments and behavior.
If you can't support X11 together with Wayland on boot.iso , why you want move to Wayland ?
The explanation to this is very clearly explained in the == Detailed Description === section
it is stupid break Linux user experience just because Wayland is fancy ,
Refrain from calling our actions or (implicitly) our contributors _stupid_
That is just not acceptable. Period.
Not to mention that nobody is breaking any user experience. Your mind is so distorted that whenever you see "Wayland" you get immediately triggered and you fight whatever is going on in the discussion.
what we get with Wayland that we don't get with X11 ?
This has been explained so many times that the fact that you keep asking this over and over and over is just making you look like somebody one cannot have a conversation with.
if you need remove X11 to add Wayland, don't do it ! .
Again, the reasoning has been explained in the == Detailed Description == section
Don't break the other Linux user systems .
Nobody is breaking anything. Stop spreading FUD.
Is difficult understand that you should not remove components without agreement of everyone ?
yes, sure, like absolutely everything in our society needs to be agreed by 100% of the people. Of course.
Do you realize how non nonsensical that sounds?
Linux should support all kind of hardware, if Wayland don't, you should provide at least fall backs , and not just ignore the others .
That is only *your* view. Please explain me why I cannot install Fedora in my AMD K6-2 or my Pentium 200 MMX (because I cannot, it is not supported anymore).
Linux should support all kind of hardware, right?
¯_(ツ)_/¯
The removal of X11 from KDE , just because KDE SIG decide without consent of many members of Fedora which contribute to Fedora KDE , should not be acceptable .
Why on earth would you bring this here? I am not sure you can understand how childish you look by doing this sort of thing.
Waste my energy discussing things that should be obvious , make me think if I still should contribute to this project .
If you ask me? Please don't. I personally do not want to deal with contributors with the attitude that you have.
Like Linus says "DON'T BREAK THE USER SPACE"
Is that supposed to mean anything? Just because the kernel maintainer says something it doesn't mean that is a rule written by the Heavens and The All Mighty and we must follow it.
(for the record, the linux kernel *has* broken userspace in the past. Just saying).
Best regards,
Marc Deop
On Tue, 2024-06-11 at 19:48 +0200, Marc Deop i Argemí wrote:
On Tuesday 11 June 2024 14:52:19 CEST Sérgio Basto wrote:
I had enough with you an your attitude. You have been abusing the good will and temperament of many Fedora contributors for too long. Somebody must put a stop to your comments and behavior.
If you can't support X11 together with Wayland on boot.iso , why you want move to Wayland ?
The explanation to this is very clearly explained in the == Detailed Description === section
it is stupid break Linux user experience just because Wayland is fancy ,
Refrain from calling our actions or (implicitly) our contributors _stupid_
I don't want that you deduce that.
OK I 'll try be more inclusive BTW I confused you with user moceap. yeah I think try removing X11 is not right path that is my opinion. And you don't have the right of remove X11 software from Fedora . You aren't adding software, you are trying removing X11 and impose Wayland because, I think, you want that people test wayland, you think if people test more, the things will be fixed by them self but I don't think that is true, see the case of btrfs , still missing core functionalities, hopefully nobody tried to remove ext4. Moreover I won't test wayland, wayland simple is not ready for me. I don't use wayland and I want maintain X11
About benefit to Fedora https://fedoraproject.org/wiki/Changes/Anaconda_As_Native_Wayland_Applicatio...
- RDP is more secure that VNC ? this is not an argument, and typically is not an honest argument. VNC works over ssh, is more light, is more quick and is better in all aspect that I can think of. So RDP is not a benefit is an escape to VNC problem .
- This change will enable removal of X11 dependencies from the Anaconda which may result in reduction of installed software ? you don't even know if reduce the installed software , so in my conclusion also is not an argument .
So zero benefits to Fedora, on other hand any old computer with a graphic where drives don't support wayland will have problems .
So is the same problem of kde-X11 and is not just me, several people already state the same.
And I'd like discuss this
That is just not acceptable. Period.
What for me is not acceptable disable kwin-x11, just because yes , and give a bunch of work to the others , everywhere forum, discourse , chat , email bugzilla, we have to explain what happened , with X11 , how reinstall X11 , so is just not me .
Not to mention that nobody is breaking any user experience. Your mind is so distorted that whenever you see "Wayland" you get immediately triggered and you fight whatever is going on in the discussion.
The problem is not Wayland , the problem is remove X11, and the x11 experience . If you enable wayland but keep X11 as fallback I hadn't any problem .
what we get with Wayland that we don't get with X11 ?
This has been explained so many times that the fact that you keep asking this over and over and over is just making you look like somebody one cannot have a conversation with.
if you need remove X11 to add Wayland, don't do it ! .
Again, the reasoning has been explained in the == Detailed Description == section
Don't break the other Linux user systems .
Nobody is breaking anything. Stop spreading FUD.
No, is not FUD, because we got this experience in Fedora 40, _all_ old nvidia drives simple don't support wayland .
Is difficult understand that you should not remove components without agreement of everyone ?
yes, sure, like absolutely everything in our society needs to be agreed by 100% of the people. Of course.
Do you realize how non nonsensical that sounds
Until a few weeks ago, there was always agreement and consensus among everyone, here in Fedora, in 20 years I don't remember any discussion like these one.
Linux should support all kind of hardware, if Wayland don't, you should provide at least fall backs , and not just ignore the others .
That is only *your* view. Please explain me why I cannot install Fedora in my AMD K6-2 or my Pentium 200 MMX (because I cannot, it is not supported anymore).
Linux should support all kind of hardware, right? ¯_(ツ)_/¯
:thumbs up:
The removal of X11 from KDE , just because KDE SIG decide without consent of many members of Fedora which contribute to Fedora KDE , should not be acceptable .
Why on earth would you bring this here? I am not sure you can understand how childish you look by doing this sort of thing.
no, that is the main problem is the removal of X11 .
Waste my energy discussing things that should be obvious , make me think if I still should contribute to this project .
If you ask me? Please don't. I personally do not want to deal with contributors with the attitude that you have.
me too , please stop your contributions to Fedora and attempts of remove X11 , you make me miss the previous maintainers a lot .
Like Linus says "DON'T BREAK THE USER SPACE"
Is that supposed to mean anything? Just because the kernel maintainer says something it doesn't mean that is a rule written by the Heavens and The All Mighty and we must follow it.
(for the record, the linux kernel *has* broken userspace in the past. Just saying).
This is a principle that means that you should avoid break things and should provide fallback
(I don't have more time)
Best regards,
On Tue, Jun 11, 2024 at 01:52:19PM +0100, Sérgio Basto wrote:
On Tue, 2024-06-04 at 14:26 +0200, Jiri Konecny wrote:
You should be able to install from Live ISO which we are not modifying (depends on environment set by SIG owners). However, we won't support X11 together with Wayland on boot.iso. That would be hard to achieve given to the big amount of changes we are required to do now to support Wayland.
If you can't support X11 together with Wayland on boot.iso , why you want move to Wayland ? it is stupid break Linux user experience just because Wayland is fancy , what we get with Wayland that we don't get with X11 ? if you need remove X11 to add Wayland, don't do it ! . Don't break the other Linux user systems . Is difficult understand that you should not remove components without agreement of everyone ?
Linux should support all kind of hardware, if Wayland don't, you should provide at least fall backs , and not just ignore the others .
Open Source software in general supports a wide variety of use cases and hardware. The role of most Linux distros, however, is NOT to provide a solution for every conceivable scenario or hardware or user.
Instead a Linux distro exists to pull together a curated set of software that best solves the set of goals their distro has. Each Linux distro will have their own priorities, and make different tradeoffs in choosing what software to provide & how to configure & use stuff they do provide.
What we're seeing here is that in Fedora, the distro priorities & goals are taking us down a path of prioritizing Wayland, over X11. This is a valid decision & direction for Fedora to choose, because it aligns with our distro mission statement, part of which is to focus on innovation.
At times some users will be left without support for things that previously worked, and thus be unhappy with the result. That is an unfortunate, but at the same time, acceptable outcome. Fedora is not trying to cater to every possible user feature demand, it is trying to optimize for its mission.
The beauty of open source is that users have a choice to distros, and can select whichever has a mission & deliverables that best satisfy the user's needs. There will be distros around that aim to support X11 with a higher priority.
With regards, Daniel
On Fri, 2024-05-31 at 08:04 -0700, Adam Williamson wrote:
On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
To my knowledge it shouldn't be. Fedora Workstation is already running on Wayland by default for quite some time and even Live ISO is already Wayland. To my knowledge Wayland don't have issues with graphics cards in general.
GNOME has a fallback mechanism where it automatically runs the X.org session if the Wayland session doesn't work. I believe that is active on the live image. Of course, as telemetry is evil, we have absolutely no idea how many Fedora users actually hit this mechanism.
TL;DR; if you may fallback to X11 , I don't have problems. If we don't have way to use X11 , is just break Linux for many users
On 31 May 2024, at 12:36, Jiri Konecny jkonecny@redhat.com wrote:
To my knowledge Wayland don't have issues with graphics cards in general.
Isn’t the nouveau driver known to have wayland support issues with some nvidia chip set generations? Sorry I am not across the detail of which chips set maybe a problem.
Lots of users end up using the rpmfusion nvidia drivers to get a working DE. See the almost daily nvidia support we handle on fedora discuss.
Barry
I'm not able to tell, I'm not involved into Wayland enough. Hi Ray, Jose do you know something about what is written below?
Jirka
On 31. 05. 24 19:16, Barry wrote:
On 31 May 2024, at 12:36, Jiri Konecny jkonecny@redhat.com wrote:
To my knowledge Wayland don't have issues with graphics cards in general.
Isn’t the nouveau driver known to have wayland support issues with some nvidia chip set generations? Sorry I am not across the detail of which chips set maybe a problem.
Lots of users end up using the rpmfusion nvidia drivers to get a working DE. See the almost daily nvidia support we handle on fedora discuss.
Barry
Aoife Moloney amoloney@redhat.com writes:
=== VNC switch to RDP for remote GUI installations ===
I'm curious how my usual install workflow will be affected by this change. I use the kickstart "vnc --connect" option extensively in my workflow; I may have a bunch of installs running in parallel, and they just connect and display when they are ready. I use vinagre as the vnc client.
It's not a huge thing; I could come up with another workflow but that's the one I've used since before Fedora existed. The installs are fully automated and the display connection is only used so that I can see the progress and potentially interact with a machine if it encounters a problem. I guess in the worst case I could just do the install blind and ssh in if something takes too long.
- J<
On 03. 06. 24 21:57, Jason L Tibbitts III wrote:
Aoife Moloney amoloney@redhat.com writes:
=== VNC switch to RDP for remote GUI installations ===
I'm curious how my usual install workflow will be affected by this change. I use the kickstart "vnc --connect" option extensively in my workflow; I may have a bunch of installs running in parallel, and they just connect and display when they are ready. I use vinagre as the vnc client.
It's not a huge thing; I could come up with another workflow but that's the one I've used since before Fedora existed. The installs are fully automated and the display connection is only used so that I can see the progress and potentially interact with a machine if it encounters a problem. I guess in the worst case I could just do the install blind and ssh in if something takes too long.
Hi, the only change should be that you will change "vnc --connect" with the new API we will provide and also use RDP as your client instead of VNC.
Best Regards, Jirka
- J<
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Tue, Jun 4, 2024 at 8:23 AM Jiri Konecny jkonecny@redhat.com wrote:
On 03. 06. 24 21:57, Jason L Tibbitts III wrote:
> Aoife Moloney amoloney@redhat.com writes:
=== VNC switch to RDP for remote GUI installations ===
I'm curious how my usual install workflow will be affected by this change. I use the kickstart "vnc --connect" option extensively in my workflow; I may have a bunch of installs running in parallel, and they just connect and display when they are ready. I use vinagre as the vnc client.
It's not a huge thing; I could come up with another workflow but that's the one I've used since before Fedora existed. The installs are fully automated and the display connection is only used so that I can see the progress and potentially interact with a machine if it encounters a problem. I guess in the worst case I could just do the install blind and ssh in if something takes too long.
Hi, the only change should be that you will change "vnc --connect" with the new API we will provide and also use RDP as your client instead of VNC.
Given that gnome-remote-desktop supports both VNC and RDP, can't VNC support still be wired up?
On 04. 06. 24 14:27, Neal Gompa wrote:
On Tue, Jun 4, 2024 at 8:23 AM Jiri Konecny jkonecny@redhat.com wrote:
On 03. 06. 24 21:57, Jason L Tibbitts III wrote:
>> Aoife Moloney amoloney@redhat.com writes:
=== VNC switch to RDP for remote GUI installations ===
I'm curious how my usual install workflow will be affected by this change. I use the kickstart "vnc --connect" option extensively in my workflow; I may have a bunch of installs running in parallel, and they just connect and display when they are ready. I use vinagre as the vnc client.
It's not a huge thing; I could come up with another workflow but that's the one I've used since before Fedora existed. The installs are fully automated and the display connection is only used so that I can see the progress and potentially interact with a machine if it encounters a problem. I guess in the worst case I could just do the install blind and ssh in if something takes too long.
Hi, the only change should be that you will change "vnc --connect" with the new API we will provide and also use RDP as your client instead of VNC.
Given that gnome-remote-desktop supports both VNC and RDP, can't VNC support still be wired up?
Hi, it is theoretically possible but we are not planning to do that until there will be a reason for that. AFAIK it's not that simple change to do that.
Jirka
On Tue, Jun 11, 2024 at 10:41 AM Jiri Konecny jkonecny@redhat.com wrote:
On 04. 06. 24 14:27, Neal Gompa wrote:
On Tue, Jun 4, 2024 at 8:23 AM Jiri Konecny jkonecny@redhat.com wrote:
On 03. 06. 24 21:57, Jason L Tibbitts III wrote:
>>> Aoife Moloney amoloney@redhat.com writes:
=== VNC switch to RDP for remote GUI installations ===
I'm curious how my usual install workflow will be affected by this change. I use the kickstart "vnc --connect" option extensively in my workflow; I may have a bunch of installs running in parallel, and they just connect and display when they are ready. I use vinagre as the vnc client.
It's not a huge thing; I could come up with another workflow but that's the one I've used since before Fedora existed. The installs are fully automated and the display connection is only used so that I can see the progress and potentially interact with a machine if it encounters a problem. I guess in the worst case I could just do the install blind and ssh in if something takes too long.
Hi, the only change should be that you will change "vnc --connect" with the new API we will provide and also use RDP as your client instead of VNC.
Given that gnome-remote-desktop supports both VNC and RDP, can't VNC support still be wired up?
Hi, it is theoretically possible but we are not planning to do that until there will be a reason for that. AFAIK it's not that simple change to do that.
I think the reason is pretty obvious: there are many more high quality VNC clients than there are RDP ones. And even ignoring that, the existing Anaconda workflows for remote GUI expect VNC. There is no technical limitation preventing us from having VNC support through grd. In fact, one of the original reasons I wrote the Weston backend for Anaconda was so that I could have VNC for Linux and web clients, because the RDP clients are not very good in my experience.
-- 真実はいつも一つ！/ Always, there's only one truth!
On 11. 06. 24 11:53, Neal Gompa wrote:
On Tue, Jun 11, 2024 at 10:41 AM Jiri Konecnyjkonecny@redhat.com wrote:
On 04. 06. 24 14:27, Neal Gompa wrote:
On Tue, Jun 4, 2024 at 8:23 AM Jiri Konecnyjkonecny@redhat.com wrote:
On 03. 06. 24 21:57, Jason L Tibbitts III wrote:
>>>> Aoife Moloneyamoloney@redhat.com writes: === VNC switch to RDP for remote GUI installations ===
I'm curious how my usual install workflow will be affected by this change. I use the kickstart "vnc --connect" option extensively in my workflow; I may have a bunch of installs running in parallel, and they just connect and display when they are ready. I use vinagre as the vnc client.
It's not a huge thing; I could come up with another workflow but that's the one I've used since before Fedora existed. The installs are fully automated and the display connection is only used so that I can see the progress and potentially interact with a machine if it encounters a problem. I guess in the worst case I could just do the install blind and ssh in if something takes too long.
Hi, the only change should be that you will change "vnc --connect" with the new API we will provide and also use RDP as your client instead of VNC.
Given that gnome-remote-desktop supports both VNC and RDP, can't VNC support still be wired up?
Hi, it is theoretically possible but we are not planning to do that until there will be a reason for that. AFAIK it's not that simple change to do that.
I think the reason is pretty obvious: there are many more high quality VNC clients than there are RDP ones. And even ignoring that, the existing Anaconda workflows for remote GUI expect VNC. There is no technical limitation preventing us from having VNC support through grd. In fact, one of the original reasons I wrote the Weston backend for Anaconda was so that I could have VNC for Linux and web clients, because the RDP clients are not very good in my experience.
In any case, I would see this more like a future improvement if we agree to go this way. I would like to simplify things for now, it's already a big change.
Anyway, Jonas, could you please share your recommendation here as owner of grd? Do you think that VNC should be enabled in grd?
Best Regards, Jirka
On Tue, Jun 11, 2024 at 4:22 PM Jiri Konecny jkonecny@redhat.com wrote:
On 11. 06. 24 11:53, Neal Gompa wrote:
On Tue, Jun 11, 2024 at 10:41 AM Jiri Konecny jkonecny@redhat.com wrote:
On 04. 06. 24 14:27, Neal Gompa wrote:
On Tue, Jun 4, 2024 at 8:23 AM Jiri Konecny jkonecny@redhat.com wrote:
On 03. 06. 24 21:57, Jason L Tibbitts III wrote:
Aoife Moloney amoloney@redhat.com writes:
=== VNC switch to RDP for remote GUI installations ===
I'm curious how my usual install workflow will be affected by this change. I use the kickstart "vnc --connect" option extensively in my workflow; I may have a bunch of installs running in parallel, and they just connect and display when they are ready. I use vinagre as the vnc client.
It's not a huge thing; I could come up with another workflow but that's the one I've used since before Fedora existed. The installs are fully automated and the display connection is only used so that I can see the progress and potentially interact with a machine if it encounters a problem. I guess in the worst case I could just do the install blind and ssh in if something takes too long.
Hi, the only change should be that you will change "vnc --connect" with the new API we will provide and also use RDP as your client instead of VNC.
Given that gnome-remote-desktop supports both VNC and RDP, can't VNC support still be wired up?
Hi, it is theoretically possible but we are not planning to do that until there will be a reason for that. AFAIK it's not that simple change to do that.
I think the reason is pretty obvious: there are many more high quality VNC clients than there are RDP ones. And even ignoring that, the existing Anaconda workflows for remote GUI expect VNC. There is no technical limitation preventing us from having VNC support through grd. In fact, one of the original reasons I wrote the Weston backend for Anaconda was so that I could have VNC for Linux and web clients, because the RDP clients are not very good in my experience.
In any case, I would see this more like a future improvement if we agree to go this way. I would like to simplify things for now, it's already a big change.
As long as the mechanism to wire things up for inst.vnc to work isn't deleted, then I think that's fine. It can be added after-the-fact and maybe even still land for F41.
On Tue, Jun 11, 2024 at 04:22:24PM +0200, Jiri Konecny wrote:
On 11. 06. 24 11:53, Neal Gompa wrote:
On Tue, Jun 11, 2024 at 10:41 AM Jiri Konecnyjkonecny@redhat.com wrote:
On 04. 06. 24 14:27, Neal Gompa wrote:
On Tue, Jun 4, 2024 at 8:23 AM Jiri Konecnyjkonecny@redhat.com wrote:
On 03. 06. 24 21:57, Jason L Tibbitts III wrote:
> > > > > Aoife Moloneyamoloney@redhat.com writes: > === VNC switch to RDP for remote GUI installations === I'm curious how my usual install workflow will be affected by this change. I use the kickstart "vnc --connect" option extensively in my workflow; I may have a bunch of installs running in parallel, and they just connect and display when they are ready. I use vinagre as the vnc client.
It's not a huge thing; I could come up with another workflow but that's the one I've used since before Fedora existed. The installs are fully automated and the display connection is only used so that I can see the progress and potentially interact with a machine if it encounters a problem. I guess in the worst case I could just do the install blind and ssh in if something takes too long.
Hi, the only change should be that you will change "vnc --connect" with the new API we will provide and also use RDP as your client instead of VNC.
Given that gnome-remote-desktop supports both VNC and RDP, can't VNC support still be wired up?
Hi, it is theoretically possible but we are not planning to do that until there will be a reason for that. AFAIK it's not that simple change to do that.
I think the reason is pretty obvious: there are many more high quality VNC clients than there are RDP ones. And even ignoring that, the existing Anaconda workflows for remote GUI expect VNC. There is no technical limitation preventing us from having VNC support through grd. In fact, one of the original reasons I wrote the Weston backend for Anaconda was so that I could have VNC for Linux and web clients, because the RDP clients are not very good in my experience.
In any case, I would see this more like a future improvement if we agree to go this way. I would like to simplify things for now, it's already a big change.
Anyway, Jonas, could you please share your recommendation here as owner of grd? Do you think that VNC should be enabled in grd?
Currently in upstream grd VNC support is implemented using LibVNCServer, and completely lacks any way of encryption. Other than that, there are awkward limitations of password lengths that may be present, depending on various factors. All in all, it's awful for security.
There are three things that would make me comfortable recommending making VNC an option:
* Changing implementation to use neatvnc instead of LibVNCServer. The impression I have is that this VNC implementation has a bit higher code quality compared to LibVNCServer. * Implement TLS key/cert based encryption and require that by default, while dropping the anontls support we have downstream in Fedora. * Remove the "prompt" authorization method from grd.
Other than that, a probably unenforcable thing would be to not allow it being exposed to the wider Internet.
Jonas
Best Regards, Jirka
Jiri Konecny jkonecny@redhat.com writes:
Hi, the only change should be that you will change "vnc --connect" with the new API we will provide and also use RDP as your client instead of VNC.
Thanks. I don't particularly care about VNC itself; I just wanted to make sure that it was known that someone does use "--connect" to do a "client-initiated" display connection.
Off topic, I know, but what I really wish existed was some kind of deployment console. Early in the kickstart process, the machine being installed would contact a server, pass hardware info and wait. The server would pass back the rest of the kickstart file (after potentially getting admin input) and the installation would continue. Output would be logged in a way that the server can present to the admin, and potentially the graphical (or perhaps the text) UI could be passed through.
Years ago I had hacked something implementing a little of this which just worked in %pre but it ended up being less useful than the system I use now. And really, I don't think that deployments like mine (maybe a couple hundred machines) are very common so there's probably no point. But it's an interesting problem to think about.
- J<
On Tue, Jun 04, 2024 at 12:08:45PM -0500, Jason L Tibbitts III wrote:
Jiri Konecny jkonecny@redhat.com writes:
Hi, the only change should be that you will change "vnc --connect" with the new API we will provide and also use RDP as your client instead of VNC.
Thanks. I don't particularly care about VNC itself; I just wanted to make sure that it was known that someone does use "--connect" to do a "client-initiated" display connection.
Off topic, I know, but what I really wish existed was some kind of deployment console. Early in the kickstart process, the machine being installed would contact a server, pass hardware info and wait. The server would pass back the rest of the kickstart file (after potentially getting admin input) and the installation would continue. Output would be logged in a way that the server can present to the admin, and potentially the graphical (or perhaps the text) UI could be passed through.
This is similar to what The Foreman does I think?
https://www.theforeman.org/introduction.html
There are various other things in the same world such as:
https://docs.openstack.org/ironic/latest/
Rich.
Years ago I had hacked something implementing a little of this which just worked in %pre but it ended up being less useful than the system I use now. And really, I don't think that deployments like mine (maybe a couple hundred machines) are very common so there's probably no point. But it's an interesting problem to think about.
- J<
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 05. 06. 24 10:05, Richard W.M. Jones wrote:
On Tue, Jun 04, 2024 at 12:08:45PM -0500, Jason L Tibbitts III wrote:
> Jiri Konecny jkonecny@redhat.com writes:
Hi, the only change should be that you will change "vnc --connect" with the new API we will provide and also use RDP as your client instead of VNC.
Thanks. I don't particularly care about VNC itself; I just wanted to make sure that it was known that someone does use "--connect" to do a "client-initiated" display connection.
Off topic, I know, but what I really wish existed was some kind of deployment console. Early in the kickstart process, the machine being installed would contact a server, pass hardware info and wait. The server would pass back the rest of the kickstart file (after potentially getting admin input) and the installation would continue. Output would be logged in a way that the server can present to the admin, and potentially the graphical (or perhaps the text) UI could be passed through.
This is similar to what The Foreman does I think?
https://www.theforeman.org/introduction.html
There are various other things in the same world such as:
https://docs.openstack.org/ironic/latest/
Rich.
IIRC Foreman is doing this by not optimal way currently and they asked us some time ago about using %pre section as you said. Not sure what happened then.
Anyway, the pre section should be fine to use for this in Anaconda.
Also a question, is kickstart command for RDP requirement for you? Or is inst.rdp (replacement of inst.vnc) enough to work with? We are trying to find out if we can drop the kickstart command.
Best Regards, Jirka
Years ago I had hacked something implementing a little of this which just worked in %pre but it ended up being less useful than the system I use now. And really, I don't think that deployments like mine (maybe a couple hundred machines) are very common so there's probably no point. But it's an interesting problem to think about.
- J<
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Jiri Konecny jkonecny@redhat.com writes:
Also a question, is kickstart command for RDP requirement for you? Or is inst.rdp (replacement of inst.vnc) enough to work with? We are trying to find out if we can drop the kickstart command.
I don't particularly care about how the functionality gets activated; in my case it's not something that would need to come in though the kickstart file. However, I could see situations where it would be useful to have that specified in the kickstart file, such as a hypothetical deployment system. It might, for example, want to direct anaconda to send the display to an appropriate place that could be proxied or recorded. That location might be complicated or variable and not necessarily something that could be baked into the boot media or typed in at boot time.
- J<
On Tue, 2024-06-04 at 12:08 -0500, Jason L Tibbitts III wrote:
Jiri Konecny jkonecny@redhat.com writes:
Hi, the only change should be that you will change "vnc --connect" with the new API we will provide and also use RDP as your client instead of VNC.
Thanks. I don't particularly care about VNC itself; I just wanted to make sure that it was known that someone does use "--connect" to do a "client-initiated" display connection.
Off topic, I know, but what I really wish existed was some kind of deployment console. Early in the kickstart process, the machine being installed would contact a server, pass hardware info and wait.
I think we already send some (configurable) identifier when talking to DHCP [0], which could be used to forward a matching kickstart to the machine. I'm not sure but we might even do something similar in the call trying to fetch the kickstart over network ?
[0] https://anaconda-installer.readthedocs.io/en/latest/boot-options.html#inst-d... Not the same thing you suggest, but close. And of course I guess one could generate specific images with Image Builder with the right kickstart baked in.
The server would pass back the rest of the kickstart file (after potentially getting admin input) and the installation would continue. Output would be logged in a way that the server can present to the admin, and potentially the graphical (or perhaps the text) UI could be passed through.
Years ago I had hacked something implementing a little of this which just worked in %pre but it ended up being less useful than the system I use now. And really, I don't think that deployments like mine (maybe a couple hundred machines) are very common so there's probably no point. But it's an interesting problem to think about.
- J<
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Tue, 2024-06-04 at 14:22 +0200, Jiri Konecny wrote:
On 03. 06. 24 21:57, Jason L Tibbitts III wrote:
> Aoife Moloney amoloney@redhat.com writes:
=== VNC switch to RDP for remote GUI installations ===
I'm curious how my usual install workflow will be affected by this change. I use the kickstart "vnc --connect" option extensively in my workflow; I may have a bunch of installs running in parallel, and they just connect and display when they are ready. I use vinagre as the vnc client.
It's not a huge thing; I could come up with another workflow but that's the one I've used since before Fedora existed. The installs are fully automated and the display connection is only used so that I can see the progress and potentially interact with a machine if it encounters a problem. I guess in the worst case I could just do the install blind and ssh in if something takes too long.
Hi, the only change should be that you will change "vnc --connect" with the new API we will provide and also use RDP as your client instead of VNC.
Does RDP support this kind of "reverse connection" mode that VNC has? https://serverfault.com/questions/1100655/is-it-possible-to-make-a-reverse-r... says not, which seems like a significant loss of functionality.
The point of the `vnc --connect` mechanism anaconda currently has is to allow remote installs to a heavily-firewalled system, by having that system connect *out* to a server running on the system from which you will run the install, instead of the other way around.
On Tue, 2024-06-04 at 11:02 -0700, Adam Williamson wrote:
On Tue, 2024-06-04 at 14:22 +0200, Jiri Konecny wrote:
On 03. 06. 24 21:57, Jason L Tibbitts III wrote:
> > Aoife Moloney amoloney@redhat.com writes:
=== VNC switch to RDP for remote GUI installations ===
I'm curious how my usual install workflow will be affected by this change. I use the kickstart "vnc --connect" option extensively in my workflow; I may have a bunch of installs running in parallel, and they just connect and display when they are ready. I use vinagre as the vnc client.
It's not a huge thing; I could come up with another workflow but that's the one I've used since before Fedora existed. The installs are fully automated and the display connection is only used so that I can see the progress and potentially interact with a machine if it encounters a problem. I guess in the worst case I could just do the install blind and ssh in if something takes too long.
Hi, the only change should be that you will change "vnc --connect" with the new API we will provide and also use RDP as your client instead of VNC.
Does RDP support this kind of "reverse connection" mode that VNC has? https://serverfault.com/questions/1100655/is-it-possible-to-make-a-reverse-r... says not, which seems like a significant loss of functionality.
Yeah, I don't think this is really a thing in the RDP world as far as I can tell.
Also, we are using GNOME remote desktop to provide the RDP access & its remote desktop control tool (grdctl) does not seem to provide a way to configure something like that:
https://www.mankier.com/1/grdctl
For the record, it does not seem to support the VNC connect mode as as well.
I'm also not sure how well is VNC actually supported in GNOME remote desktop, as IIRC it is not even exposed as an option in modern Fedora Workstation options page - only RDP can be configured from there.
The point of the `vnc --connect` mechanism anaconda currently has is to allow remote installs to a heavily-firewalled system, by having that system connect *out* to a server running on the system from which you will run the install, instead of the other way around. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Fri, 2024-06-07 at 13:19 +0200, mkolman@redhat.com wrote:
Does RDP support this kind of "reverse connection" mode that VNC has? https://serverfault.com/questions/1100655/is-it-possible-to-make-a-reverse-r... says not, which seems like a significant loss of functionality.
Yeah, I don't think this is really a thing in the RDP world as far as I can tell.
Also, we are using GNOME remote desktop to provide the RDP access & its remote desktop control tool (grdctl) does not seem to provide a way to configure something like that:
https://www.mankier.com/1/grdctl
For the record, it does not seem to support the VNC connect mode as as well.
I'm also not sure how well is VNC actually supported in GNOME remote desktop, as IIRC it is not even exposed as an option in modern Fedora Workstation options page - only RDP can be configured from there.
Well, all you need is any VNC app, and there are lots of those. For the openQA tests we use vinagre for the regular client test and tigervnc for the reverse connection test. GNOME Connections supports regular VNC, I just didn't get around to changing that test to use it yet.
On Fri, Jun 7, 2024 at 8:32 AM Adam Williamson adamwill@fedoraproject.org wrote:
On Fri, 2024-06-07 at 13:19 +0200, mkolman@redhat.com wrote:
Does RDP support this kind of "reverse connection" mode that VNC has? https://serverfault.com/questions/1100655/is-it-possible-to-make-a-reverse-r... says not, which seems like a significant loss of functionality.
Yeah, I don't think this is really a thing in the RDP world as far as I can tell.
Also, we are using GNOME remote desktop to provide the RDP access & its remote desktop control tool (grdctl) does not seem to provide a way to configure something like that:
https://www.mankier.com/1/grdctl
For the record, it does not seem to support the VNC connect mode as as well.
I'm also not sure how well is VNC actually supported in GNOME remote desktop, as IIRC it is not even exposed as an option in modern Fedora Workstation options page - only RDP can be configured from there.
Well, all you need is any VNC app, and there are lots of those. For the openQA tests we use vinagre for the regular client test and tigervnc for the reverse connection test. GNOME Connections supports regular VNC, I just didn't get around to changing that test to use it yet.
Note that gnome-remote-desktop supports VNC. It can be configured using the grdctl commandline tool.
I am owner of MATE desktop spin. Will anconda run on a x11 desktop (liveCD) ? Mate wayland support is highly experimental and far away from a production state to use as desktop for fedora. When anconda won't run on x11 it isn't possible to install MATE desktop from the spin, in result this breaks the Mate-Compiz spin.
Btw. what is the reason to do that beside from dependencies? Does anaconda have serious issues with x11? I hope you don't do that.
regards Wolfgang
Btw. Why not splitting anconda RPM in a main part which support only wayland with a new sub package for X11? Than you can reduce package size for workstation and desktops which are ready for wayland. In my opinion this is way to go to support X11 desktops until X11 itself is obsolete.
Wolfgang
On Tue, Jul 9, 2024 at 2:49 PM Wolfgang Ulbrich fedora@raveit.de wrote:
Btw. Why not splitting anconda RPM in a main part which support only wayland with a new sub package for X11? Than you can reduce package size for workstation and desktops which are ready for wayland. In my opinion this is way to go to support X11 desktops until X11 itself is obsolete.
Anaconda will still start as an X11 application for X11 live environments, so the impact on MATE is minimal.
On Tue, 2024-07-09 at 20:53 -0400, Neal Gompa wrote:
On Tue, Jul 9, 2024 at 2:49 PM Wolfgang Ulbrich fedora@raveit.de wrote:
Btw. Why not splitting anconda RPM in a main part which support only wayland with a new sub package for X11? Than you can reduce package size for workstation and desktops which are ready for wayland. In my opinion this is way to go to support X11 desktops until X11 itself is obsolete.
Anaconda will still start as an X11 application for X11 live environments, so the impact on MATE is minimal.
Exactly - its just the boot.iso/netinst image that is switching directly from X11 to Wayland.
For all the Live image spins, Anaconda still runs like a regular GTK3 application - if the spin uses X11, Anaconda (or rathher GTK I guess ?) will run as an X11 application. If the spin uses Wayland, then I guess it will run as native Wayland client if possible.
To only change that could impact spins is that we would ideally like to drop the X11-only libXklavier library we have used for keaboard handling so far and replace it with the universal localed keyboard handling API. IIRC Jiri Konecny already notified all spin owners and started some discussions about this.
In an ideal case all the spins add support for the localed API & we can drop libXklvaier. If this turns out to not be possible in the given time frame, we have some workaround available (using a keyboard handling helper script or keeping libXklavier in a limited role).
-- 真実はいつも一つ！/ Always, there's only one truth!
On Wed, Jul 10, 2024 at 8:16 AM mkolman@redhat.com wrote:
On Tue, 2024-07-09 at 20:53 -0400, Neal Gompa wrote:
On Tue, Jul 9, 2024 at 2:49 PM Wolfgang Ulbrich fedora@raveit.de wrote:
Btw. Why not splitting anconda RPM in a main part which support only wayland with a new sub package for X11? Than you can reduce package size for workstation and desktops which are ready for wayland. In my opinion this is way to go to support X11 desktops until X11 itself is obsolete.
Anaconda will still start as an X11 application for X11 live environments, so the impact on MATE is minimal.
Exactly - its just the boot.iso/netinst image that is switching directly from X11 to Wayland.
For all the Live image spins, Anaconda still runs like a regular GTK3 application - if the spin uses X11, Anaconda (or rathher GTK I guess ?) will run as an X11 application. If the spin uses Wayland, then I guess it will run as native Wayland client if possible.
To only change that could impact spins is that we would ideally like to drop the X11-only libXklavier library we have used for keaboard handling so far and replace it with the universal localed keyboard handling API. IIRC Jiri Konecny already notified all spin owners and started some discussions about this.
In an ideal case all the spins add support for the localed API & we can drop libXklvaier. If this turns out to not be possible in the given time frame, we have some workaround available (using a keyboard handling helper script or keeping libXklavier in a limited role).
It is probably possible to create a helper application to do the same thing that we do in KWin and Sway for X11 environments.
-- 真実はいつも一つ！/ Always, there's only one truth!
mkolman@redhat.com wrote:
To only change that could impact spins is that we would ideally like to drop the X11-only libXklavier library we have used for keaboard handling so far and replace it with the universal localed keyboard handling API. IIRC Jiri Konecny already notified all spin owners and started some discussions about this.
Unfortunately, the "universal localed keyboard handling API" is not as universal as your wording appears to imply. At least, not yet. Historically, the API was primarily intended to set the systemwide default locale and the systemwide default keyboard layout, requiring a reboot to apply. So getting the changes picked up in real time is something the desktop has to support explicitly. (And that support may also have to be enabled explicitly, e.g., KWin requires the --locale1 option.)
I also wonder how this is expected to work in a multi-user setup (where some users may want to use different locale, keyboard layout, etc. settings than the system default), though in the context of installation, that is probably a non-issue.
This of course also affects installers other than Anaconda, e.g., see also the discussion under: https://github.com/calamares/calamares/pull/2180
Kevin Kofler
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.
Best Regards, Jirka
On 31. 05. 24 10:34, Aoife Moloney wrote:
Wiki - https://fedoraproject.org/wiki/Changes/Anaconda_As_Native_Wayland_Applicatio... Discussion Thread - https://discussion.fedoraproject.org/t/f41-change-proposal-anaconda-as-nativ...
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.
== 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.
== Owner ==
- Name: Anaconda team ([[User:jkonecny| Jiří Konečný]])
- Email: jkonecny@redhat.com
== 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 https://bugzilla.redhat.com/show_bug.cgi?id=1955025 ) 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.
=== 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).
=== 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 https://bugzilla.redhat.com/show_bug.cgi?id=2016613 ). 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:
- https://pagure.io/fedora-workstation/issue/430
- https://pagure.io/fedora-kde/SIG/issue/504
- https://gitlab.com/fedora/sigs/sway/SIG/-/issues/36
- https://bugzilla.redhat.com/show_bug.cgi?id=2278655
- https://bugzilla.redhat.com/show_bug.cgi?id=2278658
- https://bugzilla.redhat.com/show_bug.cgi?id=2278656
- https://bugzilla.redhat.com/show_bug.cgi?id=2278864
- https://bugzilla.redhat.com/show_bug.cgi?id=2278866
- https://bugzilla.redhat.com/show_bug.cgi?id=2278869
- https://bugzilla.redhat.com/show_bug.cgi?id=2278874
- https://pagure.io/fedora-cosmic/SIG/issue/1
- https://pagure.io/fedora-budgie/project/issue/4
- https://pagure.io/fedora-lxqt/SIG/issue/4
- https://pagure.io/i3-sig/Fedora-i3-Spin/issue/70
== 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.
== 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 .
== 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: [https://pagure.io/releng/issue/12138 #12138]
Policies and guidelines: Yes should be done after the implementation
(https://docs.fedoraproject.org/en-US/fedora-server/installation/interactive-... should switch to RDP)
Trademark approval: N/A (not needed for this Change)
Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
This will impact only Fedora installations so no compatibility or upgrade issues.
== Early Testing (Optional) ==
We will reach Fedora QE to coordinate testing approach.
== How To Test ==
# Download any installation media # Run the installation # 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
== User Experience ==
The only visible change to a 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.
== Dependencies ==
No dependencies of this package related to this change.
== Contingency Plan ==
- Contingency mechanism: Postpone this change to the next Fedora
release. Revert landed changes in Anaconda if required.
- Contingency deadline: 100% code completion deadline
- Blocks release? No
== Documentation ==
No documentation yet. However, there are a few PRs ready for merge for CentOS Stream 10:
- https://github.com/rhinstaller/anaconda/pull/5463
- https://github.com/rhinstaller/anaconda/pull/5470
- https://github.com/rhinstaller/anaconda/pull/5485
- https://github.com/rhinstaller/anaconda/pull/5498
== Release Notes ==
TBD
Hi,
I'm thinking about starting a project to enable the new keyboard switching solution on X11 based systems. However, I wanted to be sure that no-one already done that or started the effort.
If someone knows about such a project please tell me.
Best Regards, Jirka
On 31. 05. 24 10:34, Aoife Moloney wrote:
Wiki - https://fedoraproject.org/wiki/Changes/Anaconda_As_Native_Wayland_Applicatio... Discussion Thread - https://discussion.fedoraproject.org/t/f41-change-proposal-anaconda-as-nativ...
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.
== 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.
== Owner ==
- Name: Anaconda team ([[User:jkonecny| Jiří Konečný]])
- Email: jkonecny@redhat.com
== 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 https://bugzilla.redhat.com/show_bug.cgi?id=1955025 ) 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.
=== 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).
=== 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 https://bugzilla.redhat.com/show_bug.cgi?id=2016613 ). 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:
- https://pagure.io/fedora-workstation/issue/430
- https://pagure.io/fedora-kde/SIG/issue/504
- https://gitlab.com/fedora/sigs/sway/SIG/-/issues/36
- https://bugzilla.redhat.com/show_bug.cgi?id=2278655
- https://bugzilla.redhat.com/show_bug.cgi?id=2278658
- https://bugzilla.redhat.com/show_bug.cgi?id=2278656
- https://bugzilla.redhat.com/show_bug.cgi?id=2278864
- https://bugzilla.redhat.com/show_bug.cgi?id=2278866
- https://bugzilla.redhat.com/show_bug.cgi?id=2278869
- https://bugzilla.redhat.com/show_bug.cgi?id=2278874
- https://pagure.io/fedora-cosmic/SIG/issue/1
- https://pagure.io/fedora-budgie/project/issue/4
- https://pagure.io/fedora-lxqt/SIG/issue/4
- https://pagure.io/i3-sig/Fedora-i3-Spin/issue/70
== 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.
== 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 .
== 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: [https://pagure.io/releng/issue/12138 #12138]
Policies and guidelines: Yes should be done after the implementation
(https://docs.fedoraproject.org/en-US/fedora-server/installation/interactive-... should switch to RDP)
Trademark approval: N/A (not needed for this Change)
Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
This will impact only Fedora installations so no compatibility or upgrade issues.
== Early Testing (Optional) ==
We will reach Fedora QE to coordinate testing approach.
== How To Test ==
# Download any installation media # Run the installation # 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
== User Experience ==
The only visible change to a 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.
== Dependencies ==
No dependencies of this package related to this change.
== Contingency Plan ==
- Contingency mechanism: Postpone this change to the next Fedora
release. Revert landed changes in Anaconda if required.
- Contingency deadline: 100% code completion deadline
- Blocks release? No
== Documentation ==
No documentation yet. However, there are a few PRs ready for merge for CentOS Stream 10:
- https://github.com/rhinstaller/anaconda/pull/5463
- https://github.com/rhinstaller/anaconda/pull/5470
- https://github.com/rhinstaller/anaconda/pull/5485
- https://github.com/rhinstaller/anaconda/pull/5498
== Release Notes ==
TBD
Thanks a lot, i've no idea to do that for myself for MATE desktop. So please go a head.
Wolfgang
Hi just for update. I've created the script and it seems to be working correctly.
https://github.com/rhinstaller/localed-x11-sync
Now, I need: - create a user systemd service - package that to Fedora - enable this package in livesys-scripts on fedora-kickstarts
Best Regards, Jirka
On 17. 09. 24 21:55, Wolfgang Ulbrich wrote:
Thanks a lot, i've no idea to do that for myself for MATE desktop. So please go a head.
Wolfgang
-
Adam Williamson -
Aoife Moloney -
Barry -
Daniel P. Berrangé -
Hans de Goede -
Ian Laurie -
Jason L Tibbitts III -
Jiri Konecny -
Jonas Ådahl -
Kevin Kofler -
Leon Fauster -
Leslie Satenstein -
Marc Deop i Argemí -
Michael J Gruber -
mkolman＠redhat.com -
Neal Gompa -
Richard W.M. Jones -
Sérgio Basto -
Vitaly Zaitsev -
Wolfgang Ulbrich -
Wolfgang Ulbrich