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

[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. 😊

[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.

[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.

[creoflux]

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

[Myownfriend]

Every feature in Xorg that supports X11 applications.

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.

*waits for “apps can't be ported to Wayland because it's just a protocol” responses*

I have feeling you're referring to something I said. I had said that applications don't need to be "ported" to Wayland in the sense that you don't need a separate binary of the application to support Wayland. Tool kits like GTK and Qt take care of all or most of what's needed to get an application running in Wayland and is added as an option backend for that application. As a result, an application may be developed without Wayland in mind and still support Wayland natively. "Porting" tends to be used to describe the work needed to get applications to run on different operating systems or ISAs.

[kpedersen]

Any example of such a feature would do. Thanks.

The most obvious is the ability to talk the X11 protocol. All Wayland compositors lack this ability. Thus an Xserver called Xwayland is needed.

You can of course state that this was by design. But that won't magically make existing software not talk X11.

[tomas]

Every feature in Xorg that supports X11 applications.

Maybe I was unclear. You said "... useful things in X11 that Wayland lack".

What specifically are "those useful things" that you claim wayland lacks?

Any example of such a feature would do. Thanks.

[kpedersen]

Such as?

Every feature in Xorg that supports X11 applications.

[tomas]

... tomas mentioned the emulated input extension. You want to avoid that on Wayland, so I doubt XWayland will enable that. If you need it, you'll stick to X11. It isn't going anywhere anytime soon.

It will in fact be used in Xwayland to support the legacy X emulated input mechanism using the mentioned libei. But in a controlled and secure way unlike the X extension. See the blog post:

"Turns out we still have a lot of X clients around so somehow we want to be able to use those. Under Wayland, those clients connect to Xwayland which translates X requests to Wayland requests. X clients will use XTest to emulate input which currently goes to where the dodos went. But we can add libei support to Xwayland and connect XTest..."

[dekernel]

Such as?

Well, the last time I tried any type of desktop sharing, I was met with failure across the board. If I remember correctly, they haven't standardized the protocol extension for this.