3 ms·

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 generi

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.

nerdponx 6y ago
What do game devs have to say about all this? Or do games bypass X11/Wayland and do some kind of lower-level rendering?
- dyingkneepad 6y ago
  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.
ajaxnwnk 6y ago
So. Couple of things. 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.
- nybble41 6y ago
  > 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.

nerdponx 6y ago

What do game devs have to say about all this? Or do games bypass X11/Wayland and do some kind of lower-level rendering?

dyingkneepad 6y ago
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.

ajaxnwnk 6y ago

So. Couple of things. 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.

nybble41 6y ago
> 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.