This is irrelevant to the merits of the code.
It is my current understanding that a parallel-installable set of packages would not require a systemwide change proposal at all.
Yes, I also wonder whether this even has to go through the Change process if we decide to not replace X.Org.
Sir,
You wrote the change proposal. If you are unsure this needs to go through the process, why did you write the proposal before attempt to generate parallel installable packages.
Iâm honestly a little confused why you started with the most disruptive way to introduce the change instead of just attempting to build a set of copr packages that are parallel installable and work from there.
1 Like
More to the point,
I think you could right now retract the proposal, work on the parallel installable packages as the least intrusive way to introduce a new X11 server implementation.
If you are unsure this needs to go through the process, why did you write the proposal before attempt to generate parallel installable packages.
Well, my hope when I filed this proposal was that this could indeed replace the X.Org Xserver and bring X11 back out of âmaintenance modeâ, and that, I think we all agree needs a system-wide Change.
Also keep in mind that the deadline for system-wide Changes for Fedora 43 is really soon (July 1), so there is not much time for âtry this and that first, then discuss options, then submit a Changeâ. That said, I have been complaining about other Changes getting rushed this way, so I guess I should know better. I suppose I could have a try at non-obsoleting packages first, then either submit a Change targeting Fedora 44 instead of 43 or discard the Obsoletes idea entirely.
About the NVidia driver issue: Upstream claims that he wants to keep the NVidia drivers working and that they currently work. But this might be wrong, or it might be true only for the latest driver branch and not for the legacy branches that people are most eager to run X11 for (because those legacy driver branches do not support Wayland). So if @leigh123linux says that it will be an issue, he is probably right. But I was not aware of that when I filed the proposal, because I had fallen for upstreamâs claims on that subject.
Yes Kevin
I agree you should know better.
Nvidia 575.xx latest âNew feature branchâ fails due to the new ABI version.
[2025-06-14 21:28:18] Module class: X.Org Video Driver
[2025-06-14 21:28:18] ================ WARNING WARNING WARNING WARNING ================
[2025-06-14 21:28:18] This server has a video driver ABI version of 28.0 that is not
supported by this NVIDIA driver. Please check
http://www.nvidia.com/ for driver updates or downgrade to an X
server with a supported driver ABI.
[2025-06-14 21:28:18] =================================================================
[2025-06-14 21:28:18] (EE) NVIDIA: Use the -ignoreABI option to override this check.
Overriding the ABI check has rarely worked in the past, it usually ends with a server crash.
I want to be very clear that I am not a developer, so the following questions are based purely on my own assumptions.
Sorry if this seems like a silly question, but if XLibre were to be packaged and provided as a replacement for X11, and worked on for it to be installable alongside plasma-wayland (as an example), wouldnât that create some sort of friction(?) to users that decide to install the package by getting into âuncharted territoryâ not supported by upstream (KDE Plasma in this example)? Iâm guessing this new package will inevitably cause new bugs previously unseen by the regular plasma-x11 session, but I am no developer so I might be completely wrong.
I can see this package causing confusion for new users that get asked to install an x11 session and then getting bugs that are not reproducible by others on other distributions.
Also, considering the current to-be-proposed change mentions replacing X11 completely (or so I understand), it could either be completely fine or catastrophic, considering all desktops currently offering X11 either by default or optionally would need to be reworked to support XLibre, meaning more of a maintenance burden to support something that is not supported in the upstream desktops.
Iâd love to read responses (and questions) from people that know more about this stuff.
If you havenât, please read
3 Likes
Yes. The upstream KWin (KDE Plasma window manager) developers have indicated they will not support the combination of Plasma X11 and x11libre. I imagine this will be true for other desktops too.
3 Likes
In principle, desktop environments should not need to specifically support X11Libre to begin with (unless they want to support new features such as the Xnamespace extension, if and when that actually becomes usable in production). It is an X server speaking the X11 protocol. Desktop environments do not use the Xserver module ABI which breaks at every major release, they use the X11 protocol, which (at least in theory) is much more stable.
That said, bugs can of course exist, and it is unfortunate that some desktop environments are outright refusing to test on X11Libre. (That said, if major distributions start shipping it, and Fedora is of course one such major distribution, they may have no other choice but supporting it. Especially those that, unlike Plasma, still target only X11.)
And about NVidia: The commit history Commits · X11Libre/xserver · GitHub shows that they reexported a whole bunch of functions to make the NVidia driver load, so there is at least some effort to make it work.
What I am also wondering is: Let us hypothetically assume that in some close future, X11Libre will have made great progress, that Xnamespace will have started working, and that some other nice new features will have been added (maybe another extension for HDR support?). (Yes, I love that future perfect tense. 
) Then how long will we be willing to hold back progress just because of third-party proprietary drivers that we do not ship?
Once X11Libre has shown that itâs delivering benefits then the case to support it will have evidence. But until that progress is shown why would you bet on it delivering?
I just want to make clear again that I do not agree with the kind of posts by Lunduke that you quoted there and that I consider this kind of bullying against LGBTQI+ people and against FOSS projects showing their support for that community to be entirely off-topic for what claims to be a tech journal. Yes, this kind of mixed-content blogs and social media presences, mixing some other topic with rightwing political propaganda, are a problem, and Lunduke is not the only one doing that (but he is definitely one of those doing that).
That said, in my view, that still does not make it a sanctionable offense to forward information to that person. Though I would personally choose another medium to make things public.
Please, correct me if I am wrong, but Fedora as far as I know was the first distribution that defaulted to Wayland on NVIDIA dGPUs before any other. I am sure Fedora has been doing that since at least Fedora 37 if my memory doesnât fail me, and ever since we only got improvements on that front.
While I believe your same argument was used when defaulting to Wayland (as can be seen in this small example), this is slightly different, as X11Libre has - as far as I know - no funding from big organizations, not a lot of developers considering how massive X11 is and already was 20 years ago for a lot of people and developers to yearn for change so much that Wayland was created in around 2008.
I believe the project, as it stands, is unsustainable.
Considering that the top Wayland desktops just got HDR support in the last couple releases + all of the above, as well as Wayland having significantly more funding and support from most desktops, experimental or not, I fail to see the benefits of duplicating such work. Not to mention that Wayland has been around for almost 20 years and only now we are seeing significant improvements being made in every front. How long until those same significant improvements are made for a display server that is older than Linux itself, has fewer developers, fewer or no funding (as far as I know), and technical debt that spans around 4 decades?
I am sorry if this sounds insulting in any way, this is not my intention. These are genuine questions.
Not really. Another option for most of those X11-only environments with no direct path to Wayland would be to use rootful Xwayland on top of a thin Wayland compositor like Weston, Miriway, labwc, or Cage.
Regardless, the following spins are X11 by default as of Fedora 42:
- Xfce
- Cinnamon
- MATE
- i3
- LXDE
- SoaS
- Budgie
Of all the spins in Fedora, the only spins Iâm unaware of having a direct path to Wayland are the i3 spin (which its users can use the Sway or MiracleWM spins to have similar experiences) and the LXDE spin (which its users can use the LXQt spin to have a similar experience).
Xfce, MATE, and Budgie have ported their components to run on Wayland. Budgie is expected to switch to Wayland in Fedora 43 (their git mainline codebase is already ported to Wayland). MATE has a Wayfire-based session available, Sugar has been slowly working on moving to Wayland, Cinnamon has a Wayland session that they are aggresively developing, and Xfceâs window manager is slated to be ported to Wayland (but you can use Wayfire or labwc now with it and have a Wayland experience).
1 Like
You can, but it doesnât quite give you the xfce experience.
I doubt that that is a realistic option for any of them, considering:
- the limitations of Xwayland (e.g., positioning requests by applications will typically be ignored, which makes it no better than just using Wayland directly),
- the extra bloat that the extra layer (X11 on top of Wayland instead of bare metal X11) adds, when those desktop environments typically strive to be lightweight.
I do not see why they would prefer to target such a kludgy solution rather than an actively maintained Xserver fork (or a native Wayland port).
Rootful Xwayland does not have this limitation as it has a full X screen space of the X11 root window to work with. This can be set up on a Wayland compositor to be the full compositor screen space.
If the project is dead, the âkludgy solutionâ is quite fine. Actively developed projects are already working on Wayland ports (or have them already).
Again, Iâm very confused as to why you are choosing to introduce Xlibre as a cut over replacement via the system wide change given the statement above.
Please consider retracting the systemwide change proposal and work on making parallel installable packages available as a way to introduce any alternative X11 implementation. I just donât understand how forcing a system wide change discussion âto begin withâ is the approach best aligned with the principle youâve stated.