> I don't have any real desire to get there while still pretending that the xfree86 hardware-backed server code is a real thing
What does he mean by that? That there isn't really a hardware-accelerated Xorg server?
If that's true, is the post indicating that Adam sees the Xorg code as an interface layer to some other rendering system that had hardware acceleration?
The xserver code base is huge and supports a lot of stuff. It supports drawing through hardware-backed drivers (e.g., xf86-video-radeon on Xorg), through generic drivers (e.g., xf86-video-modesetting on Xorg) and even through weirder drivers (e.g., xf86-video-nested). It also supports servers other than Xorg (e.g., Xephyr, Xvfb) and many other things.
In an ideal world where everything uses KMS or everybody uses something like Xwayland we would be able to kill million of lines of code from the Xserver. While this doesn't happen, those millions of lines not exercised by these paths remain unmaintand.
Remember, Ajax works for Red Hat, which is trying to push really hard for Wayland on Gnome. They don't seem to care about anything graphics-related that's not Wayland+Gnome. Red Hat has much more decision power on the Linux community than people imagine it has.
A huge problem here is that a lot of efforts that were previously redirected at X11 are now being done on the Gnome compositor, due to Red Hat. We just won't get to see a solution to the fragmentation power unless someone with a lot of money decides to play Linux Graphics.
sloccount says xserver is around 370kloc. This isn't counting the drivers outside of the generic KMS support (which, practically speaking, is what you're probably running on anything remotely modern), but ati+amdgpu+nouveau are another 102k, and intel is another 186k (partly because it embeds a copy of the software renderer for dumb reasons), so you're still not quite at two-thirds of an MLOC. The size isn't so much the issue, it's the design. The xfree86 ddx seriously believes that you have one video card driving one monitor with one keyboard and one mouse, and anything beyond that only works well because we sank a ton of effort into it. (It used to have code to disable interrupts! From userspace! What could go right.)
It sounds a little like you think I'm being given these priorities as marching orders from above. That's maybe a bit insulting? I suspect I'd have the same opinion at this point regardless of my employment history, namely, that X is a tremendously successful project whose core design and reference implementation do not reflect how computers work anymore, in ways that make it painful to develop and maintain as the system display server. Frankly that was probably true in 2005 when I started on it, but at that point it was also the only thing that had credible video drivers at all.
It's not that Red Hat is trying to lock anybody into a particular desktop out of some nefarious political agenda, it's that we don't have the resources to do things twice. If we want to deliver the best desktop experience we can then choose your own adventure among Gnome and KDE and XFCE and twm and i3 and whatever else simply is not going to be an efficient use of our headcount. And we're reaching that point with display services too, trying to support both X and Wayland increasingly means writing the same feature twice, sometimes with radically different approaches, and trying to implement them _at_ _all_ under X11 is more and more intractable. What would you have us do? What we're trying to build now is an Xwayland that keeps your X apps working as well as they ever did, under a hardware display server model that makes things like high-dpi and HDR and AirPlay and RDP and GPU offload straightforward, or at least feasible, instead of excruciating. You can like that or not, I guess.
In all seriousness, if someone wants to take the reigns of stewardship over the xfree86 code then please, by all means, come forward and claim your prize. But I can't justify spending my time on that anymore, and given the interval since the last major release, apparently nobody else can either.
> It's not that Red Hat is trying to lock anybody into a particular desktop out of some nefarious political agenda, it's that we don't have the resources to do things twice. … What would you have us do?
I appreciate the work that is going into the Wayland desktop ecosystem, really, but I would wonder why you would put all this general-purpose desktop environment implementation effort into Gnome specifically and not a common library like wlroots, with the Gnome compositor as a layer on top, so that all compositors would benefit. (I would ask the KDE team the same question.) It feels like what we are losing most with the transition from X11 to Wayland is commonality of implementation for the various system services other than input or presentation which were formerly handled by the X server, and which are now handled either by the compositor itself (Gnome and KDE) or by a shared library (Sway and any other wlroots-based compositors).
It is good that we at least have standardization at the protocol level, but just the same in my opinion it is … unfortunate … that the two largest desktop environments chose to forge their own paths in terms of the implementations of those protocols, with various desktop-specific extensions.
Yes, I recognize I exaggerated regarding LOC. I should have not said that. I do understand that the core protocol assumes one of each thing. Sometimes I dream about declaring X12 being the same thing as X11 but with the core protocol being converted to just an additional extension marked for deprecation :). Then we also deprecate everything related to drawing and find a way to make compositing great again.
> 2nd paragraph
I did not mean to insult you at all. But let's be honest: if you wanted to spend your time doing something that your employer does not want, you'd either have to do it outside your normal working hours or you'd start getting bad performance reviews due to not being aligned with the business priorities. Red Hat's business alignment has much much much more influence over the Linux ecosystem as whole than people on Hacker News realize or are willing to believe.
> 3rd paragraph
I understand it, and that's why I say things won't change unless someone else with lot of money decides to play Linux Graphics. We can't blame RH for choosing a path and following (to quote a certain someone, "Linux is not about choice", right?). But we do have the unfortunate consequence that RH's decisions are contributing to significant fragmentation. You don't want to have to reimplement the stuff for X+Wayland, but everybody else who does not want to use the Gnome compositor will have to reimplement the stuff you put on Gnome. There's probably a lot the community (not only RH) could try to push to alleviate the fragmentation problems.
Quite the opposite: games often just run on GL or Vulkan (actually usually Unity or Unreal which will then use GL or Vulkan), and will abstract input with something like libsdl, so they don't have to care about Wayland or X11. But still, some problems that affect games to have to be solved in the X11/Wayland level. Some are solved by the graphics companies (Intel, AMD, etc), some others are either left or picked by companies with a different kind of interest in the graphics world, like Valve.
If only we had more real world money-making products actually relying on the desktop graphics stack to make money, then we'd have a better graphics situation.
Terminology is something X has always gotten a little wrong.
The organization is called X.Org. The project is called xserver. It contains several display backends. The one based on the model inherited from XFree86 is called xfree86 in the code, but the executable is named Xorg (to avoid stepping on the XFree86 trademark, if memory serves). Its other backends you might encounter include Xvfb for an in-memory virtual framebuffer; Xwin and Xquartz, for running nested under some commercial OS' display servers; Xephyr and Xnest, for two different approaches to running nested under another X server; and Xwayland, for running nested under a wayland display server.
So when I say Xorg is abandoned I'm very specifically referring to the xfree86 code, to running xserver as _the_ display server.
What does he mean by that? That there isn't really a hardware-accelerated Xorg server?
If that's true, is the post indicating that Adam sees the Xorg code as an interface layer to some other rendering system that had hardware acceleration?
Is that XWayland? I'm guessing at all this.