F43 Change Proposal: X11Libre (system-wide)

Project Discussion Change Proposals
,
1

X11Libre

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

Wiki
Announced

:link: Summary

Replace the X.Org X11 Xserver (xorg-x11-xserver) with the X11Libre (XLibre) Xserver, an actively maintained fork.

:link: Disclaimer

The Change Owner does NOT share or endorse upstream’s political views! Given that those can be found even in the upstream project-wide README.md, the Change Owner feels obliged to make this clarification.

:link: Owner

:link: Detailed Description

A long time has passed since the last major release of the X.Org X11 Xserver. Even bugfix releases have become rare. Therefore, this Change proposes replacing the nearly unmaintained upstream with a maintained fork, the X11Libre XServer.

The upstream maintainer of X11Libre had been the most active remaining contributor to the X.Org X11 Xserver before the fork. The Change Owner is well aware of the controversies around the X11Libre upstream maintainer (FreeDesktop.org CoC violations, controversial political views, conspiracy theories, rants against Red Hat), but believes that the benefit of shipping maintained software outweighs the potential annoyances when having to deal with upstream.

There is no intent to ever replace the Xwayland implementation, only the standalone Xserver and its subpackages (Xnest, Xvfb, Xephyr), and possibly the driver packages (xorg-x11-drv-*).

:link: Feedback

The formal discussion on this Change has not started yet, pending official announcement of the Change.

:link: Some earlier X11-related discussion (not directly related to this Change)

Ticket:

Thread:

:link: Discussion of this Change started before the formal announcement

Thread:

:link: Benefit to Fedora

  • Fedora will benefit from shipping an actively maintained Xserver instead of a moribund one whose maintainers themselves label as “unmaintained” (pushing Wayland as the replacement).
  • All the Spins (and Editions, if any) still shipping X11 will benefit from the improvements. The ones that have switched to Wayland (only) will not be affected at all.
  • One interesting new feature is the Xnamespace extension, which aims at bridging the gap in isolation capabilities between X11 and Wayland. If and where that extension is used, it will no longer be possible to abuse the Xserver for privilege escalation across a security boundary enforced by the extension (e.g., host/container, root/user). (Note that this extension is purely opt-in and will by default do nothing.)
  • The Xnest nested X server has been ported from the legacy Xlib to the xcb library.
  • The fact that the Xserver is now maintained again means it will be able to live in Fedora for much longer, and the need to push all users to Wayland at all costs disappears completely.

:link: Scope

  • Proposal owners: Package x11libre-xserver (based on the existing xorg-x11-xserver package), add proper Obsoletes/Provides, get it through the package review process, and try to find comaintainers. (The packaging changes as such are pretty much self-contained. The Change is system-wide due to touching an important package with many users and reverse dependencies.)

  • Other developers: Drivers depending on the X11 driver ABI will need to be rebuilt (see the next section Upgrade/compatibility impact). For those that are part of X.Org, instead of just rebuilding the old unmaintained code, it may make sense to move those packages to the forks in the X11Libre project as well. Otherwise, no changes by other developers should be needed.

  • Release engineering: Rel-eng says no impact.

  • Policies and guidelines: No updates needed.

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

  • Alignment with the Fedora Strategy: Replacing near-unmaintained software with a maintained version matches the point “Focus Area: Technology Innovation & Leadership” of the Fedora Strategy and “First” in the referenced Four Foundations.

:link: Upgrade/compatibility impact

The fork is a drop-in replacement for the X.Org X11 Xserver. As such, no compatibility issues should be visible to end users, and RPM-level Obsoletes/Provides will transparently take care of the package rename. No manual configuration or data migration should be needed. No dropped functionality has been announced at this time.

However, as with every new major X.Org X11 Xserver release in the past, the driver ABI has changed. Therefore, any X drivers will have to be rebuilt with the new ABI. The process is the same as for regular major updates of the Xserver, though indeed it has been a long time since the last such major release, so this might come as a surprise to some.

:link: Early Testing (Optional)

Do you require ‘QA Blueprint’ support? N

It is planned to bring up a Copr repository as soon as possible to allow for early user testing. The Change Owner does not believe automated testing to be of much use for this Change.

:link: How To Test

Hardware requirements: Testing is useful on all hardware (except completely headless or text-only systems). No special hardware is needed. However, the more different graphics hardware gets tested, the better.

Software requirements: To test this change, the system only needs to run X11. So install any desktop environment or standalone window manager that uses X11. (If you want to test KDE Plasma, install the plasma-workspace-x11 package and make sure you test the “Plasma (X11)” session, not the Wayland one.) Then upgrade your Xserver to the X11Libre one (x11libre-xserver).

Testing: Once you have the requirements, you should try to use your desktop environment (or standalone window manager) as normal, and report any crashes or graphical glitches that come up. The expected result is that everything works without any crashes or glitches. A non-exhaustive list of items that are useful to test specifically is given by the following release criteria:

:link: User Experience

Users will not immediately notice any difference at all. In the long run, they may benefit from fixed bugs, from the Xnamespace extension if and when other software starts using it, and from future features.

:link: Dependencies

RPM reverse dependencies (other packages depending on this package): Several packages depend on the Xserver. Thanks to Obsoletes/Provides, most of them will not be affected by this change at all. However, packages depending on the driver ABI will need a rebuild (see Upgrade/compatibility impact).

Dependencies on other Changes: No.

Dependencies on other upstream projects: No.

:link: Contingency Plan

  • Contingency mechanism: Revert to xorg-x11-server. With suitably versioned Obsoletes/Provides, that should require only a sufficient bump of Release in xorg-x11-server and adding Obsoletes/Provides to xorg-x11-server to replace x11libre-server. The Change Owner will do it.
  • Contingency deadline: Beta Freeze. (Late enactment of the contingency plan is technically possible, but means a lot of testing may be invalidated.)
  • Blocks release? Maybe. If the Change is not implemented at all (or if the contingency plan is enacted): no. If any release-blocking deliverable is still using X11, and if X11 is so broken that it makes it fail the release criteria, then yes, until either the regression is fixed or the contingency plan is enacted. Otherwise, no.

:link: Documentation

See the upstream 25.0 release announcement. There is also the upstream README.md. Unfortunately, half of those documents consists of political statements (which are upstream’s views and upstream’s only, see the Disclaimer section) and rants.

More details about the Xnamespace extension can also be found in the rejected X.Org/FreeDesktop.org merge request.

:link: Release Notes

In this Fedora release, the X.Org X11 Xserver (xorg-x11-xserver) has been replaced by a maintained fork, the X11Libre Xserver (x11libre-xserver). This affects the Xserver itself (xorg-x11-xserver-Xorg) as well as the subpackages Xnest (which no longer depends on the legacy Xlib (libX11), but on the xcb library (libxcb)), Xvfb, and Xephyr.

End users are not expected to immediately notice any difference at all, but may in the long run benefit from fixed bugs and future features. Note however that, as with any major release of the Xserver, the X11 driver ABI has changed, so third-party drivers will need to be recompiled for the new Xserver version.

Last edited by @amoloney 2025-06-24T10:40:18Z

Last edited by @amoloney 2025-06-24T10:40:18Z

3 Likes
2

How do you feel about the proposal as written?

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

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

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

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

3

What about the broken, untested patches coming from that maintainer? Is X11Libre of sufficient quality (now, and in the future when it is likely to be a one-person project) to fully replace X.Org X11 in Fedora? Would packaging both be an option, at least until it becomes clear whether the fork is viable?

(I voted “opposed, but could be convinced”, based on this concern.)

10 Likes
4

Nvidia would need to add support for this, I believe it’s unlikely to happen.
390xx and 470xx will never support as they are legacy.
I will enforce xorg ABI for nvidia main.

1 Like
5

Strongly Opposed.

The libreX11 project has explicitly stated that the NVIDIA proprietary driver may not work,
and the wording of their comment[0] indicates they make no assurances that it will be supported going forward. While many may lament that there is a need for the proprietary NVIDIA drivers, the fact is there is for many people. A project not fully committed to supporting those drivers should not be made the new X11 server for Fedora.

For an underlying technology so important to some, the upstream MUST have a robust development community. It is easy to fork, it is hard to build a community. At this time, this project appears to be essentially a one person show. Once (if?) the project gains community traction and a larger development community, this proposal might be appropriate to be revisited, but not for F43 (maybe in a year or two?).

[0] * Proprietary Nvidia drivers might break: they still haven’t managed to do do even simple cleanups to catch up with Xorg master for about a year. All attempts to get into direct mail contact have failed. We’re trying to work around this, but cannot give any guarantees.

8 Likes
6

Nvidia has never supported unreleased xorg versions or RC kernels.

1 Like
7

The core of this proposal is not merely making x11libre available, but having it obsolete xorg-x11-server. The xorg-x11-server maintainers are not co-owners of this change proposal, and as far as I can tell have not consented to this change anywhere else. Aside from anything else specific to this fork or the upstream maintainer, it would be wholly inappropriate to allow a new package to obsolete an existing package without the consent of the existing package maintainer.

If the change owner wants to move this forward, the best way to do that would be to package x11libre in Fedora without obsoletes (which doesn’t require a change proposal), demonstrate its value over a multiple releases, and then reach consensus with the xorg-x11-server maintainers on when/if obsoletes should be added.

21 Likes
8

Okay, let’s split this into two:

A) Having X11Libre into Fedora
That part I very much don’t care either way. If it passes Legal, then go nuts, get that in fedora and deal with the packaging issues.

B) Replacing the official xorg stack
That one I am very strongly against, until it is supported by both AMD and nVidia and other vendors. And I am pretty sure that is nowhere even in the realm of being close to being possible.

7 Likes
9

@kkofler Kudos, this is one of the best-written proposals that I have ever seen. I don’t agree with the idea, but I really wish more proposals would be so comprehensive and detailed.

I think those two statements are in contradiction. If we need to rebuild the drivers for the change, we’d need to rebuild them for the revert too.

This means that we’d have two Xserver implementations in common use. Depending on how things are used, it could create complications.

I agree with what others have already written, so I’ll conclude similarly, but more from the POV of a distro maintainer. The new fork is creating a lot of churn with cleanups and new protocols and other ideas. Even if we completely ignore the problematic social behaviours of the maintainer, introducing significant changes in such an old project is very likely to unintentionally break backward compatibility or expose bugs in other components. The scope of work that would be required to take care of all of this is too much for a single maintainer. In addition, we keep X11 around mainly as a bridge until Wayland can serve all the requirements. Thus, we don’t to put any development effort in solutions based on X11, and no new features should be added there. So overall, switching to this fork doesn’t sound like a good idea at all.

6 Likes
10

I will be sharing a bit of spicy opinion, probably, but here it goes.

Accepting this project, even packaged, will set a precedence that Fedora knowingly trust this code written by people who hate Diversity, Equity and Inclusion.

In my eyes this goes completely against the Fedora DEI and other similar movements.

This does not make any sense to me.

Accept it and it will make me walk away from Fedora, since even when knowingly someone is hurting others, their output is trusted to be ran on systems without sandboxing. Especially on the lower level like X11 runs.

It would be very hard for me to trust anything Fedora packages after that. And once that trust is gone, it’s hard to get back.

26 Likes
11

Is there any indication that the person who made this fork possesses the technical and social experience to successfully manage such a large and important project and build a durable community behind it over an extended period of time? I have not seen evidence of this so far, and it feels too early to even be attempting to gather evidence for or against that, given that the fork happened barely weeks ago and the first release was only three days ago. There simply isn’t enough data in existence to answer these important questions.

We’re left with speculation. Maybe the project evolves in the direction of being stable and high quality over the long term and building an inclusive and welcoming community around it, and maybe it doesn’t — but until a certain amount of time has elapsed, we simply can’t know.

As such, the entire proposal feels premature to me, and that’s before bringing up any specific technical or social concerns about the project or its maintainer.

25 Likes
12

I believe the X11Libre project needs to prove competence with stable packages. Certainly right now X11Libre is far from having even a rawhide ready to test. In my opinion with a proven record of delivering a stable release X11Libre should be given opportunity when ready. So I’m opposed now for F43 but very open for F44+ if X11Libre has a stable release without serious regressions. I do suspect the Nvidia driver ABI rebuilds will be a showstopper for replacing Xorg so I’m skeptical at best if X11Libre can deliver.

13

I do not think the project is well established or proven enough that it can be relied on to be a replacement for Xorg/x11.

4 Likes
14

Xorg have been working great and been very stable for me. I don’t like the idea of replacing it with something I know nothing about but having more options are always welcome.

I think a parallel install option would be beneficial so people can choose what they run, this way it dont break for people that already run xorg

15

I think a package existing for Fedora is fine, but until this is proven, there’s no way it should be considered for obsoleting X11.

16

This statement implies that the Xorg X11 server was basically a one-man show before, and now that one individual has gone off and created a fork, so “why not follow the development activity?”

That seems to miss an important part of the situation, though - that statement implies that the maintenance being performed was effective. I’m a layperson observer, but there seems to be at least some evidence pointing toward the maintainer’s work being a net negative to Xorg:

This seems likely to prevent effective upstream/downstream collaboration - whether due to active hostility from the upstream maintainer, or reduced interest among Fedora contributors in engaging with an individual who takes such an approach.

10 Likes
17

I’m gonna also have to agree with many others in this thread and express my disagreement with this proposal. The maintainer’s need to make their hard right political views front and centre as part of the project in the README.md, combined with (to be clear - I think FOSS and politics are inseparable) shows contempt for users belonging to marginalised groups like myself.

Additionally, as many others have mentioned, the XLibre maintainer has a less than stellar reputation on technical issues, pushing many broken MRs and failing to test their code whilst causing code churn and ABI breaks with no clear (or at least immediate reason), and poor responses to being called up on this, leaving no clear reason to switch.

IMO, XLibre feels like a deeply unserious protest project lead by people who’s software shouldn’t be running as root on people’s computers. Especially given how heavily it’s author tries to justify its existence using conspiracy theories around big tech and ‘DEI bad’ level criticisms.

I think for Fedora to not just accept it’s inclusion, but to go further and outright replace the current X.org server entirely with no clear benefit shows that Fedora is willing to either enable this behaviour, or worse; actively endorse it. I think this would make users like myself not able to trust Fedora again (as akselmo mentioned, it’s easy to lose and hard to gain back), both technically and socially.

15 Likes
18

It sounds similar to freenginx and nginx (main person forked nginx over differences).

In that case, FreeBSD packaged both, freenginx offers Windows builds, and I freely switched my own stack to freenginx. Eventually nginx offered 1-2 newer versions, I saw no technical differences, and went back to nginx.

I know Xorg worked better for me 8+ years on GNOME, and technical differences implies that’s in stone. Xorg as-is currently (not X11Libre) seemingly works on Xfce, but my preferred DE is GNOME.

I’m interested in GNOME on Xorg, but feel this proposal doesn’t covers X11Libre on GNOME?

19

This is a very detailed Change proposal, but it also sends a fair number of red flags to me.

We do not actually know whether we can consider X11Libre “maintained”. As @airlied pointed out in the other thread, we do not know that they are capable of doing the actual work that the developers of xorg-x11-xserver does upstream (CVE triage and responsible disclosure, bug fixing, etc.). This is a huge risk for something that is effectively a critical path package for several spins.

This is realistically not of benefit to Fedora for the same reason Xsecurity wasn’t: it requires everything in the environment (the window manager, the applications, etc.) to be written to leverage it. The amount of work it would take to do so is sufficiently high that it would likely be considered equivalent to the work it takes to port to Wayland.

The Xserver is maintained by the XOrg folks, and that’s a big part of why the experience has been relatively stable for X11 for the past 15 years. Not trying to change the X server and focusing on Wayland for the new way of doing things has made things tremendously easier for everyone.

This wouldn’t change pushing all users to Wayland as the motivations for doing so are rooted in offering capabilities that are not possible with X11: native wide color gamut support, HDR, variable refresh rate for supported hardware, per-output scaling, fractional scaling, flexible input, and so much more. As an example, there are people building XR experiences with Wayland because the design makes it possible in the first place. There’s a lot more going on in contemporary computing than there was 40 years ago.

Transitioning to Wayland also has provided opportunities to clean up and modernize the basic experience itself. Smooth graphics and cheap compositing (because we’re not fighting multiple systems for drawing properly!) is a big deal, and something that brings us to the level of macOS in graphics performance and quality.

These days, there’s a lot of infrastructure to assist developers in moving from X11 to Wayland. And as I pointed out in the other thread, almost every spin currently using X11 has some kind of pathway to a Wayland based experience, with varying degrees of progress, but most at least usable at a basic level.

KDE has stated X11Libre is not going to be supported. This means that issues that arise from it are effectively WONTFIX upstream.

This is effectively a non-starter. Most people currently using X11 are doing so to leverage things like the proprietary NVIDIA driver. And as has already been stated, that is unlikely.

I am also concerned about the nature of the changes in the codebase upstream. Looking at the commit history, I see a lot of changes of varying quality landing, and not much in the way of quality or regression handling.

And this is worrying in itself. We use automated testing in Fedora to identify behaviors and ensure they don’t regress. We have plenty of empirical evidence proving that it has made Fedora a much better distribution, and it is a big part of how we maintain a high quality platform. If there’s no automated testing, how can anyone provide data to indicate whether it’s good or bad?

This is what I do not understand the most. This Change wants us to accept an upstream into our project and our community that actively dislikes us. That makes having a working relationship impossible and makes the whole effort unsustainable.

28 Likes
20

What’s better from a technological stance?

The work was done to create Wayland over X, and other apps are or have done the work to transition from X to Wayland, but with a different proposal, there’s now concern about having to do more work?

I aim to have a good desktop experience and don’t like the idea of it being less-performant to entertain less effort.

I don’t buy NVMe to tell it to chill at 1/2 speed; I want speed, and expect every part of the chain that offers that speed (drive firmware, mobo/PCI interfaces, OS, filesystem); one part of it being slow for non-technical reasons = a replacement for something more serious.

If others have a better way of going about change, it’s open-source code open to contributions.

What about higher-up IBM dropping DEI incentives? There’s always a boss, so what’s downstream’s response?

Politics shouldn’t affect code delivered to end-users; if the code works good, it’s good. Code can’t be discriminatory. It’s all open-source, and I’m sure looking deep enough into every contributor’s history could be made to match a less-than-stellar appearance today to suit an agenda, but how does that benefit end users using code?

1 Like