Given who founded Xlibre (Metux) has some...interesting history (he was banned from the X.org project due to poor code quality and practices [1]) I would say no

Metux himself also has some "fascinating" takes as archived from other projects such as the LKML [1] and Devuan [2] mailing lists

[1] https://gitlab.freedesktop.org/xorg/xserver/-/work_items/179...

[2] https://lkml.org/lkml/2021/6/10/957

[3] https://web.archive.org/web/20190404153507/https://lists.dyn...

You're trying to cancel this guy's project on hackernews comments because he quoted winston churchhill in 2025 and didn't get a vaccine donut in 2019?

What do you get from it? Is he your enemy? Seems like you are trying to destroy him using this comment as attack vector. And this comment is well prepared and sourced and easily repeatable, so I presume you use multiple attack vectors like this.

Just an observation. And as an observer, this is annoying to see.

That's a deliberate misreading of events but okay :)

Ah yes, "he doesn't agree with me, therefore he must be [insane|incapable|inept]" argument tied in with some nothing burger about Metux pushing code that could break things.

While I'm over here having to move to Xorg as Wayland breaks my applications about once every two months. Breaking changes, poor code quality, LLMs, or maybe it's just that the devs of Wayland were more motivated by their own personal needs/wants then the Xorg users.

I can never get back the hours I lost troubleshooting graphics drivers only to realize that Wayland claimed it should work, but doesn't. I'll take whatever Metux gives me if it works, or from anyone else for that matter.

Not the person you're replying to, but years ago Metux used to send PRs to a different project that I maintain. He was difficult to work with, insisted that his way was the right way when I wanted something else, and his code quality was usually middling at best. Some of his PRs were of the annoying "tidy this up" form, where it felt like someone who just wanted more commits in a repo and lines in `git blame`.

I hope his xlibre project is successful, but my opinion of the project is certainly tainted by my past interactions with him.

I don't doubt you. I think it's a good way to look at it. I appreciate what he's trying to do with Xlibre but I would never work in that environment with or without him.

As I said to the other guy I just hope this is better than what we have and I'll take about anything at this rate. I don't care to deal with people on that level anymore, which is why I stopped developing OSS over 10 years ago; everyone has their opinions about the code, if they can't solve that they fight over politics to "justify" forking and the downward spiral ever goes downward.

That's quite a disingenuous response to something I said with citations and no direct stated opinions on the person.

Be better

> Be better

What year are we in?

...Did we suddenly abandon bettering ourselves in 2026?

The "be better" comment was used exclusively by the worst people i knew for 4 years straight. So for me, absolutely.

It's condescending, unnecessary, and it is a polarizing comment people who are miserable leave to annoy the rest of us.

Sorry that self-improvement hurts you so

Sorry that you are incapable of seeing how others perceive you

Citations from people who want the whole platform die. (Actually they get paid for that, it's their dayjob to kill X11, but it can be their personal belief as well)

Yep, it is important to remember Metux was a sole guy supporting Xorg for many years while everybody else outright refused to touch the codebase. Then they blamed Metux for "breaking compatibility." While this sounds like a plausible reason, long time Linux users could recall that every major X release broke something in one way or another. It's just how it is, there is no way around it. They blamed Metux for doing something that cannot be avoided while maintaining the project, and claimed that Xorg must burn.

They also claimed features like namespaces would be impossible to implement in Xorg, which was later proven false as Xlibre brought XNamespaces -- as well as HDR and seat management. :)

I'm personally a Wayland user because I have AMD iGPU and use whatever comes by default, but I couldn't imagine Nvidia users having the same experience as me, even with their new drivers. I know it sucks because I used to own Nvidia. Removing Xorg while Nvidia users make up the majority is insane.

IIRC they blamed Metux for unnecessarily breaking BC, e.g. renaming & moving around symbols when it wasn't necessary and didn't improve features or fix bugs.

When you're working on something this foundational, BC breaks should always have a good reason, and he repeatedly didn't give any. This causes churn for all downstream consumers.

> It's just how it is, there is no way around it.

There literally is a way around it: not doing unnecessary BC breaks.

What applications?

> Ah yes, [...] some nothing burger about Metux pushing code that could break things.

Not could break, did break. Multiple times. When a contributor repeatedly submits broken and untested PRs, the correct solution isn't to let him keep trying as often as he wants.

idk man, it seems like a bunch of glass houses.

In context if you read what I said I didn't imply Metux was the best out there; I was highlighting how absolutely terrible Wayland is and how I will take anything at this point.

You can do that without misrepresenting the issues that got him banned. This happens almost every time there's a discussion on Xorg-related stuff, and I'm tired of seeing the maintainers getting slandered over and over.

So, here are a few direct links to the comments/issues/MRs (in chronological order), some very minor stuff, some bigger. I also didn't cherrypick examples where the maintainers acted perfectly, but IMO metux is far more difficult as you can see. Note I didn't search very long, so keep looking if you want to see more before you're sure:

- Small procedural issues: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...

- metux being difficult regarding work with nvidia: https://gitlab.freedesktop.org/xorg/xserver/-/commit/095e8ee...

- metux causes regression & it stays unaddressed for weeks, even though he was pushing on other branches: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...

- metux is marking threads as resolved when comments are unaddressed: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...

- metux causing unnecessary API breakage in commits marked trivial: https://gitlab.freedesktop.org/xorg/xserver/-/work_items/176...

- metux isn't properly testing his PRs: https://gitlab.freedesktop.org/xorg/xserver/-/work_items/179...

- metux breaking downstream again: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...

None of these are terrible on their own, but IMO taken together I can't fault the maintainers at all.

I was about to reply that it is now a project with many contributions, but looking here:

https://github.com/X11Libre/xserver/graphs/contributors?from...

it seems that there are only two additional significant contributors (an anonymous "stefan1111" and Alan Coopersmith, an X.org member who maintains the Solaris port), and a larger number of people who contributed a couple of commits here and there - and Enrico Weigelt (metux)'s commits are about three times as many as everyone else's combined. So, it is still very much his project, although not exclusively.

As for your links: You point to some exchanges which indicate problematic opinions, and an exchange which indicates, or at least, in which the project founder is accused of being somewhat reckless in making changes. The first kind of are legitimate to point out, and would make me wary of befriending him, but not directly relevant to his technical capabilities. The second kind is more worrying. Do you have a link to someone analyzing/considering the changes made to Xlibre relative to Xorg?

Be that as it may - while this does not sway me into belief in Wayland, it does introduce a grain of salt into my view of the X side of things, and thank you for that.

> which destroys variety and flexibility

That's probably the worst argument that you could make against Wayland: there has only ever been a single X11 server in common use on the Linux desktop (first XFree86, now X.Org), but there are tons of independent Wayland "server" implementations (Weston, Mutter, KWin, wlroots, etc.) [0]. Lots of these are written in completely different languages and implement different extensions from each other, so there's way more variety and flexibility with Wayland than with X11.

The more common criticism that I've heard is that Wayland's variety and flexibility is actually bad, because it makes it harder to add extensions (since you need to implement it in multiple different projects, and not just the single X.Org codebase), and it means that applications potentially have to test against multiple implementations. (I don't necessarily agree with this criticism myself, but it's still a valid complaint.)

> and of course nothing would run on BSDes

FreeBSD [1] and OpenBSD [2] both have Wayland support.

[0]: https://en.wikipedia.org/wiki/List_of_display_servers#Waylan...

[1]: https://docs.freebsd.org/en/books/handbook/wayland/

[2]: https://xenocara.org/Wayland_on_OpenBSD.html#running-wayland

I think the flexibility issues is more that you can't easily do things that used to be trivial. Try to spin up a bunch of headless wayland gnome sessions with VNC on a modern linux distro running on a server, it basically can't be done. This was trivial in the past, you just launched an X11 server for each one and handed it to VNC and you were done.

The hard part is knowing where to draw the line between relatively stable infrastructure items that don't benefit from duplication, and flexible items that are likely to benefit from specialization and competition.

X11 made the right choice in putting graphics drivers in the "stable infrastructure" stuff and display toolkits and window managers in the "specialize and compete" section.

I'm sort of pleased about that we're finally trying to replicate this division with the River ecosystem, building a standard compositor that we can plug in different actual window management logic into it, but that makes River itself a huge single point of failure-- if it has a bum release or fails to keep up with trends and extensions, it takes down a lot of the ecosystem, but perhaps not enough to be a five-alarm fire the way Xorg or XF86 back in the day would have been.

And one implementation that everyone settled on, and pretty much everyone can assume to be present is worse than multiple incompatible implementations how?

> and of course nothing would run on BSDes

A number of wayland compositors are available in at least freebsd and openbsd (haven't checked on netbsd and dragonflybsd). Wayland is only a protocol. Whoever wants to support it can.

> Wayland is only a protocol. Whoever wants to support it can.

I'm kinda tired of this line that I see everywhere. The bottom line is that most people develop for Linux, and don't consider the BSDs, and so things end up broken, or not working at all. The popular libraries for writing Wayland compositors consider Linux first, and BSD support is bolted on later.

The end result is that it's just more work for everyone. X11 could have been fixed, it's just no one wanted to do so in time to head off the Wayland work. XLibre and Phoenix might have ended up working out if they'd been started 10-15 years ago, but Wayland has too much momentum now, for better or worse.

(Source: I am a Wayland compositor maintainer who would love it if his stuff would work on the BSDs, but I don't have the time or energy to install a BSD and test and fix.)

> The popular libraries for writing Wayland compositors consider Linux first, and BSD support is bolted on later.

BSD devs can fork/write libraries too if they choose to or decide to not implement wayland which is valid too.

I din't see anyone complaining that xorg or xlibre is providing source that build and work for haiku, redox for example. My understanding is that both projects have to maintain their own patchsets to make it work.

HDR, VRR, Mixed refresh rate/DPI displays, Zero-copy video acceleration, support for tiled GPUs

Yeh... we should totally keep to X11.... especially when toolkits start to drop support.

None of that matters if you don't have a HDR monitor, only have one monitor, and when absolute basics of window management are somehow broken under KDE Wayland. Why that even has anything to do with Wayland I don't know. I just know that it all works perfectly when I use KDE X11. Maybe other DEs/WMs have better Wayland implementations, I don't know.

Issue is not wayland but KDE from what I understand here

Yeah, but it works under KDE+X11. Wayland it the thing that changes. I think KDE has it's own Wayland implementation? kwin_wayland is what is broken, probably. Why they broke it when porting it from X11 I don't know. But the effect is the same: Can't use it as of now.

You can't condemn a protocol because there are bad or buggy implementations.

HTML5 was not shitty because internet explorer was a shitty browser.

I don't condemn the protocol. I specifically mention the buggy implementation. I say that I use X11 because KDE's Wayland implementation is so buggy.

I want to use KDE. KDE was perfect for me before Wayland. I don't criticize Wayland here, I criticize KDE Wayland. And I'm worried because very soon KDE will delete X11 support.

But you can condemn the organization and people pushing for the deprecation and abandonment of another protocol, when the alternative one (Wayland) has nowhere near the level and quality of support and breadth of capabilities as the existing one. GP puts the blame on KDE - and it would be partially their responsibility if they were to drop X11, for sure, but the underlying initiative is RedHat/IBM's.

What is Wayland as a protocol missing?

Multiple monitors care about this :)

> None of that matters if you don't have a HDR monitor, only have one monitor, and when absolute basics of window management are somehow broken under KDE Wayland

So you think we should have one protocol for people who have HDR etc and another for those that don't?

I use KDE and have for 10+ years. In my experience, kwin is the most stable and performant it's ever been. I don't notice anything at all, ever. Under X, it was common to get stuttering, tears, and dropped frames. Not anymore. I mean I run 2 204hz 1440p monitors. And it's perfect, always.

I'm not saying you're wrong, but it's clear that basics of window management are not universally broken under Wayland. It works well for me and has for a couple of years.

Gnome /Wayland on Fedora44. No issues to report. AMD, but previously NVIDIA 4060.

> HDR...

Yep. Sucks. It's the only thing I miss about gaming on Windows. Hopefully xlibre will be adding that in.

> ...VRR, Mixed refresh rate/DPI displays, Zero-copy video acceleration...

I know that the first two work fine on xorg [0]. It's not entirely clear what you're talking about with the third, but I know that xorg supports compositor bypass for windows so that programs can interact with the graphics card without the windowing system getting in the way. Like, I think this is a thing people were talking about working on back when Compiz and its wobbly windows was new and exciting.

If that isn't what you mean by your third thing, perhaps you'd be interested in specifying what video acceleration mechanism xorg doesn't have?

> ...support for tiled GPUs.

Doesn't that only matter for Apple Silicon(TM) machines, and maybe some ARM machines with integrated graphics? If folks want that, it's "just" a matter of writing the drivers to make it happen and getting them into an xorg fork. Can you show me a feature or features of xorg that makes it impossible.. other than FDO's tactical neglect?

EDIT: Actually, I dimly recall some old hardware that I think was supported by DRM that did tiled rendering. Maybe it was some PowerVR stuff? If my memory isn't failing me, then there's the counter to claims that it's impossible for xorg to support. :P

[0] Source: Me having these work just fine for quite a long time now on my personal machines that run xorg.

> Hopefully xlibre will be adding that in.

You will also need toolkits/games to add support for any additional protocol, which I doubt they will.

> It's not entirely clear what you're talking about with the third

Zero-copy video means you can play vides in web pages hardware accelerated and have no copy of the video frame required to send it to the display. This saves a lot of power.

> it's "just" a matter of writing the drivers to make it happen and getting them into an xorg fork

Compositing with Xorgs model and applying any kind of screen effect would be extremely painful on tiling GPU because of how the screen is passed back and fourth to the compositor. Given compositing in Wayland compositors is passive, it does not have that issue.

Notice how Wayland on the RPi had performance that it simply couldn't gain under Xorg.

> Me having these work just fine for quite a long time now on my personal machines that run xorg

Good for you. But we have modern hardware and demands that simply Xorg doesn't meet and the protocol is archaic that adding support isn't worth it.

Wish I could use it, I really tried! I have some HDR screens I want to actually run HDR on. But KDE Plasma + Wayland keep crashing out on me.

Which distro?

Nixos unstable atm fwiw, which you'd expect would pick up fixes early. But my particular setup with displayport DPMS stuff keeps going wrong, and there's a bunch of WONTFIX under KDE afaict.

Ehhh I know people love that and swear by it, and maybe it's fine, but I wouldn't expect it to have great integration and a solid, reliable, desktop experience on nixos.

KDE/X11 is rock solid, at least

> especially when toolkits start to drop support.

Which toolkits are dropping support for X11?

AFAICR, few toolkits support Wayland (even though the two major ones, GTK and Qt, do).

i like the idea of wayland but i agree about the loss of flexibility. they seem very concerned about security and make screen sharing very complex now if you stray from the accepted path. systemd complicates this further with logind seat management etc. as a result our companies dev servers where we run a bunch of simultaneous VNCs and independent mate desktop sessions can really only work with X11 for now. There is a way to do it with nested cgroups running n number of systemd instances etc but its a pain and then we would have to use gnomes built in rdp thing which we dont want to use… anyway i actually vibe coded a way to get it working with wayland in containers with a dummy kernel video driver, my own fake logind etc. etc. etc. it was a harrowing experience but fun.

> i agree about the loss of flexibility

The maintainer of Phoenix puts it very well[0]:

> The main issue with Wayland is not a technical one but in its philosophy. X11 is "mechanism over policy" while Wayland is "policy over mechanism".

[0] https://git.dec05eba.com/phoenix/about/

I kind of wonder that too, I'm fine using wayland but it seemed like a huge user hassle for not many benefits (namely independent screen scaling which xlibre now supports). It's a shame xlibre didn't come around sooner, after years of pain wayland support has gotten a lot better, to the point I can more or less use either without issue.

> It's a shame xlibre didn't come around sooner

Xorg team had accepted Enrico's patches then did not release them. Classic saboteur handbook stuff

There were years where, to my understanding, they were deliberately not accepting features or patches to push Wayland, which is kind of frustrating, because it misses the point of a competitive ecosystem. Like on one hand if they're deliberately sabotaging Xorg for Wayland it implies Wayland must actually be a lot better, but on the flip side if Linus had sabotaged linux in favor of seL4 we'd all be worse off, even though kernel engineers often regard microkernels as a "better architecture".

> course nothing would run on BSDes

Ummmm, Wayland runs on FreeBSD...

https://docs.freebsd.org/en/books/handbook/wayland/

Great, I can run Compiz Fusion replacement, yay.