Bad estimates for the share of users of DEs on Linux
Bad estimates for the share of users of DEs on Linux
Posted Apr 5, 2024 15:22 UTC (Fri) by farnz (subscriber, #17727)In reply to: Bad estimates for the share of users of DEs on Linux by paulj
Parent article: GNOME 46 puts Flatpaks front and center
The devs working on the graphics code in DDXes now just work in Mesa - they've dropped the DDXes a while ago. This is why Glamor exists, to provide a DDX that's backed only by an OpenGL driver (and which is used by Xwayland, too, so is maintained by Red Hat and Oracle people for people running X11 apps on GNOME). The remaining chunks of Xfree86 code were being worked on by people who were paid to do it so that GNOME continued to work; they've moved onto other things now that their employers don't care about GNOME/X11.
And because all the people who care have moved onto other things, nobody cares about the demise of the Xorg DDX code, bar some distros who are scared that Xserver will have a security flaw that needs fixing, and nobody willing to roll up their sleeves and fix the code. Previously, Oracle and Red Hat provided that by paying people to work on this so that GNOME/X11 worked. Now that GNOME doesn't need an X11 server, those people aren't being paid to work on the Xserver code base, and they've moved onto something else because that code is so horrible that people won't work on it unless paid.
Some people who are trying to get Someone Else to carry the maintenance burden of Xorg DDX code portray this as "they want to hurry the demise of the Xorg DDX code", but it's simpler than that - nobody cares enough to become the Someone Else who works on that code for the benefit of X11 DEs. It used to be the case that Red Hat and Oracle cared if there was an exploitable flaw in Xorg DDX code, since that would result in their paid product containing an exploitable flaw in GNOME; now, they don't, and Someone has to step up to the plate for WindowMaker, XFCE, Cinnamon, Trinity and any other DE that depends on X11, or accept that sooner or later, there will be an exploitable flaw in the X server where distros will fix it by removing the X server completely.
Posted Apr 8, 2024 9:52 UTC (Mon)
by paulj (subscriber, #341)
[Link] (2 responses)
But people _are_ working on Wayland, and the graphics libraries that underpin it, right? And someone is working on XWayland, right? So... could someone not add a mode to XWayland to let it present a full screen, undecorated, unmanaged-by-any-wayland-compositor window to X11?
Cause, wouldn't that allow all that unmaintained, unloved, old XFree86^WXorg DDX code to be set aside, and allow seamless transition of the user-facing X11 components (WM, clients) to then run on top of that /maintained/ graphics stack?
Posted Apr 8, 2024 9:55 UTC (Mon)
by paulj (subscriber, #341)
[Link]
Early on in Wayland, it was my understanding that XWayland would basically be the transition strategy - starting as a seamless, full-root-window server. But that, strangely, never happened.
Posted Apr 8, 2024 10:16 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
Xwayland, by design, takes in X11 protocol from its clients, and uses Wayland protocol to render the X11 requests in Wayland window(s) managed by Wayland compositors. It has no ability to present anything on the display itself; it relies crucially on a Wayland compositor doing all the hardware interaction for it.
In this respect, it's the same as Xephyr, XDarwin, X11.app and Xming - it acts as an X11 server for its clients, but implements it by talking to a different window system on the other side, and not to hardware.
It's an essential part of the transition process, since it means that when you move to a Wayland DE, you don't need to throw away all your X11 clients - you can use Xwayland to run them within your Wayland DE, and can use Xwayland in either rootful or rootless mode to run those clients in a way that suits you.
The bit that's missing is an interface between Wayland protocol and what hardware supplies; we call that a "Wayland compositor", and its job is to listen to Wayland clients (including Xwayland), and output commands to the hardware (e.g. via Linux kernel DRM drivers). That's what needs implementing, and that needs to exist outside Xwayland.
The alternative route, which you seem to be describing, is to create a brand new hardware-aware X server, dropping the xfree86 DDX code, using modern mechanism like Wayland does for rendering, and that has its own hardware access code similar to a Wayland compositor. But, unlike a simple full-screen Wayland compositor (which remains useful without Xwayland for things like games consoles), this is very much tied to keeping X11 servers working.
Indeed, if you really want to keep X11 DEs going, you should be able to run gamescope as your Wayland compositor (ignoring its gaming features), and use Xwayland as the X11 implementation.
Bad estimates for the share of users of DEs on Linux
Bad estimates for the share of users of DEs on Linux
Bad estimates for the share of users of DEs on Linux