GNOME Dropping X11 Support May Complicate Next Ubuntu LTS

The march to a Wayland-only future continues, with GNOME looking to drop support for X11 session as soon as this year — far sooner than Ubuntu would like.

Ubuntu 26.04 LTS, due out next year, had been planning to ship GNOME 50 and Xorg according to (the latter likely being the final long-term support release to do so, giving general trends).

But, per Gitlab, GNOME wants to remove all X11 session code—which allows the desktop to run on the ageing Xorg display server—by GNOME 50. Once gone, running GNOME on Xorg will, in their words, be an “entirely unsupported configuration”.

—XWayland is not affected; don’t panic on that score.

Of course, Ubuntu already defaults to running GNOME on Wayland, including on NVIDIA hardware.

It only ships a fallback Xorg/X11 session for those who need or prefer it for edge-case reasons (running a specific tool) or if a hardware configuration can’t support Wayland.

Thus, it’s not so much GNOME itself not running on the aged display server that’s the stickler, but how far the X11 session code removal goes, and the edge-cases it may affect from Ubuntu’s POV, as a downstream distro planning its next LTS.

The pain point is in removing code which allows GDM, the display manager (aka login screen) to start X11 desktop sessions, as one Ubuntu developer explained:

I think it would be very disruptive if GDM was unable to load Xorg sessions so I request that GNOME try to keep that working. My understanding is that GDM is the only login manager that currently works 100% with GNOME. It would be bad if we forced people who want to easily switch between desktops to use something like lightdm or sddm and then not have the Lock Screen working correctly in GNOME.

J. Bicha, Canonical

Any decision has knock-on implications for the distro, its paid enterprise and businesses customers, and the millions of others who rely on it — not only gamers¹, but educators, researchers, etc, all with expectations and needs, all choosing Ubuntu as it met them.

Given this, discussions are underway on ways to start X11 sessions through GDM in a post-X11-code-removed-from-GNOME landscape.

One leading idea, put forward by Red Hat’s Adrian Vovk, is to shift responsibility for starting Xorg to individual desktop sessions directly, allowing GDM to be shorn of Xorg baggage:

XOrg desktop environments should configure themselves such that launching their .desktop file takes care of launching XOrg as well. This lets us drop all of GDM’s bespoke XOrg support, without sacrificing the ability to launch X11 desktop environments.

Adrian Vovk, Red Hat

That might assuage Ubuntu’s concerns, and still allow Ubuntu 26.04 LTS to ship with GNOME 50 whilst continuing to provide a Xorg session for those who need it — likely as a last LTS hurrah.

Why care about Xorg anyway?

GNOME, from what I can glean, plan to ‘soft disable’ X11 session support in GNOME 49, before it goes on to ‘rip out’ code in GNOME 50 – time for those involved to prepare and adapt, which will have to happen at some point.

Fact is, there will never be a good time to drop X11 support. Doing so will inconvenience someone, somewhere, in some way², so why keep waiting for the perfect time?

For projects many projects, having to maintain code to support X11 soaks up development effort it could put towards pushing the future, rather than pulling up the past.

If people need Xorg, there are other desktops that work with it.

But for those (like GNOME) committed to Wayland resolutely, it is ultimately counterintuitive to keep Xorg support around: it’s crutch; there’s less impetus to learn to move on without using it.

Wayland is where the bulk of development effort is; Xorg is in maintenance mode, seeing little active development (what I call “actively unmaintained”). Ever-moving goalposts of what Wayland “needs” to reach before a shift ought to happen won’t help.

As one dev put it: it’s time to be “less carrot, more stick” — does that make NVIDIA a piñata?

Thanks Dominic!

1. Said because when people list reasons why Wayland isn’t ready they tend to focus on things gamers need (or want). The counter when people say Wayland is ready for the masses is usually “my games run fine” – point is: there are more use cases than gaming. ↩︎
2. Remember: the goal isn’t to recreate Xorg in Wayland; many “but it needs to…” blockers are counter to the explicit aims of Wayland and so better addressed/added elsewhere in the stack — where not, Wayland is open-source, so code/help/proposals are sure to be welcomed. ↩︎