#395 Evaluate our X11 session offering
Closed: Deferred to upstream 6 months ago by catanzaro. Opened 8 months ago by aday.

Wayland has been our default session for a long time and has matured considerably. At the same time, the X11 session isn't getting as much testing, and is an additional resource burden.

It would therefore be good to have an exploratory conversation about whether we want to make any changes with regards to the X11 session. Options that we could consider include:

  • Hide the X11 session by default, so that fewer people use it.
  • Remove the X11 session file. Users would be able to add it back and use it as an unsupported configuration.
  • Build GNOME components (e.g. mutter/gnome-shell/gnome-session) without X11 support. Technically, users could recompile those packages themselves.

These changes would only affect GNOME and the session. Apps would still be able to use X11 through Xwayland.

Note that there is currently no anticipated time frame or schedule around this discussion or its outcomes. Additionally, no decisions will be made without getting advice from the relevant maintainers and domain experts.


Is it possible to compile gnome-session and mutter without the X11 session yet?

Is it possible to compile gnome-session and mutter without the X11 session yet?

@bilelmoussaoui was working on this, so he might know the current state

Is it possible to compile gnome-session and mutter without the X11 session yet?

@bilelmoussaoui was working on this, so he might know the current state

The mutter bits are slowly falling into place, hopefully we can get most if not all of it in GNOME 46. I have no idea about gnome-session though

If GNOME 46 is able to be compiled without X.Org, would this mean the X session will be dropped in Fedora 40? I ask because the KDE SIG plans to also drop X11 in Fedora 40 (with Plasma 6). Would it be better to have the two major desktop versions of Fedora drop X11 at the same time?

If GNOME 46 is able to be compiled without X.Org, would this mean the X session will be dropped in Fedora 40? I ask because the KDE SIG plans to also drop X11 in Fedora 40 (with Plasma 6). Would it be better to have the two major desktop versions of Fedora drop X11 at the same time?

I don't think it really makes any difference.

Dropping the X session just required dropping a text file. It is not necessary to purge X11 dependencies from the whole stack at the same time.

I do have a reason for why I still need X.Org:

https://odysee.com/@GraysonPeddie:6/gnome-mag-obs:5

I did file a bug report on Pipewire, Mutter (Gitlab), and Ubuntu Launchpad and I do not have any traction and I have decided not to file a bug on Fedora because I decided to give up. And I don't think filing a bug against OBS makes any sense.

I need to be able to use a GNOME Magnifier along with OBS because of my visual disability. Is there anything I can do moving forward so that X.org can be dropped?

The video playback on this website seems really buggy so I've given up on trying to watch your video. Can you paste links to your bug reports please?

The video playback on this website seems really buggy so I've given up on trying to watch your video. Can you paste links to your bug reports please?

That was uncalled for. It was pretty easy to find @graysonpeddie's issues.

I see there was a link to the pipewire issue if I expand the description of the video, and from that issue further links to the mutter and Ubuntu issues. Anyway, the bug reports look good. I'll try to increase visibility of the mutter issue.

Aside: I think the problem with odysee.com is a WebKit bug, reported here. That video is taking down networking in all browser tabs. :)

I think that ultimately, it makes sense to drop X11. I'm not in a position to say whether or not now is the right time, but if X11 support is draining development time whilst Wayland works perfectly well if not better for the vast majority of users then it definitely becomes hard to justify keeping X going.

On a personal note, I have been using Fedora with Wayland for a long while, across many devices from a fairly high end PC right down to some ancient ThinkPads and I have not had any issues for a good 6 months, and even then those issues have been minor enough the average user likely wouldn't notice or care.

Since OBS Studio is now packaged in Fedora, we can create a test case for @graysonpeddie's issue for reproducing and fixing it.

Support this as it should encourage everyone to port to wayland for stuff that can't work with Xwayland. It also reduces the test burden and maybe in the future allow not installing X11 - deps which could reduce the attack surface. I will even argue that should be an opt-out way to disable Xwayland for testing.
But looking at comments from others due to the announcement from the KDE spin announcement, I don't think we should make impossible to use X11 with either GNOME or KDE (at least one as I don't think other DEs are good enough replacement for those people). I think we could split package instead and drop X11 from default install. The user if they want could still dnf install it. We can then wait for 2 releases and revisit it. I just don't want people dropping fedora due lack of X11 support.

I think we could split package instead and drop X11 from default install.

The packages have been split for years already. There are a surprising number of people who have not realized that we actually have no default path in which we use X11 anymore. Even basic graphics mode uses Wayland now.

I see there was a link to the pipewire issue if I expand the description of the video, and from that issue further links to the mutter and Ubuntu issues. Anyway, the bug reports look good. I'll try to increase visibility of the mutter issue.

So I got in touch with a mutter developer who also works on OBS, but unfortunately he wasn't able to reproduce the issue.

We don't currently have a good alternative to XDMCP for people who need that sort of thing. that's blocking on this landing:

https://gitlab.gnome.org/GNOME/gdm/-/merge_requests/180

(though it should be landing early in the GNOME 46 development cycle)

We also don't offer wayland with vendor nvidia driver in some configurations. I believe we get the configuration right for rpm install, but its not right out of the box for people installing from nvidia.com. So there is some chance this will lead to systems breaking when they install vendor nvidia driver.

Still worth doing, imo, but it might go over a little rocky

I see there was a link to the pipewire issue if I expand the description of the video, and from that issue further links to the mutter and Ubuntu issues. Anyway, the bug reports look good. I'll try to increase visibility of the mutter issue.

So I got in touch with a mutter developer who also works on OBS, but unfortunately he wasn't able to reproduce the issue.

May I ask what is their system configuration? It may have something to do with the GPU, but I cannot be certain if they use GNOME Magnifier or not.

We should aim for this with GNOME 46 / Fedora 40.

Metadata Update from @ngompa:
- Issue set to the milestone: Fedora 40

8 months ago

I see there was a link to the pipewire issue if I expand the description of the video, and from that issue further links to the mutter and Ubuntu issues. Anyway, the bug reports look good. I'll try to increase visibility of the mutter issue.

So I got in touch with a mutter developer who also works on OBS, but unfortunately he wasn't able to reproduce the issue.

May I ask what is their system configuration? It may have something to do with the GPU, but I cannot be certain if they use GNOME Magnifier or not.

An important detail that's mentioned only in the Ubuntu issue is that @graysonpeddie is running on an NVIDIA GeForce RTX 3060 Ti. Presumably this is with the NVIDIA proprietary driver. Once the new patches for nouveau land, we should see if we can turn on the new behavior for Turing and Ampere cards by default in Fedora too. That may resolve the issue.

This comment is not meant to oppose this issue, but to ask for a stay of removing X11 support from mutter/Gnome.

Two use cases that still require X11:
- NVIDIA GPU controls, including fan controls
- 10-bit color, while supported by Wayland, is not yet supported by Gnome (see: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1756 and it's handful of other linked issues)

An important detail that's mentioned only in the Ubuntu issue is that @graysonpeddie is running on an NVIDIA GeForce RTX 3060 Ti. Presumably this is with the NVIDIA proprietary driver. Once the new patches for nouveau land, we should see if we can turn on the new behavior for Turing and Ampere cards by default in Fedora too. That may resolve the issue.

I probably should have mentioned in the Ubuntu bug report that I have updated to GeForce RTX 4070 a couple of months ago as I was having some computer problems and it turns I had to change out my motherboard (I don't want to go too far off topic in this discussion thread). Honestly I am not sure if it's the proprietary GPU driver is the problem or not. No wonder why my bug report felt a bit incomplete... Oh, well.

The reason why I needed an NVIDIA GPU is for CUDA/OptiX support so I can use Blender for 3D modelling.

Unfortunately if you need the NVIDIA proprietary driver, then you probably need to put that information in the GNOME ticket so that it can be correctly triaged and create a post on the NVIDIA forums so that NVIDIA will do something about it.

Mutter doesn't support DRM leasing under Wayland, which is needed for using VR headsets [1]. If the Gnome X11 session is not available, VR users will need to use a different Wayland compositor like KDE Plasma or a wlroots-based compositor.

[1] https://gitlab.gnome.org/GNOME/mutter/-/issues/1743

At this time, we don't have any VR hardware or software to use/test, so stuff like this is difficult for us.

That being said, there appears to be a merge request to add support to mutter in the works: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3205

At this time, we don't have any VR hardware or software to use/test, so stuff like this is difficult for us.

I understand, which is why I wanted to point out the missing feature in Mutter so that you're aware of it before deciding to remove the X11 session.

That being said, there appears to be a merge request to add support to mutter in the works: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3205

Mutter maintainers have indicated (in the above bug report) that they don't intend to support DRM leasing using the same mechanism as other compositors, which is what that patch adds. They would prefer to use portals instead; the effort to standardize such a portal is being tracked in [1]. But it will take time to build consensus around the API, implement it, and have it supported by non-Gnome compositors and VR software.

[1] https://github.com/flatpak/xdg-desktop-portal/issues/953

Wayland has been our default session for a long time and has matured considerably. At the same time, the X11 session isn't getting the testing it needs, and is an additional resource burden.

Maybe it's time to drop the X11 session?

No, it's not time to drop the X11 session.

Screen recording, e. g. for screencasts, educational videos, etc does not work on Wayland. It drops frames like crazy so videos are useless. X11 seems to be the only way to record your desktop. Please do not drop X11, some of us depend on it on a daily basis to do our job.

Wayland has been our default session for a long time and has matured considerably. At the same time, the X11 session isn't getting the testing it needs, and is an additional resource burden.

Maybe it's time to drop the X11 session?

No, it's not time to drop the X11 session.

Screen recording, e. g. for screencasts, educational videos, etc does not work on Wayland. It drops frames like crazy so videos are useless. X11 seems to be the only way to record your desktop. Please do not drop X11, some of us depend on it on a daily basis to do our job.

This is an interesting aberration as we've mostly gotten feedback that screencasting and recording is smoother and more performant since the move to PipeWire as the backend for this stuff.

I myself regularly stream/record using OBS on KDE Plasma Wayland (and occasionally on GNOME Wayland) and I've noticed it's much smoother than the X11 counterpart.

If you've got a specific configuration and an issue, can you please file a bug about it?

At this time, we don't have any VR hardware or software to use/test, so stuff like this is difficult for us.

I understand, which is why I wanted to point out the missing feature in Mutter so that you're aware of it before deciding to remove the X11 session.

That being said, there appears to be a merge request to add support to mutter in the works: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3205

Mutter maintainers have indicated (in the above bug report) that they don't intend to support DRM leasing using the same mechanism as other compositors, which is what that patch adds. They would prefer to use portals instead; the effort to standardize such a portal is being tracked in [1]. But it will take time to build consensus around the API, implement it, and have it supported by non-Gnome compositors and VR software.

[1] https://github.com/flatpak/xdg-desktop-portal/issues/953

It does not appear to be a consensus that a portal needs to be made for GNOME to support it. The objection seems to be coming from a single person. I think we're going to need a separate ticket to track VR support, as this is a significant separate issue that we will have to drive upstream to do something about.

Wayland has been our default session for a long time and has matured considerably. At the same time, the X11 session isn't getting the testing it needs, and is an additional resource burden.

Maybe it's time to drop the X11 session?

No, it's not time to drop the X11 session.

Screen recording, e. g. for screencasts, educational videos, etc does not work on Wayland. It drops frames like crazy so videos are useless. X11 seems to be the only way to record your desktop. Please do not drop X11, some of us depend on it on a daily basis to do our job.

This is an interesting aberration as we've mostly gotten feedback that screencasting and recording is smoother and more performant since the move to PipeWire as the backend for this stuff.

I myself regularly stream/record using OBS on KDE Plasma Wayland (and occasionally on GNOME Wayland) and I've noticed it's much smoother than the X11 counterpart.

If you've got a specific configuration and an issue, can you please file a bug about it?

I'm afraid it's not an aberration.

This has happeend RHEL 8 CSB, Fedora 36-38 and Fedora KDE 36 (and maybe 37 too, I can't remember for sure) on a Lenovo P1 Gen3 with Intel graphics. Intel modules are loaded and yadda yadda. OBS (and any other screen recording software I tried) drops just too many frames so ultimatey I had to move to X11.

IMHO Wayland is not yet ready and it fails in some aspects that affect my daily job.

Wayland has been our default session for a long time and has matured considerably. At the same time, the X11 session isn't getting the testing it needs, and is an additional resource burden.

Maybe it's time to drop the X11 session?

No, it's not time to drop the X11 session.

Screen recording, e. g. for screencasts, educational videos, etc does not work on Wayland. It drops frames like crazy so videos are useless. X11 seems to be the only way to record your desktop. Please do not drop X11, some of us depend on it on a daily basis to do our job.

This is an interesting aberration as we've mostly gotten feedback that screencasting and recording is smoother and more performant since the move to PipeWire as the backend for this stuff.

I myself regularly stream/record using OBS on KDE Plasma Wayland (and occasionally on GNOME Wayland) and I've noticed it's much smoother than the X11 counterpart.

If you've got a specific configuration and an issue, can you please file a bug about it?

I'm afraid it's not an aberration.

This has happeend RHEL 8 CSB, Fedora 36-38 and Fedora KDE 36 (and maybe 37 too, I can't remember for sure) on a Lenovo P1 Gen3 with Intel graphics. Intel modules are loaded and yadda yadda. OBS (and any other screen recording software I tried) drops just too many frames so ultimatey I had to move to X11.

IMHO Wayland is not yet ready and it fails in some aspects that affect my daily job.

I used to have a Lenovo P1 Gen 3. I actually know what you're talking about, unfortunately.

The solution to the problem is to enable hardware accelerated encoding for the Intel media engine by default, but we can't until the package review clears legal...

Hi!
Please do not kill the Cinnamon desktop! I use it. :)
(don't break userspace, someone said once)

Hi!
Please do not kill the Cinnamon desktop! I use it. :)
(don't break userspace, someone said once)

Do you know if Cinnamon has a Wayland roadmap? If it is something they are working on it might not be as much of a problem, but as there is a Cinnamon spin it is important we do not break it.

Please do not kill the Cinnamon desktop! I use it. :)

Note that this ticket is just about dropping the X11 session in GNOME

(don't break userspace, someone said once)

Please be aware that the "don't break userspace" is a completely different thing than what you mean here. This has nothing to do with the userspace/kernel space divide and how that needs to be kept stable

Note that 10bpc colors are on their way to land in GNOME 46 as part of https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3139 ; it was just too late to still get this in for GNOME 45 / Fedora 39

Hi!
Please do not kill the Cinnamon desktop! I use it. :)
(don't break userspace, someone said once)

Do you know if Cinnamon has a Wayland roadmap? If it is something they are working on it might not be as much of a problem, but as there is a Cinnamon spin it is important we do not break it.

I have collected some articles. I dove into this multiple times, what I remember:
The developers have no interest in rewriting everything, because that is a lot of work, and they are not with many.
There is a (now apparently resolved) dependency on muffin be ported to wayland.

It appears not to be the highest of their priorities.
A ticket opened in 2016, as old as it was reported:
https://github.com/linuxmint/cinnamon/issues/5201

A developer on the issue in 2019:
I have absolutely zero interest in a protocol that has so many shortcomings.
https://github.com/linuxmint/cinnamon/issues/8512#issuecomment-482975669

most recent formal message I could find 2022:
https://github.com/linuxmint/cinnamon/issues/10787#issuecomment-1179489222
TLDR Wayland isn't ready, and I personally wouldn't expect significant motion on this in the near future.

Dropping the X session just required dropping a text file. It is not necessary to purge X11 dependencies from the whole stack at the same time.

I guess this is maybe something we should think about: what do we mean exactly with "dropping the X11 session in GNOME". It could be

  • We hide the X11 session by default, so even less users come into contact with the X11 session
  • We remove the X11 session file. An end user could add it back, but it would be a manual action and would go into an unsupported configuration.
  • We build several parts (e.g. mutter/gnome-shell/gnome-session) without X11 support. Technically, an end user could recompile those packages themselves and be even more outside of the realm of support

Note that all of this is still separate from any discussion on the future of the Xorg server package in general (and why it make little sense for Cinnamon users to put up Cinnamon's non Wayland support as a blocker here)

Please do not kill the Cinnamon desktop! I use it. :)

Note that this ticket is just about dropping the X11 session in GNOME

It is for me not clear what the implications of this are, so I report it. What are the implications? Are applications not compiled with the X-extentions, meaning I cannot start any Gnome application anymore? I do not know, I thus I report.

(don't break userspace, someone said once)

Please be aware that the "don't break userspace" is a completely different thing than what you mean here. This has nothing to do with the userspace/kernel space divide and how that needs to be kept stable

I think you are missing an import, please check if 'joke' is loaded.

@heidistein

It is for me not clear what the implications of this are, so I report it. What are the implications?

I understand that you might be fearful about what's being discussed here, and your concerns have been noted.

At the same time, please bear in mind that this is an issue tracker - it is not an appropriate place for developers to explain all the technical details (I'm sure that they'd be happy to do so elsewhere).

Also, you don't need to panic - this is an exploratory conversation and we are not going to quickly make a decision without it being discussed more widely.

I think you are missing an import, please check if 'joke' is loaded.

It wasn't clear to me that you were making a joke, either. Let's just stick to the issues at hand! :smile:

@heidistein Cinnamon's ability to move to Wayland is predicated on them rebasing Muffin to the latest Mutter code. They are currently at Mutter 3.36, which is quite far behind: https://github.com/linuxmint/muffin

The decisions made by Fedora Workstation do not necessarily impact Cinnamon because GNOME's mutter package is not the same as Cinnamon's muffin package.

Please pardon me for an off-topic question but has anyone tried visiting [1]? I tried to check in my bug report for Mutter [2] and I am getting an error message saying that the application is not available. I hope I'm not the only one seeing an error message.

[1] https://gitlab.gnome.org/
[2] https://gitlab.gnome.org/GNOME/mutter/-/issues/2698

GNOME infrastructure has a major outage: https://status.gnome.org/

Please try and avoid off-topic comments everyone - thanks!

If we continue to get a lot of chat, this issue will become useless and we'll have to close it.

Dropping the X session just required dropping a text file. It is not necessary to purge X11 dependencies from the whole stack at the same time.

I guess this is maybe something we should think about: what do we mean exactly with "dropping the X11 session in GNOME". It could be

  • We hide the X11 session by default, so even less users come into contact with the X11 session
  • We remove the X11 session file. An end user could add it back, but it would be a manual action and would go into an unsupported configuration.
  • We build several parts (e.g. mutter/gnome-shell/gnome-session) without X11 support. Technically, an end user could recompile those packages themselves and be even more outside of the realm of support

Note that all of this is still separate from any discussion on the future of the Xorg server package in general (and why it make little sense for Cinnamon users to put up Cinnamon's non Wayland support as a blocker here)

I think we should aim for option 3, but option 2 can be done if we can't get 3 done.

Please note that a number of issues still exist when running the proprietary NVIDIA driver with Wayland:
https://download.nvidia.com/XFree86/Linux-x86_64/535.104.05//README/wayland-issues.html
In particular, I am affected by the following:
- night light is not working due to missing GAMMA_LUT [1][2]
- EGL falling back to software rendering [3]
- mame window blinking when running in a vulkan window (not reported yet as I do not have a simple test case)

I am aware that this is a chicken-and-egg problem: if X11 never goes away, the motivation to fix remaining issues will remain low. Having said that, I am not sure how much I would be inclined to continue using Fedora if I still have an nvidia card in my machine by the time F40 gets released. My laptop already has an AMD card in it.

[1] https://gitlab.gnome.org/GNOME/mutter/-/issues/290
[2] https://forums.developer.nvidia.com/t/gnome-night-light-not-working-under-wayland/193590
[3] https://forums.developer.nvidia.com/t/hardware-egl-not-working-on-wayland-libegl-warning-egl-failed-to-create-dri2-screen/262167

My usage of Xorg is because of a single game through Wine.

The game is Old School Runescape (OSRS) and if I run it on GNOME on Wayland on Fedora 38:

  1. Most of the time the Jagex Launcher window doesn't appear automatically, and requires a seemingly random amount of double-clicking to make it either flash a black window briefly, or finally appear (it takes 10 seconds of clicking in this video https://youtu.be/NFDe9AVVlxo?si=eiMbvJvRmYeBgMiq&t=155 around 02:40 to 02:50) (this doesn't seem to be an issue anymore)

  2. With the OSRS game client window up, it gets locked to around 40-50 FPS, regardless of the in-game setting being Unlimited

The launcher window appearing isn't a problem from GNOME on Xorg; it appears immediately, first-time, rendered and ready to go always.

The FPS limiting issue doesn't happen on GNOME on Xorg and FPS; FPS at unlimited goes to 100+, and vblank_mode=3 caps in-game FPS reporting to refresh rate.

The FPS limiting issue can seemingly be worked-around by forcing Zink and immediate WSI modes. I don't recall specifically but there was something about the other WSI modes and Vsync that just didn't seem to work ideally, so I chose immediate and to set a FPS limit from the game client itself. I've seen some odd black screen and minimap update issues recently on another distro that I'm thinking was because of OGL -> Zink and no longer completely trust this to be a safe workaround (certainly don't need graphical issues or crashing as hardcore :p)

Both Jagex Launcher and OSRS are Windows executables ran through Wine. Jagex Launcher seems to rely on Direct3D for GPU acceleration and uses DXVK when ran through Wine. OSRS is OpenGL. In Fedora's case I'm using the wine package included in default Fedora repos and nothing else (no Lutrus, no Flatpak, no Proton; just wine cli).

If anyone is interested in testing I have notes here https://wiki.realmofespionage.xyz/games:wine:old_school_runescape_jagex_launcher_c and Old School Runescape is free (free account sign-up, free client download, free-enough game content to test overall client behavior). You need a Jagex account (not traditional Runescape account) and it's possible you'll have to create a Runescape account first and then upgrade it (all free still) https://www.jagex.com/en-GB/accounts

What about when running it through gamescope?

It is not currently possible to use GTK 4 apps in Wayland with Orca. This will require https://github.com/flatpak/xdg-desktop-portal/issues/1046 to be fully implemented in xdg-desktop-portal, orca, and mutter/gnome-shell. Granted such users including myself do have options, staying on Fedora 39 being one of them. However it would be nice to be able to continue to move forward and use newer releases of GNOME with all the accessibility improvements that are likely to be included.

Having said all that, I am looking forward to being able to use wayland.

I feel like this needs an effort to fix/implement stuff that does not work in Wayland yet, which reminds me a bit of the Python 2 fade out where we ported quite some software to Python 3. Not sure whether this issue was meant as a place to collect this "fix me in Wayland" stuff but judging from the previous comments it became that place anyway. Let me add my two blockers from just a quick test:

  • Qt applications have ugly white window decorations in dark mode, for example KeePassXC.
  • wmctrl works only for X applications and I haven't found a direct replacement. (wlrctl is not packaged for Fedora, haven't tested it.)
    I use this script together with custom Gnome shortcuts to launch and switch applications so that is a big blocker for me personally.

What about when running it through gamescope?

I wasn't able to get good results with gamescope. The Jagex Launcher and OSRS game client renders in what looks like 16 or 256 color mode, and the FPS limit of around 52 is still there. I didn't notice any relevant launch flags for gamescope to fix that and put it right before wine in the command like "ENV1 ENV2 gamescope -- wine /path/to/Game.exe"

I'm not certain if it's a actual FPS limit or if it has to do with CPU usage, but when testing software mesa driver overrides and crocus and i965 I saw FPS go a little above 60.

Zink is fine with high FPS, and over the past day seems stable on F38 and Intel UHD 630 so it seems I can use this and be fine on Wayland. Worst-case, RuneLite's GPU plugin doesn't have a similar FPS issue with the native OpenGL and I can use that on Wayland.

FYI, we should at least make it possible to uninstall Xorg without ripping out everything in comps.

I submitted a PR for this a couple weeks ago because of Fedora Asahi work, but it'd be useful for this too: https://pagure.io/fedora-comps/pull-request/888

I hope that this now 2-year-old Mutter screen tearing bug (https://gitlab.gnome.org/GNOME/mutter/-/issues/1722) gets resolved before this change, otherwise, Fedora may become unusable for me.

Wayland has been our default session for a long time and has matured considerably. At the same time, the X11 session isn't getting as much testing, and is an additional resource burden.

It would therefore be good to have an exploratory conversation about whether we want to make any changes with regards to the X11 session. Options that we could consider include:

  • Hide the X11 session by default, so that fewer people use it.
  • Remove the X11 session file. Users would be able to add it back and use it as an unsupported configuration.
  • Build GNOME components (e.g. mutter/gnome-shell/gnome-session) without X11 support. Technically, users could recompile those packages themselves.

These changes would only affect GNOME and the session. Apps would still be able to use X11 through Xwayland.

Note that there is currently no anticipated time frame or schedule around this discussion or its outcomes. Additionally, no decisions will be made without getting advice from the relevant maintainers and domain experts.

I'm not sure where there is overlap between how Gnome and KDE Plasma work, but here are my thoughts from a marketing perspective on how we should consider artists in a potential transition to Wayland only.

https://discussion.fedoraproject.org/t/f40-change-proposal-kde-plasma-6-system-wide/89794/48

ngompa: You told me on Fedora KDE Matrix channel that Gnome doesn't work on Xorg. It works just fine on Xorg in Fedora 37. Maybe you just haven't tested it in a while?

ngompa: You told me on Fedora KDE Matrix channel that Gnome doesn't work on Xorg. It works just fine on Xorg in Fedora 37. Maybe you just haven't tested it in a while?

I didn't say that. I said "It runs on Wayland by default from start to finish since at least Fedora 25. And since Fedora 36, all fallback modes are Wayland instead of Xorg, just like Fedora KDE." And I didn't dispute that it works on Xorg. This was in reply to your statement "also gnome runs on xorg" in the context of Wayland for the different desktops, which (to me) sounded like you thought it uses Xorg by default, hence my answer.

For complete clarity, both GNOME and KDE are primarily tested, validated, and supported on Wayland in Fedora.

I can’t speak for Neal, but when I read that screenshot, I thought you were trying to say “GNOME runs on Xorg by default”, not that it has an Xorg session to begin with.

For what it’s worth, GNOME’s Xorg session (as the original post says) is not very well tested and has a few bugs that don’t exist in the Wayland session. For all intents and purposes Wayland is the only actually-supported, actually-tested, actually-developed option in GNOME.

Guild Wars 2's installer through Wine locks the whole GNOME shell on Wayland consistently for me, whereas it starts fine on Xorg session. Here's a testing command:

mkdir -p ~/'.wine' ~/'Downloads/Guild Wars 2' && wget -O ~/'Downloads/Guild Wars 2/Gw2Setup.exe' 'https://account.arena.net/content/download/gw2/win/64' && WINEPREFIX=~/'.wine/Guild Wars 2' WINEARCH='win64' wine ~/'Downloads/Guild Wars 2/Gw2Setup.exe'

F38 (6.4.15-200.fc38.x86_64) and Intel UHD 630 graphics.

Guild Wars 2's installer through Wine locks the whole GNOME shell on Wayland consistently for me, whereas it starts fine on Xorg session. Here's a testing command:

mkdir -p ~/'.wine' ~/'Downloads/Guild Wars 2' && wget -O ~/'Downloads/Guild Wars 2/Gw2Setup.exe' 'https://account.arena.net/content/download/gw2/win/64' && WINEPREFIX=~/'.wine/Guild Wars 2' WINEARCH='win64' wine ~/'Downloads/Guild Wars 2/Gw2Setup.exe'

F38 (6.4.15-200.fc38.x86_64) and Intel UHD 630 graphics.

Can you report a mutter bug for this issue at https://gitlab.gnome.org/GNOME/mutter/issues please? Thanks.

The workstation working group had an initial discussion about this issue last week, on 3 October. We came up with a few questions that we've put to the Red Hat graphics team. We'll wait for answers to those before discussing again.

This is where Telemitry would be very useful.

How many people are still using X11 and for what reason?

Kmag, a screen magnifier tool on KDE (vaguely related as its also a Fedora Spin) is not working on Wayland to this day. This would be a total showstopper for people with bad eyesight.

Telemetry would not help us at all. Elimination of the X11 session cannot be avoided, the X11 stack is basically dead. Telemetry helps when prioritizing development already being done, not triggering new development.

@ngompa It would at least show how many people that use X11 have huge font size, use magnifiers regularly, or use screen readers or other accessibility features, that may not work 1:1 or at all on Wayland.

I know X11 is dead, and people can just not update to avoid this, but not for very long.

I would like to add the aspect "remote support".

  • According to their documentation "HelpDesk by RemotePC" supports only X11. I did not test.
  • AnyDesk allows only X11 for incoming connections. Wayland works for outgoing connections. In the past management ruled to switch from TeamViewer to AnyDesk due to security concerns and massively risen license fees. And because AnyDesk supports Microsoft Windows, Apple macOS, and GNU/Linux clients. I set X11 as default mode. All fine. In April 2021 I contacted AnyDesk support, highlighted TeamViewer's plan to support Wayland, and asked if AnyDesk plans to support Wayland. Reply was along the lines of "AnyDesk developers are working on Wayland support, no roadmap or details available". Recent threads on Reddit with same question were answered along the lines of "no plan at the moment; we might do it some day". Today AnyDesk 6.3.0 still lacks Wayland support for incoming connections.
  • TeamViewer started to support Wayland for incoming and outgoing connections with version 15.29.x. Today I successfully tested on Fedora Workstation 38 with TeamViewer 15.47.3. Wayland support still marked as experimental.

Options "Hiding X11 session" and "removing X11 session file" is fine with me if I can add it back locally and continue using X11 due to AnyDesk.

We cannot block on random proprietary software, especially when open source alternatives do exist that support it. RustDesk, for example, does support Wayland through the remote desktop portal, just like TeamViewer does.

I have a bad gut feeling with RustDesk, due to finding company name (Purslane Ltd.) and country (Singapore), but no actual address or matching company registration. Thank you for pointing out remote desktop portal. I will bother AnyDesk support again.

I also use Anydesk by the way and yes it only works with X11.
By the way, I've been a Fedora user for several years and I've never moved away from xorg, so please don't drop xorg support, I'm really begging you.

  • I use NVIDIA's proprietary drivers on my NVIDIA GPU which are working just fine on X11 (I'm also one of the Avisynth contributors and I need to use CUDA) but have issues on Wayland.
  • Virtualbox doesn't support Wayland natively and relies on XWayland instead, while if you use X11 it will run just fine natively (I use VMs with Virtualbox pretty much every day). Trying to run it with -platform wayland to make it run natively results in a segmentation fault and this has been reported by several users in the virtualbox community.
  • Aegisub is old and is not maintained any longer, but it still remains one of the best open source subtitles editor and given that I have plenty of subtitles in .ass with typesetting, FX and automation code in LUA, there's no way I'm switching. It has no wayland support at all and it will only run on X11 (or xwayland).
  • Evince Document Viewer 45.0 has a very annoying bug on Wayland when you're trying to read the notes (i.e the "Note text") you wrote and attached next to some text: if the app opens on a position on the screen, let's say left, and then you drag the window right and click on the note, then the note pop up box will open in the old position instead of the new one. In other words, if you have the document on the right, it will open on the left outside of the PDF instead of opening next to the text where you put it. This is particularly frustrating if you're working with PDF a lot every day and you use your screen split between Chrome and Evince.

For these and plenty other reasons, please, I'm begging you, from the kindness of your heart, don't drop X11 support.
The time will come, I'm sure, but that time is not now.

For reference, here's an extract from the first 50 lines of the virtualbox logs when you start a VM (even when you're using the Wayland desktop environment on GNOME 45):

00:00:00.922155 GUI: Qt version: 6.3.0
00:00:00.922164 GUI: X11 Window Manager code: 2

and

00:00:01.029888 X Server details: vendor: The X.Org Foundation, release: 12302002, protocol version: 11.0, display string: :0

Nvidias proprietary drivers are annoying, but they have to get better. Please gather as many suffering users together to file bugs where they belong, to NVIDIA, that decided to ship a proprietary driver instead of a FOSS one.

Virtualbox not supporting Wayland is cringe. It is a FOSS project many people use, report bugs here and it should improbe. But I recommend you to try virt-manager anyways, which works without strange Kernel modules and using KVM, a native kernel feature.

I dont see the reason why Aegisub would not just work through XWayland then. XWayland will not be dropped. Also if you want to ensure compatibility of such an old app, try to Flatpak it. XWayland works perfectly fine.

I dont think that detauiled Evince bug belongs here. If it has a flatpak, disable Wayland and it will launch through XWayland. If its a native app there will still be a way to force it to use XWayland, for QGis (Qt App) for example there is env QT_QPA_PLATFORM=xcb qgis. Please file that bug where it belongs.

So in the end, I guess only NVidia is a real issue, and thats probably dealt with, if enough pressure goes into the correct direction, which is not poor FOSS distro maintainers that all suffer from NVIDIA bugs they probably can't fix.

Please note that a number of issues still exist when running the proprietary NVIDIA driver with Wayland:
https://download.nvidia.com/XFree86/Linux-x86_64/535.104.05//README/wayland-issues.html
In particular, I am affected by the following:
- night light is not working due to missing GAMMA_LUT [1][2]
- EGL falling back to software rendering [3]
- mame window blinking when running in a vulkan window (not reported yet as I do not have a simple test case)

I am aware that this is a chicken-and-egg problem: if X11 never goes away, the motivation to fix remaining issues will remain low. Having said that, I am not sure how much I would be inclined to continue using Fedora if I still have an nvidia card in my machine by the time F40 gets released. My laptop already has an AMD card in it.

[1] https://gitlab.gnome.org/GNOME/mutter/-/issues/290
[2] https://forums.developer.nvidia.com/t/gnome-night-light-not-working-under-wayland/193590
[3] https://forums.developer.nvidia.com/t/hardware-egl-not-working-on-wayland-libegl-warning-egl-failed-to-create-dri2-screen/262167

I am happy to report that with 545.29.02 nvidia driver, all of the above issues appear to have been resolved.

We discussed this at last week's Working Group meeting, but it looks like we forgot to post a status update here, so whatever we agreed on is probably now forgotten, unless somebody has a better memory than I do.

Proposal: just follow what upstream decides to do. Currently that means we'll remove the X11 session file soon, but leave the X11 support available for anybody who creates the session file.

I noticed that in the other thread they're talking about HDR support and proper color profile handling getting ready soon (couple of cycles).
Wouldn't it make more sense to wait until that's in place before actually going on with this?
It would help making that an official date so that the devs of other programs are gonna know as well and it would also give a rather good reason for people to eventually move to Wayland 'cause currently as things stand Wayland doesn't really offer any tangible benefit for people compared to xorg, so they wouldn't really see a reason to switch (and I'm one of those).
Having proper color management and HDR support in place would actually be a valid reason and it would soften the blow for long time xorg users like me.

We discussed this at last week's Working Group meeting, but it looks like we forgot to post a status update here, so whatever we agreed on is probably now forgotten, unless somebody has a better memory than I do.

There's a summary in this week's agenda:

I think it needs another round of discussion by the working group to come to a consensus.

Metadata Update from @catanzaro:
- Issue tagged with: meeting

6 months ago

We discussed this again at today's meeting:

  • We think we are ready to remove gdm's udev rules that cause the login screen to conditionally fall back to X11 rather than using Wayland. This will break users who are truly completely incapable of using a Wayland session. Affected users will need to edit their gdm.conf to reenable X11, which will require some technical expertise as there will be no graphical session from which to do so. This probably affects people who use older NVIDIA hardware with old driver versions.
  • We do not have consensus for removing the X11 desktop sessions prior to upstream doing so. Upstream is likely to remove them soon regardless of what we choose to do. Removing these sessions downstream does not have strong benefits for Fedora users.
  • We are especially sensitive to accessibility requirements and want orca global keybindings to work in Wayland. We encourage upstream to not remove the X11 sessions before global keybinding support is in place.

I said during today's meeting that I would keep this issue open so that we can reevaluate soon, but actually I think we have covered our bases here and am tempted to close it now. We can reevaluate again next time something changes upstream. Feel free to reopen if you disagree.

Metadata Update from @catanzaro:
- Issue untagged with: meeting
- Issue close_status updated to: Deferred to upstream
- Issue status updated to: Closed (was: Open)

6 months ago

Thanks for the update! :)
So, if I understand this correctly, the X11 desktop session will be kept available in GNOME 45.1 / Fedora 40 and the only thing that is "removed" is the default X11 fallback for new users that have just installed Fedora but can't use Wayland unless they edit a config file, right?
Older users who already have Fedora up and running and upgrade to Fedora 40 will still have the old gdm.conf in place, right?

In other words, if a user with, let's say, Fedora 39 has the following configuration:

GDM configuration storage

[daemon]
WaylandEnable=true
DefaultSession=gnome-xorg.desktop

which allows him to pick either X11 or Wayland at login time (and by default he logins to X11), upon upgrading to Fedora 40 he'll still have the custom.conf gdm file preserved, right?

Thanks for the update! :)
So, if I understand this correctly, the X11 desktop session will be kept available in GNOME 45.1 / Fedora 40 and the only thing that is "removed" is the default X11 fallback for new users that have just installed Fedora but can't use Wayland unless they edit a config file, right?
Older users who already have Fedora up and running and upgrade to Fedora 40 will still have the old gdm.conf in place, right?

No promises yet. What we've agreed thus far is Fedora won't remove the X11 session before GNOME does, or at least not in the near future. However there is still a good chance that the X11 session will be removed upstream soon. Whether this happens in GNOME 46 or a later release, and how exactly, has not been worked out yet.

A few thoughts:

  1. The default session for a user isn't specified in /etc/gdm/custom.conf (It was like maybe 15 years ago or something, but it's been specified in /var/lib/AccountsService/user/username for quite some time)

  2. Upstream we're discussing toggling XorgEnable=false in the config file and dumping the udev rules. This would mean, users would put XorgEnable=true to get Xorg back and maybe WaylandEnable=false to get rid of wayland (or PreferredDisplayServer=xorg to keep both but prefer Xorg).

  3. Users that don't change XorgEnable=true would get switched to gnome on wayland on upgrades unless they have WaylandEnable=false in their config. There's an open question what to do if XorgEnable=false becomes the new default and WaylandEnable=false is inherited from an upgrade. see https://gitlab.gnome.org/GNOME/gdm/-/issues/881

Yep, my bad, that was an old memory I had from the back of my head (it's been 15 years already? Really? Wow, time flies...)
Anyway yes, it's indeed in /var/lib/AccountsService/user/ and it's one per username, in fact mine is:

[User]
Languages=en_US.UTF-8;
Session=gnome-xorg
XSession=gnome

thus referring to xorg.

Anyway moving to point 2 and 3 which are far more interesting, if I got it correctly, in /etc/gdm/custom.conf, if a user has:

[daemon]
WaylandEnable=true
XorgEnable=true

after the upgrade to Fedora 41 / GNOME 46 (assuming that GNOME 45.1 / Fedora 40 are gonna stay as is as per the post before), the user is gonna have:

[daemon]
WaylandEnable=true
XorgEnable=false

and if and only if they manage to login using Wayland, they'll have to change it back to true to get xorg back, otherwise they need to rely on the command line, while if the user has:

[daemon]
WaylandEnable=false
XorgEnable=true

in their config, after the update it would be

[daemon]
WaylandEnable=false
XorgEnable=false

which means that they won't be able to login graphically and they'll have to set at least one of them to true from the command line to get the UI back?

If you were to go down this route, instead of limiting the change to XorgEnable=false, wouldn't it be more sensible to also insert WaylandEnable=true? I mean, Wayland may have its issues but the last thing you wanna do is leaving people stranded after an upgrade (not my case, but Fedora and GNOME are so widely used that I'm sure there are people with that kind of config).

There is a sequel here proposing to remove X11 session from the default installation while still allowing users to install it if desired.

Login to comment on this ticket.

Metadata
Attachments 1
Attached 8 months ago View Comment