X.Org DMX Dropped After More Than A Decade Of Crashes

[creoflux]

All I could think was... What's my name?

[kpedersen]

So you're call Xorg itself a feature of Xorg? Not how that works.

That's like saying that Vulkan lacks features compared to OpenGL because it isn't a direct superset of OpenGL with backwards compatibility. Nobody is trying to build X backwards compatibility into Wayland, nobody wants to, and that's a good thing.

Well it kind of is a feature. Same with C and OpenGL. Having such a legacy of software and platform support available to them is further contributing to their lifespan like a vicious circle. Yes they may arguably be surpassed in many ways but they also tend to outlive everything in the end.

Xwayland is quite good evidence of this. You can bet on the successor to Wayland having an Xserver compatibility layer.

[Myownfriend]

Well it kind of is a feature. Same with C and OpenGL. Having such a legacy of software and platform support available to them is further contributing to their lifespan like a vicious circle. Yes they may arguably be surpassed in many ways but they also tend to outlive everything in the end.

Well no. C really has nothing to do with what we're talking about though, other than the fact that it's old like X. C isn't an API, it's a language that gets compiled. It really isn't the kind of thing that there will ever be a compatibility layer for. In the case of OpenGL, even if drivers dropped support it, compatibility for it would be maintained via software implementations and translation layers like Zink.

Xwayland is quite good evidence of this. You can bet on the successor to Wayland having an Xserver compatibility layer.

But again, XWayland isn't a part of Wayland just as Zink isn't a part of Vulkan.

If we look back at what you originally said...

That's a bit odd. XWayland only exists because there are useful things in X11 that Wayland lacks. If you remove all that, why even bother having XWayland?

...you're talking about XWayland as if it's an extension to Wayland that adds all the features that Wayland lacks. That's not what it is at all. XWayland is a Wayland client that looks like an X Server to an X client. It's an application. To act like it's adding functionality to Wayland is like saying a GameCube emulator is adding PowerPC support to the ARM or x86_64 ISA.

Admittedly, I've never even heard of DMX before it's removal, but it sounds like it's a server-side feature/utility that was transparent to the client so it's removal won't effect compatibility at all and wouldn't make sense to add to XWayland. Since XWayland IS a Wayland client, anything that provides similar functionality to DMX in an Wayland session would work just as well for XWayland or Wayland-native clients.

Similarly, Pipewire/xdg-desktop-portal can capture windows and screens in a Wayland session regardless of whether or not the applications are Wayland-native so there's no purpose for XWayland to support tools like xwd (X Window dump).

And really you can apply that to any utility that's part of Xorg.

[tomas]

You can bet on the successor to Wayland having an Xserver compatibility layer.

I'll take that bet. That will be in about 30 years, give or take. At that point I don't forsee any application that will require the X protocol. I'll be an old man by then. 😊

[Delgarde]

I agree, but I don't think it's temporary. Think about applications, both free and proprietary, that have been long abandoned and won't ever get ported.

Agreed. Long term, XWayland will exist for the same reasons that X11 servers exist for Windows and for Mac...

[kpedersen]

Well no. C really has nothing to do with what we're talking about though, other than the fact that it's old like X.

I didn't want to change the topic too much with that so I was probably quite vague. I can probably summarize it saying something like "The major weakness of Rust, Python, etc is that they are not C". They will forever be wrapping around C libraries (via bindings) and never moving on. It is why they all drag in so many additional dependencies and even have language specific package managers to make up for this flaw (yes, the flaw that they are not C as annoying as that probably sounds).

This is the same with OpenGL. Notice how every graphics system now supports an OpenGL wrapper one way or another? So from this you can probably assume that OpenGL as an API specification will outlive Vulkan, Metal or DirectX because those guys are much more difficult to layer ontop of others (in many ways they are too low-level and flexible).

I'll take that bet. That will be in about 30 years, give or take. At that point I don't forsee any application that will require the X protocol. I'll be an old man by then. 😊

Lets meet back here then

[mppix]

Well it kind of is a feature. Same with C and OpenGL. Having such a legacy of software and platform support available to them is further contributing to their lifespan like a vicious circle. Yes they may arguably be surpassed in many ways but they also tend to outlive everything in the end.

Xwayland is quite good evidence of this. You can bet on the successor to Wayland having an Xserver compatibility layer.

Why are you barking up this tree?
This is long decided. X11 is done as default. If you needed any demonstration even Nvidia had to give in and support it pretty much the exact way upstream decided: GBM.
Also, most apps don't even care - they will simply make the transition with their GUI framework.

It is a bit sad watching you make statements in every Wayland and Xorg thread trying to make X11 important again. Truth is, its faith is sealed. It will be more or less like in Mac - useful for a while and slowly faint away.

Look at the upsides. I know you care about remote desktop. Wayland will enable remote desktop solutions in ways that X11 never could (at least not with serious workarounds) - for privacy reasons. For example it is now feasible to implement multiuser remote desktop login and potentially every system can act as a remote desktop server..

[Myownfriend]

I didn't want to change the topic too much with that so I was probably quite vague. I can probably summarize it saying something like "The major weakness of Rust, Python, etc is that they are not C". They will forever be wrapping around C libraries (via bindings) and never moving on. It is why they all drag in so many additional dependencies and even have language specific package managers to make up for this flaw (yes, the flaw that they are not C as annoying as that probably sounds).

That's still very different from what we're talking about with X. Many libraries are written in C or other low-level languages because they're performant, don't require an interpreter to be used, or because other languages didn't exist at the time. These other languages interface with C libraries for compatibility with those libraries but not backwards compatibility. C, despite it's age, is still a current programming language.

Also C, Python, Rust, etc, are all languages not protocols. XWayland doesn't extend Wayland. There's no X libraries that Wayland might use to gain features. XWayland is strictly an application.

X isn't a language, it's a protocol. DMX isn't part of the X protocol, it's a utility that's part of one implementation of X server.

This is the same with OpenGL. Notice how every graphics system now supports an OpenGL wrapper one way or another? So from this you can probably assume that OpenGL as an API specification will outlive Vulkan, Metal or DirectX because those guys are much more difficult to layer ontop of others (in many ways they are too low-level and flexible).

Why would it outlive Vulkan? How are you describing the "life" of OpenGL in this example that wouldn't grant Vulkan a similar or longer lifespan?

And still, these are APIs not protocols.

[rabcor]

Good with code removal so there can be a smaller code base which is easier to maintain and have less bugs and security vulnerabilities. 👍

Maybe more stuff can be removed, so that it can only have the stuff that's strictly necessary for XWayland.

Wasn't XWayland separated from X? As in it's it's own independent project now and not reliant on Xorg even being installed at all?

So what would the point of removing more stuff be?

Besides there are some things X does better than Wayland, just because wayland is the preferred default for most desktop users (that aren't bound to X due to nvidia) doesn't mean that X should be shaved down to just serve as an extra for Wayland.

I think even after we reach the point where XWayland is no longer needed due to most applications supporting Wayland out of the box, there will probably still be a lot of people that prefer X over Wayland, at least for some purposes.

[Myownfriend]

Wasn't XWayland separated from X? As in it's it's own independent project now and not reliant on Xorg even being installed at all?

So what would the point of removing more stuff be?

Yes it's separate in that XWayland doesn't need Xorg installed to run, but XWayland is still part of the XServer git and pulls in headers from it's parent directories. But you're right, most things being removed from Xorg shouldn't effect XWayland.

Besides there are some things X does better than Wayland,

Like what?