Xorg-Server 21.1.0
lists.x.org
lists.x.org
This release would not have happened if an effort to improve touchpad support in Linux was not funded for the past year and half. X server 21.1 makes touchpad gesture functionality support universal so it's much easier to offer consistent user experience for everyone and downstream developers are less reluctant to accept contributions.
Thanks a lot to all the sponsors: https://github.com/sponsors/gitclear
By the way, I wonder if there is demand for long-term maintenance of X server specifically. If you think you could contribute, maybe write here and if there's enough interest maybe it's possible to crowd fund something.
Maybe someone else would have stepped up, it's hard to say. However there was no release manager for the last several years, so the likelihood of this outcome would have been small.
The fact that Red Hat doesn't see much future in Xorg reflects this, rather than the other way around.
The other historically important corporate sponsor of Xorg development is Intel, and they seem to have reached the same conclusion.
(I work for Red Hat, but not on anything graphics related)
In my view there's absolutely space for Xorg in the future. Not every OS can run Wayland well and Wayland lacks some X features like network transparency.
I kinda hope it'll be backed by an organisation that's really keen on taking it forward. Augmenting the security model for example. And going back to some client rendering enabling features like anti-aliasing. I really think there's a lack of a viable remote display tool in Linux, where Windows has RDP. Block pushers are just too slow. VDI usecases are picking up again heavily, as do other security based techniques which could benefit, like remote browser isolation. Filling up my desktop with Windows running on a bunch of other computers is just so powerful.
So in other words I'd love to see an X12 that really moves towards the future. As I understand it, it's currently with RedHat which only sees future in Wayland and X is just on life support. I regret that because I see a lot of concepts in it that are still very valid and that have been lost in current alternatives.
https://wiki.freebsd.org/Graphics/Wayland
> While Wayland isn't ready for general use.
I can't readily find anything to indicate that this claim is out of date. I am aware that Wayland has been ported, but I have not heard of it being widely used, or being "production ready" as per se.
I think it's just a tooling problem; Apache Guacamole or Xpra can trivially stick windows in a browser window, VNC is... okay, not amazing, but passable, and even RDP can be made to work well on Linux, it's just that setting up any of those is a horrible pain on Linux (in my experience at least).
This, IMHO, is the most tragic loss in functionality desktop systems suffered.
It’s hard to justify being unable to do something we’ve done since the mid 90’s. The fact I could sit in front of a computer while running GUI software from different machines with different OSs as if they were local and that, now, the best I can hope for is what VNC gave me in the early 2000’s is nothing short of depressing.
Ah ... the good old days of IRC :)
If there is a better way to do that, I would welcome knowing it. Also, how one would achieve the same result for a Wayland program.
But I'm disappointed to see this myth keep popping up. X in general isn't "network transparent." Some X11 clients are, but only if they're built in a very specific way, which also tends to degrade performance locally.
Though part of this weirdness is due to the clunkiness of the way X forwarding is implemented, I wish there was a way to do it that didn't involve kludging around with environment variables. But that is what we are stuck with.
The xrender extension already supports server side drawing, anti-aliasing, transparency, gradients and so on. If you use for example Cairo with the xrender backend almost everything except the tessellation of splines will be rendered server side and has a rather efficient wire protocol which will be better than even RDP.
Edit: There has been some progress on GPU tessellation of splines, here is the most recent I can think of that was discussed here: https://news.ycombinator.com/item?id=23512897
According to benchmarks at the time 700-800% speedup.
> everything still needs to be serialized by the X protocol
Drawing in general needs to be serialized. As soon as the object tree gets too big parallelized rendering on GPU will be slower because of the huge amount of branches. The link you posted solves this problem somewhat but introduces a huge amount of complexity to the renderer (also the benchmarks are done on Windows which obviously has no xrender backend). Xrender on the other hand is a simple standardized solution that works today.
The recent developments here are actually because advancements showing that drawing didn't need to be serialized. The whole point of a GPU is to avoid that. I really don't know what to tell you, this is a complex problem, it's not solvable with simple solutions. The practice of the X server implementing the simplest possible solution has only really resulted in the complexity being moved into other projects, hence the existence of Wayland...
There is waypipe for that:
https://gitlab.freedesktop.org/mstoeckl/waypipe/ https://mstoeckl.com/notes/gsoc/blog.html
While I made some progress, it took much longer than I anticipated. I wonder if there's demand enough for X server on macOS to justify this work? Additionally, I'd have to find some funds to support my work as well, if I were to continue.
Hello and thank you for your work!
I'd love to see Xorg maintained at least.
It seems to me there still is dust to settle around wayland and xorg os getting little to no development.
Honestly, I'd just like xorg to keep working until the rest of the ecosystem has native wayland support.
Taking myself as an example: i just like xfce. Xfce is not on wayland yet. I don't care how buggy xorg is or how better wayland is, I won't switch if I can't run xfce.
Are we talking money, time, tooling, etc.? I'm rather attached to Xorg and would like it to keep going; what would be the most helpful?
I've setup Patreon page at https://www.patreon.com/p12tic
Certainly interested in that, though you're not clear whether it's time, money or community you're asking for.
Whatever happens, at some point momentum would have to gather outside of RedHat.
Still very happy with X here, and mainly running X applications across network rather than Qt/GTK toolkits and desktop environments.
All of these, but perhaps the most important would be money as it's the only thing that clearly indicates the level of community support. Once there's funding it's much easier to prioritize the work.
If it's the former then yes I'd back it depending on the price and what you're planning. With the latter I'm not in a position to influence my employer to participate.
Is X.org interested in administering this process?
I've created a Patreon page: https://www.patreon.com/p12tic.
I think it does not make sense to involve X.org as we all want as little bureaucracy as possible because all that time is better spent in software development.
Thanks!
In the meantime, I do need continuous Xorg updates. It's not by choice, Wayland just doesn't do the trick and is unusable on my machines until workflows like Synergy/Barrier are supported.
I really hope that there is an awareness in the DE communities that, for some use cases, Wayland is still not able to replace X and that left behind users are stuck with it until then.
https://www.sizeofvoid.org/posts/2021-09-26-openbsd-wayland-...
As someone who is still not using Wayland by default (I tried, but it regresses my setup), I am thankful there are still people involved on this. Good job, guys, you are appreciated. It's not just because Wayland looks sexier [0] that your work on the thing most people actually use is appreciated.
[0]: considering Wayland is more than a decade old by now and is still a huge mess, I guess I'll keep trusting old lady Xorg's experience to handle my workflow.
Moving to Wayland implies a complete rewrite of both is necessary.
Thank you all, devs!
Expand?
Could you explain why these concepts are so flawed, for those of us to whom it is not immediately obvious?
Additionally a Desktop system in general is much more than a bunch of bitmaps blittet together. Applications need to interact and such functionality has to be tightly integrated into the compositor with standardized protocols otherwise it will be impossible to have such functionality. Taking screenshots, drawing to the root window or knowing about coordinates of windows from other programs are some examples.
Oh and what gives, wayland just has an extension for this use case!
HDR is work in progress, there is nothing unchangeable in Wayland that would disallow different buffer types.
And people wonder why Linux lags behind Windows and macOS in terms of desktop smoothness and quality.
When all is said and done, you may as well remove the legacy cruft (drawing and filling primitives, the fucking X font architecture, etc.), delegate remote display to a protocol that is better designed to support it such as RDP or PipeWire that only gets loaded when necessary (which it's not for 90% of users in 90% of use cases), and streamline the display server itself to just that which modern clients actually need, and that's Wayland. Wayland just brings Linux, barely, up to the state of the art set by Windows, macOS, iOS, and Android -- which have prioritized perfect frames and smooth compositing and presentation since forever ago.
What I like about X, that is missing in Wayland, is that you no longer can run the X server on a machine and connect to clients (application) on another.
And if you think about it... this day with the cloud it could have been the killer feature! Nowadays is normal to have programs that run in VM in the cloud with a sort of remote desktop client. X11 would have been more performant even with not so fast network connection, because you have the rendering done in your local PC and only commands that pass on the network.
And if you think about it for a moment, isn't how web browsers work? Where you have the server that sends some HTML to the browser (nowadays JS and other stuff) and the browser doing the job of rendering? If you compare the X server to a web browser and the X client to a web site, isn't very similar? And this is the model that is winning nowadays.
Meanwhile we think about a new graphical server that cannot be used on a network, in a period where we are returning in the era of mainframes, when X was created (granted, nowadays is not a big PC in a room but a multitude of VM in the cloud).
The problem is not X, the problem is that X was never used at is full potential because we are so used to the (to me not optimal) model that Microsoft/Apple proposed to us.
You could have had monitors with an integrated X server, like in the past you had serial terminals, without fans, cables, and stuff on your desk, just a small ARM processor with a GPU to render things on screen. And a single network cable going to a computer that you had anywhere else in the house/company, or in the cloud.
No need for HDMI or other display interfaces, just run a network cable to each monitor, plug keyboard and mouse on the monitor, you are done. The GPU is in the monitor, doesn't it make more sense? How much money that could have saved to a company? It would have been more efficient than thin clients that connect to an RDP Windows machine that has to have a GPU just to render the remote session? Large installations like displays used for public information? Why use a full screen web browser, it's overkill, when you could have simply launched a X server on the particular display, then launched an application on a server and connected to the IP of that particular monitor to display everything you wanted?
The architecture of X was modern 40 years ago when it was invented. It in some ways predicted the future, and now that we are discarding it for something that tries to imitate Windows/macOS (badly, because these operating systems just works well, Wayland doesn't). Is it worthed?
Web browsers (and Electron) are replacements for NeWS, not X really. That's part of the reason why Electron won't go away, the architecture advantages are too great: have the server push running code to the local display to take advantage of local acceleration. NeWS was awesome in its day, and it kind of lives on in the form of browsers and Electron.
I don't really see the point of Wayland, to me X was just fine, sure, maybe it was time for X12, but was a completely new display server needed?
Only just barely. And they told us it could stop at any time. All the developer energy and support is behind Wayland, so that's what you should be using.
> I don't really see the point of Wayland, to me X was just fine, sure, maybe it was time for X12, but was a completely new display server needed?
The developers closest to the graphics stack say yes, so I defer to their expertise.
Really, this has been discussed to death many, many times. The arguments for X (or an X-like architecture) invariably come from people who are ignorant of the actual issues involved. Here's a video by Daniel Stone that addresses the main points; note that it was made 8 years ago and people are still arguing the points: https://youtu.be/RIctzAQOe44
As far as the graphics stack maintainers are concerned the debate is pretty much over, and Wayland won. X will get little to no developer attention going forward. Unless you want to take responsibility for the X server, your choices are to get with the program and get on Wayland, or find your use case completely unsupported.
(Note that when it comes to large projects like Xorg, corporate sponsorship is critical. The corporations are putting their money behind Wayland, not X.)
My impression is that latencies kill X performance. Having a server under my desk is one thing, but running even something like xedit halfway across a world is painful. It may be possible to update these tools to be less synchronous, but I’m not sure this is a great use case, certainly not for new applications.
> No need for HDMI or other display interfaces, just run a network cable to each monitor, plug keyboard and mouse on the monitor, you are done.
This would be great. Every monitor has at least a frame buffer and there is no need to push every pixel to the monitor 60 times a second. Worst case scenario is you have a sporting event where you need to push every pixel to the screen 60 or more times per second, but, most of the time, there’s no such need.
I'd love to see a new design with network transparency in the current internet age on the foreground.
I remember working in a room with 20 big-screened X terminals connected to one server over one shared 10 Mbit 10Base-T. And it worked amazingly well.
This was when Windows was in its infancy. I'd love to see that kind of vision again.
Nowadays with modern video compressing protocols also sending the video like RDP doesn't require a lot of bandwidth either and has an acceptable latency to be fair, but with X it would be even better (and it is, if you ever used X over ssh it works great)
This is true of RDP also. The initial versions of RDP were basically GDI over the wire. Of course it's been expanded since then to include DirectX calls, etc.
> The load on the network is lower.
That is incorrect. RDP is actually usable over an internet link; X11 is far too chatty and ridden with roundtrip latency for that use case. Even VNC does better over the wire than X.
> That is incorrect. RDP is actually usable over an internet link; X11 is far too chatty and ridden with roundtrip latency for that use case. Even VNC does better over the wire than X.
Yes I use it over an internet link and it works reliably.
But the main difference between RDP and X11 forwarding is that RDP forwards the entire session, while with X11 you forward the single application. With X11 forwarding you can indeed run on the same X server different X clients. That can be an advantage in an era of microservices, because you can see an X client as a microservice, and thus have a workstation (a X server) run a plentful of X clients each one on a different machine/VM/container.
That's not even true. The DRI3 X11 extension uses the exact same buffer swap mechanism like most Wayland compositors. Running locally you get the best of both worlds with X11 already.
> So, your X server is really effectively nothing more than a shitty Wayland compositor.
Couple of things: 1) you use DRI3, you lose network transparency. KDE apps run like a pig stuck in shit over network links because Qt on X was built to take advantage of the massive speed of DRI3.
2) Having the X server, window manager, and compositing engine in separate processes introduces latency due to context switches on the hot path. Wayland fixes this by making the display server, window manager, and compositor all one process.
Wayland solves problems you do have, you just don't know you have them.
No it is a much better Wayland compositor because unlike Xwayland it provides full backwards compatibility. You even need much less boiler plate code to get a file descriptor on X11 as compared to Wayland.
> Having the X server, window manager, and compositing engine in separate processes introduces latency due to context switches on the hot path.
This is only makes a difference for rare events like moving/resizing windows. For static window positions it is the exact same path as Wayland. In practice Wayland had historically even much worse latency than X11. This has only been fixed a few years ago. Latency has low priority for Wayland developers. And as such Wayland does not beat uncomposited X11 in latency to this day.
"This is only makes a difference for rare events like moving/resizing windows."
This is actually wrong, that type of split affects the rendering of every single frame. Also, uncomposited X11 is a bad idea for a number of other reasons, the only reasonable comparison to make there is composited X versus Wayland, which is what all the benchmarks I've seen are aiming for.
That also mean that you have a single process that if it crashes you loose your entire desktop session crashes. In the old X days I used to have my compositor crash a lot of times (good old days of Compiz with a ton of effects), but everything else was still functional, and I could simply restart it without loosing my entire desktop session. Or you changed the settings on GNOME, in the past just restart the WM, with Wayland of course you have to log out and login again.
Also, things that on X were simple (for example having an application that captures the screen) are difficult in Wayland, and the only way to do so is to incorporate that functionality into the window manager itself, that becomes a monolith very quickly.
Speaking about latency, to me is stupid. Like I said, in the old days of Debian 6, with a core2 and integrated graphics I used to run GNOME 2 with Compiz, I had smooth graphical effects and it did run fine, with a memory usage less than 100Mb in idle.
Nowadays we have hardware that is orders of magnitude faster and we have more problems that back in the days we didn't.
You actually can do this with Waypipe. Also, I'll mention this again: most Wayland implementations include the X server (as XWayland) and support this as a backwards compatibility option.
"If you compare the X server to a web browser and the X client to a web site, isn't very similar? And this is the model that is winning nowadays. ... Why use a full screen web browser, it's overkill, when you could have simply launched a X server on the particular display, then launched an application on a server and connected to the IP of that particular monitor to display everything you wanted?"
It's really not overkill though, people build web apps because the stack actually works well. Developers seem to really want to use those browser features. X on the other hand is very old and hasn't kept pace. The most obvious example I can think of is OpenGL: indirect GLX doesn't really work any more and hasn't for quite some time. It can't really be updated either without complicating everything, because any performant use is going to require loading code into the server. If you want remote GPU rendering, the best way to achieve that currently is to use WebGL and WASM (and later WebGPU when that's ready).
"we are discarding it for something that tries to imitate Windows/macOS (badly, because these operating systems just works well, Wayland doesn't). Is it worthed?"
Well, worst case scenario, Wayland is just a minimal way to get your browser window on the screen. I think this is another big misconception that people have. Wayland generally sits at a lower level in the stack than network applications, and it really has to be this way if you want to support hardware accelerated clients. Wayland is made for the case where you've already decided you have a GPU buffer and you want to put that on the screen. You could build something else on top of it that runs over the network (and this is what web browsers do, it's how XWayland works, it's how your VNC/RDP client works, etc) but somewhere in the pipeline those will need to have that fast local path where they render to a GPU buffer. And that's where Wayland comes in. It's not that the developers are trying to copy Windows/MacOS, it's that you have to do this if you want to get a good experience out of a modern GPU.
Or because there is not an alternative. Building graphical software is difficult because you have to interact with graphics. But, what if we have a protocol where you simply open a network socket and write some messages on it that says "write this text hear", "draw a line from X to Y"? Well, that is how X clients work.
> Wayland generally sits at a lower level in the stack than network applications
That to me is not a good thing. One of the main advantages of Linux/UNIX systems in the past was that X was a userspace application, and if X crashed the entire computer didn't crash, like Windows does, you restart the X server and you don't loose your work. Of course modern desktop environment crash with X, and that is a bad thing (but an X client can, and should, if the X server crash, just try to reconnect with the new X instance and redraw its window, like you reconnect to any other socket, or worse case scenario the program continue to run just without the GUI!)
I mean, that is also how the Web Canvas API works. If you want to control this with some messages on a TCP-ish socket then you can use websockets. The web browser already appears to be a superset of all the networked functionality of X.
"One of the main advantages of Linux/UNIX systems in the past was that X was a userspace application"
Wayland still is a userspace application too. The protocol itself is what is at a lower level of userspace than X was, of course the compositor can also implement high level features as it sees fit.
Yes, in a very inefficient way, you end up using 1Gb of RAM to do something that could have been done with 1Mb. Not important for desktops, but for embedded applications?
> Wayland still is a userspace application too. The protocol itself is what is at a lower level of userspace than X was, of course the compositor can also implement high level features as it sees fit.
Wayland is based on KMS that indeed is a graphic implementation in the kernel itself.
Modern Xorg is also using the KMS API. If you don't want any fancy features and just want to draw some lines then you probably want to skip Xorg and Wayland altogether and use KMS directly.
As an exercise I recommend to write a native universal applicable Wayland application that takes screenshots.
https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm...
A side note, but I really hate this ideology of 'x does one thing' outside of command line tools. This is a display server we're talking about. It should be able to enable normal desktop usage. Maybe not everything but core features like brightness control, screen sharing, screenshots, etc. Otherwise every wm that comes along is going to have to reinvent the wheel. There are tons of really great window managers out there, where the authors have looked at all the work it will take to get running on wayland, and have simply thrown their hands up in frustration.
It seems to me the only people that really benefit from the switch to wayland are the wayland devs themselves.
I've used gnome wayland, and sway. It's pretty damning that so few other window managers support wayland due to the sheer difficulty of the task.
Someone could build a compatibility layer based on picom or something, and that has been talked about for a while, but I don't think it will happen unless somebody funds it with some real dollars. And I'm skeptical of whether people using those window managers would even pay for it at all, based on the comments here it seems they would rather put the money towards keeping Xorg alive.
As someone who tried to do this... Ouch. Things like this are why X will still be around in 15 years.
Is the issue that compositors don't implement the `screencopy` protocol themselves or use the implementation provided by wlroots?
Ref: https://wayland.app/protocols/wlr-screencopy-unstable-v1
> "Warning! The protocol described in this file is experimental and backward incompatible changes may be made.
and the compositors were there way before 2018, so it's a bit too much to expect them to jump on the protocol.
In general, when your diagnosis to a problem is "the people using my product are all just too lazy to use it right", the problem is almost always that your product is the problem.
This has grown out to be a really great abstraction, where later multiple implementations can decide on new protocols/extensions to support. And they have already done plenty of such extensions, and they are compatible with each other. Remember, these are protocols. There is no need to implement them yourself, they can be made into a library, like wlroots, and you can build your compositor on that base, without any repetition. Also, multiple implementations only mean that there won’t be implementation-specific quirks.
As for screenshots specifically, while the base use case is trivial enough, recording screens are most definitely not (it needs proper synchronization). Pipewire is the project that can solve the issue perfectly, and it is indeed working correctly for like a year already, with screen share even in proprietary apps like teams.
If I understand the OP correctly, this sort of philosophy is deeply troubling to some people. For simplicity-oriented folks, trivial things should be trivial, as a matter of principle. If some trivial thing becomes slightly less convenient so that complex stuff may be possible, this is an unacceptable compromise; or at least a very worrying one. When taking static screenshots requires an entire "project" that is "just ready this year" , the threshold of unacceptability is long surpassed.
I get that wayland folks do not share this worldview and they want to do the right thing, even at the expense of sacrifying things that were previously easy. But, to other people, this rubs them in a very wrong way.
(Also, if we have a complex program that does all the things we need and a simple program+the complex one, we will have more complexity in the latter case so the previous one may be preferred)
I suspect those people don't matter to this conversation and would not be working on things related to Linux graphics at all. Once you start involving DRM and Mesa (or the proprietary nvidia drivers...), everything gets really complicated, and it's not easy to come up with a one-size-fits-all approach.
In particular: the lack of GBM/dmabuf support prevented having any kind of consistent API for efficient screen capture when using the nvidia drivers, but I think that is changing slowly.
Or, compositors can use these wonderful things we have called dynamic libraries, and simply link against implementations of that desktop functionality, such as wlroots -- which implementations, by the way, will be far less crufty and ad hoc than the equivalent X11 solution!
Much of the reason why X is the way it is is because back in the day, Unix lacked dynamic libraries in general, so in order to share an implementation of, say, graphics primitives, the best way was to write a server that implemented them and have clients communicate with that server. Now that we have dynamic libraries, we can share a single implementation of graphics rendering across multiple programs, and still have all the speed advantages of doing all the rendering client side!
Oh wait, the architects of Xorg designed Wayland!
X11 is a dead end. Its authors have deprecated it and offered an upgrade path: Wayland. Time to make like Elsa and let it go.
Xorg was designed decades ago. The architects of Xorg are dead, retired, or overwritten with their stupider future selves; you're talking about maintainers.
That's a mighty big hand you're waving.
Wanna use Firefox? gotta use gnome compostor for that! Chromium only works on KDE compostor, etc.
Is this a misguided fear, or do you anticipate it moving that way?
For the case of minimal window managers, there is wlroots, which is designed to be used to write a compositor. The first line of the wlroots repo[1] states: »Pluggable, composable, unopinionated modules for building a Wayland compositor; or about 60,000 lines of code you were going to write anyway.« And there are at least three[2] actively maintained compositors based on wlroots. Sway being the most popular, the one for which wlroots was initially developed for.
I believe that there won't be too many incompatibilities, because there are 3 (4, including weston) wayland compositors developed (Gnome's, KDE's & wlroots based), all three of them having their own use cases. Using protocol extensions only useable on one compositor would limit the app to a subset of Linux Desktops (and mobile), so if possible, most apps won't use them.
PS: I just remembered one case of fragmentation: Activity Watch, a tool to keep track which apps are used how long and to track idle times, won't be able to support Gnome (mutter), because Gnome dev's won't implement the necessary freedesktop protocol extension. Sway (and KDE?) does, so it works on them. One solution would be to write a Gnome Shell extension, but yeah, it's not as easy as on X.org (reason being privacy, in this case).
[1] https://github.com/swaywm/wlroots [2] https://arewewaylandyet.com/
it'll be fixed in about 1 year, nvidia finally got on board and built the APIs they needed to build. iirc KDE forced one of the nvidia devs to implement and then fix all the problems with nvidia on KDE wayland. basically the dev went back to nvidia and was like 'just implement the GDM apis'
There is nothing Wayland puts on the table that makes me compelled to go out of my way to use it.
autotools delenda est.
OTOH, while it's a PITA it's certainly one to which package maintainers are accustomed. autotools began to lose mindshare among younger programmers and with younger projects many years ago.
Both mean the project loses out on casual development -- ideally I would check out the "latest" code for the ecosystem, build it easily, verify my bug/problem still exists, make a change.
I'm not sure any friction at this stage is a good idea, so I hope the those with the experience of the codebase are making wise decision by changing the build process to one less widely available.
If your software is distributed as a source tarball, the build system follows established conventions like honouring $DESTDIR and doesn't do anything weird like download extra stuff from the internet, creating packages is super easy, at least with RPM.
Most of the time you just write out a bit of metadata, list your dependencies, use standard macros for your build system to do the actual building and then list the files that you want to use from the build (potentially putting them in subpackages), and that's it. RPM even supports specifying dependencies like pkgconfig(library) or perl(Thing) so that the actual package name that provides it does not matter.
I haven't done Debian packaging in ages so I don't know how it compares.
https://mesonbuild.com/howtox.html --- "How do I do X in Meson?"
:)
If it were a lighter replacement of electron, muon would be an appropriate (if counterintuitive) name.
There are so many mesons (pion, kaon, \eta, \rho, J/\psi, D, B, \omega,\upsilon), why not pick one of those?
From the Ubuntu repos, it looks like the top-level dependencies are Ninja and Python 3[1]. That doesn't seem particularly bad to me?
If so, that's unfortunate, but it isn't that different from what happens in autotools land -- I've had plenty of builds fail because the configure step fails to check for `$tool` and then expects it to be present at build-time.
Last time I built X by hand, there was one... one single X element the building of which depended on Python amongst the many, many components of X: XCB. So I had to install Python just for that one module; let me tell you I wasn't happy at all with such choice. Icing on the cake, the Python scripts were not compatible with Python 3, and also mixed spaces and tabs for indentation, so I had to write patches to get the stuff to compile.
On Qubes, a secure management environment runs as a VM called dom0 on Xen, a hypervisor. dom0 (or, on the upcoming 4.1 release, another VM) runs a Linux and manages the physical display and input devices, and an X server that only it connects to, for desktop operations. User-level applications are always run in other VMs that have no direct access to hardware. Each such appVM runs its own X server, headless. So, the only programs that talk to the physical X server are desktop widgets like the XFCE "panel". appVMs have no access to those.
When an app opens a window in its X server, a memory mapping is provided shared with dom0. The app's X server writes its pixels into that shared memory, and dom0 copies from that shared memory to a corresponding window on the physical display. dom0 delivers input events to an appVM's X when they occur within a window the appVM controls.
Importantly, each appVM has no access to any other appVM's X server, window contents, or the GPU, or input; everything it does other than making and deleting windows is via raw bits copied in memory without interpretation. Thus, appVMs are wholly isolated from one another except via (virtual) network routing.
You may object that this would make interaction very slow and laggy. Perhaps surprisingly, it does not, at least on modern hardware, and when running non-time-critical programs. Certainly, browsers (including youtube pages) and similar programs -- wireshark, transmission-gtk, gitk, evince, system-config-printer -- work fine. Even mpv does fine with movies at 2880x1620 resolution. (4K is just out of reach, on my 5y-old laptop.)
I don't know what the brave new world of Wayland will look like on Qubes. The same, I expect. Ways to securely virtualize access to the GPU are, to my knowledge, still a research topic. Maybe Vulkan operations can be forwarded safely? Each shader's memory would need to be protected from others', or operations sequenced with mappings swapped in and out.
Spectrum-OS is a re-imagining of Qubes with much lighter-weight app VMs that each host just one app, just while it is running, without each having a whole Linux kernel and systemd in it. Spectrum-OS is still under development.
E.g., I just mouse over to the right on my screen so I can move the mouse on my tv and then type in a search string to bring up a video to watch in the browser on the tv.
1. Can this be done with Wayland currently? (Currently = works in some lts version of a popular distro like Debian or Ubuntu).
2. Glad to see people still working on fixing bugs and making improvements in Xorg-Server!
Not sure if it works with Wayland either though.
https://github.com/Xpra-org/xpra-html5
and