That dude had a crazy amount of patches ready to go. I don't have the technical skills to judge if the patches are any good, but that's an impressive amount of work.
I'd be a little concerned that this is just one person doing the work, but we'll see if others join in.
From looking at his Xorg contributions on FDo, his technical work amounts to mostly code style changes and cosmetic-level refactors in an attempt to clean up the codebase. In the course of this, he's broken the master branch on multiple occasions and introduced a large amount of churn in the Xorg ecosystem, all while not fixing any bugs or improving anything user-facing. The reason why he started this fork seems to be that his changes pissed off everyone working on Xorg who could review his MRs, so they started piling up without getting reviewed.
> Changing calls pScreen->DestroyPixmap to dixDestroyPixmap doesn't meaningfully improve the code or make it easier to reason about. Moving byte-swapping of requests and events from one function to another doesn't make the code more robust. Cosmetic changes to the way length fields are written doesn't help with byte vs. word unit confusion, or keep you from writing the wrong amount of data. You're just moving the complexity from point A to point G, not reducing it.
> It is possible to reduce the complexity of the code, by delving deep into the interactions between DIX/MI/FB/DDX to flatten the code flow, making some deep structural changes. Or by using structured (de)marshalling through XCB. Doing this would be incredibly risky, but at least have a much higher payoff than just cosmetic shuffling because it is 'cleaner'.
> The immense value X11 has - that it always had and will have for decades to come - is its backwards compatibility, still being able to run 40-year old apps. You correctly called the codebase 'fragile' - you've been finding this out as your changes repeatedly break things. If you're breaking apps, then what exactly is the value in a codebase which is 'cleaner' to your subjective standard but doesn't actually work?
I hope so. I've tried to use wayland more than a decade ago, it was unable to replace xorg. Again last year, same story, and we get told that it's our fault because we need to adapt our workflows to wayland. I chose Linux because I get to choose how I work.
Exactly. I came to Linux because Microsoft keeps changing; correct way to do things, configuration files/locations all while deciding to shove ads and tracking down our throats.
The MR that caused the drama that caused the fork to happen complained about this author doing tons of work to tons of legacy code with no direct user-facing benefit without testing his changes properly. From the sentiment of the discussion I gather this isn't the first time either.
I think trying to improve the quality of such old code bases is good and "don't touch it in case something breaks" has caused more problems than it solved, but in this case the lack of testing caused X to die when someone runs xrandr. Not exactly a vague use case. Large restructuring work and taking care of tech debt is good, but it should go along with diligent testing.
Until all the work is done, I don't think this will be a very stable alternative to X.org. I also don't think many people will follow this guy to the new project because the comments on the MR seems very "this guy versus everyone else".
Even if the fork stabilizes, that's just where the journey begins. The X.org system interacts with tons of other systems (the kernel and GPU drivers, among others), so that work need to be kept up with. At the same time, developing all of the new features the dev wants to add will be pretty useless unless applications start making use of them, and they're not going to if the project remains small.
If the anti-Wayland people unite behind this project and maintain their own X fork, there may be promise in this fork. But looking at the history, this is more likely to become another X12/Y11, or maybe a Mir if he can get a distro to back him.
I'd be a little concerned that this is just one person doing the work, but we'll see if others join in.