There's been some recent discussion about whether the X server is abandonware. As the person arguably most responsible for its care and feeding over the last 15 years or so, I feel like I have something to say about that.
The thing about being the maintainer of a public-facing project for nearly the whole of your professional career is it's difficult to separate your own story from the project. So I'm not going to try to be dispassionate, here. I started working on X precisely because free software had given me options and capabilities that really matter, and I feel privileged to be able to give that back. I can't talk about that without caring about it.
So here's the thing: X works extremely well for what it is, but what it is is deeply flawed. There's no shame in that, it's 33 years old and still relevant, I wish more software worked so well on that kind of timeframe. But using it to drive your display hardware and multiplex your input devices is choosing to make your life worse.
It is, however, uniquely well suited to a very long life as an application compatibility layer. Though the code happens to implement an unfortunate specification, the code itself is quite well structured, easy to hack on, and not far off from being easily embeddable.
The issue, then, is how to get there. And I don't have any real desire to get there while still pretending that the xfree86 hardware-backed server code is a real thing. Sorry, I guess, but I've worked on xfree86-derived servers for very nearly as long as XFree86-the-project existed, and I am completely burnt out on that on its own merits, let alone doing that and also being release manager and reviewer of last resort. You can only apply so much thrust to the pig before you question why you're trying to make it fly at all.
So, is Xorg abandoned? To the extent that that means using it to actually control the display, and not just keep X apps running, I'd say yes. But xserver is more than xfree86. Xwayland, Xwin, Xephyr, Xvnc, Xvfb: these are projects with real value that we should not give up. A better way to say it is that we can finally abandon xfree86.
And if that sounds like a world you'd like to see, please, come talk to us, let's make it happen. I'd be absolutely thrilled to see someone take this on, and I'm happy to be your guide through the server internals.
21 comments:
Thanks for maintaining xorg for so many years :D
(y)
I'd honestly love to see a Wayland compositor that meets my needs. Heck, I've been eagerly awaiting Wayland's ability to forcibly prevent games from getting fullscreening so wrong that it tricks the WM into squashing all my windows into a single monitor, and I chimed in to encourage that specs call for the screensaver to take events on gamepads into account so every game doesn't need to suppress the screensaver... but I'm still waiting for that compositor to exist:
1. A session recovery protocol as a successor to re-launching my WM/compositor with `--replace` every couple of weeks to flush out buggy behaviour without nuking what I'm in the middle of working on. (I can stay logged into a single desktop session on X.org for months this way and I've never seen a compositor last more than two weeks without breaking. That's why I turn off compositing in KWin.)
2. Forced server-side window decorations. (Sorry, GNOME. I don't agree that we should value the ability for applications to arbitrarily reinvent common UI functionality that really should be privileged in the first place.)
3. Compatibility with nVidia hardware. (I don't want to buy a new GPU just for Wayland, and, from what I've read, AMD's drivers still don't give the stability and uptime I've come to expect from nVidia's drivers over the last ~17 years.)
4. Extension APIs to implement things like my QuickTile window-tiling helper without putting a bunch of gunk on the main thread and janking up my rendering. (Where are those mechanisms for privileged APIs that were promised in the Wayland concept docs?)
5. Doesn't require me to buy beefy new hardware just to drive a heavier desktop. (I intentionally run a mix of LXDE and KDE components chosen to be lightweight, so I can dedicate more resources to actual work.)
> So, is Xorg abandoned? To the extent that that means using it to actually control the display, and not just keep X apps running, I'd say yes.
I might be reading this wrong (though i think that quote is very explicit), but does that mean that you are not interested in maintaining the X server as anything else than a compatibility over Wayland? If people find issues with the X server as a standalone server (ie. using it to "actually control the display") and submit fixes, are these going to be integrated into the code and be part of a release (which seems to be taking a while)? Or the only way forward for those who want to keep using the X server like they always did is to fork it?
What’s the status of Xeyes? I’ve been trying to get a version that winks at the user for a while but to no avail.
@Unknown Those are all valid criticisms of many of the existing wayland servers. I'm of the opinion that keeping xfree86 alive as a viable alternative since wayland started getting real traction in 2010ish is part of the reason those are still issues, time and effort that could have gone into wayland has been diverted into xfree86.
@BadSector My preferred path forward there is to fork the server upstream. The xfree86 code would continue to exist, either as an LTS branch or as a separate project, but it would not see new feature development. With my red hat on, I'm already on the hook for supporting the xfree86 code until RHEL8 goes EOL anyway, so I'm probably going to be writing and reviewing bugfixes there no matter what I do. If someone wanted to actively drive xfree86 development going forward, great, awesome, please step forward. Given the near-total lack of anybody expressing interest in that since I stepped down as release manager ~18 months ago, I'm not sure such a person exists, but maybe predictable stagnation is what xfree86 ought to be at this point.
@adam jackson:
I guess with the "fork the server upstream" you mean creating a new project with the existing X server code that also provides an X server and is still under the X.org umbrella... but then why make it a separate fork/project?
If as things are right now the X server isn't going to gain any new functionality and features, then why not add that new functionality and features to it? And if it *is* going to get any new functionality and features (just not related to it driving the screen, input, etc) then why duplicate effort between the current X server and its fork?
Of course all these assume that there are people interested in working on the X server (or actually, any X server) and haven't stepped forward so far, but i'm not as willing to think that there aren't such people and i think it is more likely that the current X server works fine for most people who'd also be able to contribute to it so they do not feel the need to help at the moment - but might do so if things start to break down and/or new features of their hardware aren't properly supported.
Thank you Adam for all these years.
@BadSector The project named 'xserver' builds multiple X servers. Making a release entails making sure they all work well. Servers like Xwayland see a lot of development and would like frequent releases; servers like Xorg mostly don't, and since Xorg has an external driver ABI there's a non-trivial cost to rebuilding all the dependent drivers and (what's much worse) verifying that they all still work right, so they would like infrequent releases. The xfree86 model is basically impossible to put under meaningful CI.
Moreover, the kinds of refactorings to the server core - the code common to _all_ the servers - that I'd like to see are invasive enough that making sure xfree86 works afterwards represents a lot of effort for very little gain.
Splitting the projects lets us meaningfully decouple these concerns. The xfree86 code can remain cautious and conservative, and the Xwayland (etc) code can evolve as rapidly as needed. The two code bases will likely remain similar enough that important bug fixes can be cherry-picked across, at least until interest in xfree86 evaporates for good.
At 33 years it is at its best age. 15 years for development, 15 years for maturing and 15 years to become old. We have another 12 years to go before a replacement is mature and needed. In the meanwhile x.org is still the primary solution for showing windows on your screen. Wayland is but a distant "competitor".
Long live XClock!
I encourage young desktop users to download and install the Motif Window manager,MWM.i am pretty sure it is still available. After the shock of how amazingly simple it is, maybe you will grasp how extremely quick and small it is in memory and cpu resources.
Thank you for all your work so far - and into the future!
Have my thanks too! I use X constantly, including using $DISPLAY to run apps via SSH. I used to use GLX, although it tended to work best if one used display lists heavily, which is seemingly the opposite of where many went. The only other window system I've liked was NeWS, both for pixel independence and being able to push code to the other end and elevate the protocol above the level of graphics primitives. The remote use cases for GLX, X protocol, the X font server - and *especially* interchangeable window managers - have let me use scores of computers simultaneously on a single display (virtual since tvtwm appeared) for decades.
The only time I ever *really* got annoyed at X was the apparent inability to send events to specific windows in their own coördinate systems to skip all the window-target-of-mouse-in-display finding of XSendEvent(). It radially complicated going from gluUnproject() from a 3D-texture-mapped X window to the actual coördinates *in* that window, since one had to worry about an off-screen X display with windows that have to be popped to the top first to do the XSendEvent(). Meh. :-( My solution on the first pass was just to rewrite the X server to display into an OpenGL texture, which worked perfectly, but I really wanted per-window control.
But for any system to only really, truly disappoint me once in 30 flipping years is AMAZING. I can't... imagine... how to work without trivial remote access to apps. Which is one reason I'm worried about Wayland in general, and am hoping X stays around for a long time yet as a core component of whatever we're using, even if it's only a compat layer on top of whatever's underneath.
Thanks for all these years, the NVIDIA users among us can be very grateful to you for making their Linux experience on par with the Wayland folks when Wayland was only a serious option for AMD users.
"Unknown" argues for "forced server-side window decorations." I see this as a great divide for X users. I personally use the ctwm window manager and set it to mostly avoid window decorations altogether. Since resizing, moving or closing windows are not common operations, why take up screen real-estate with window decorations to accomplish that (along with many other functions I wire into keystrokes and mouse clicks)?
The ability to massively customize one's desktop is something I would sorely miss.
Thank you so much for your dedication over all these years. It's always been a pleasure.
> And I don't have any real desire to get there while still pretending that the xfree86 hardware-backed server code is a real thing. Sorry, I guess, but I've worked on xfree86-derived servers for very nearly as long as XFree86-the-project existed, and I am completely burnt out on that on its own merits, let alone doing that and also being release manager and reviewer of last resort.
I completely sympathise with this, having just retired as lead of a not-major but not-entirely-minor Linux distro, Adélie.
> using [Xorg] to drive your display hardware and multiplex your input devices is choosing to make your life worse.
I highly disagree, though I guess this is a very objective observation. None of the Wayland compositors work on my POWER9 at all (everything is messed up with big endian), none of the Wayland compositors work right on my laptop (nvidia), none of the Wayland compositors let me `--replace` as noted before, etc. etc.
I guess since I retired from being a distro lead, I have the cycles free to be the release manager and reviewer of last resort for the X server. I'd actually be very interested in making sure X11 is alive for another 33 years. Seriously. It runs everywhere, it is the common thing that means my 2003 iBook can run the same software as my 2020 Threadripper.
I also disagree about another point you made: that X11 existing is the reason Wayland compositors are still vastly unusable. glibc was a hot mess and musl managed to still attract people to make a better libc, and now glibc is even able to learn some of those lessons and improve itself. I don't know why the Wayland community cares more about flashiness and making GLESv2 a requirement to display a window on the screen, rather than "running decently everywhere possible". Maybe it's because I'm an old curmudgeon that enjoys maximal portability. I don't know.
Anyway, if you're still looking for someone to run an "X server that is still an X server like people know it now" project, feel free to reach out.
Running an X11 server is still the only way to have a color managed desktop on Linux and other similar operating systems. The bottom line is that suggested replacements (such as Wayland or XWayland) were not architected with color management in mind, and as a result are very difficult to retrofit with what is an essential feature of any modern graphical display system. Anyone running applications that require a color managed display either have to keep using X11, or abandon open source operating systems in favour of Microsofts or Apples offerings.
Thank you for your all hard work and dedication.
Thank you very much for the work provided for such server to survive.
Unfortunately, I'm still waiting for Wayland to provide standardized ways for remote access (for remote desktop) and window forwarding (such as how remoteX works).
I have multiple tools that work fairly well by creating and managing remote X sessions (different displays) on the same one for remote access purposes, gaming purposes, testing purposes, etc... Unfortunately, they need X because they need the concepts of remoteX to show a window from a server in the current $DISPLAY.
Thank you for your work, still.
It is the right time to take my hat down and thank for all the work. That is persistence! However it ends I wish all the good.
Post a Comment