Wayland Clients Can Now Survive Qt Wayland Crashes / Compositor Restarts

[Myownfriend]

Yeah, considering that X11 window managers have nothing to do with Wayland compositors.

His point went right over your head.

Wayland compositors are basically complete Xorg Server implementations. The complexity and the amount of features that need to be implemented are staggering.

Yea? Tell me more lol I thought you said Wayland is bare bones and featureless compared to X11 so why would be as complicated as Xorg?

Maybe start with the basics before heroically raging out about something you completely fail to understand.

Irony.

[acobar]

Sorry, but your comment has absolutely nothing to do with what i said.

Really? From your comment:

Or maybe, as you pointed out, Sony should had approached Valve with AMD and do a partnership to bring Orbis to PC's and hit MS (and hopefully intel and nvidia) where it hurts.

[Myownfriend]

Ah, again the "it's just a protocol" cop-out. It never fails.
What i want to point out is, the "tools you take for granted" are reusable across toolkits and DEs. That doesn't seem to hold true for anything Wayland-related. There's wlroots, but it seems to cover very, very little, seeing as how major toolkits/DEs still have to fend for themselves.

What exactly is a cop-out about any of this? It's true. Yourself and so many other's constantly conflate X11 and Xorg. I'll hear people say shit like "With X11 I can just go into a console and type this and it'll do that." but no, X11 doesn't do anything, it has no code or commands. It and Wayland are just a standardized way that clients and compositors speak to each other... you know, protocol. When we're saying "protocol" we're not referring to anything different from when employees follow an agreed-upon process for doing something at work.

[Ironmask]

Yeah, considering that X11 window managers have nothing to do with Wayland compositors.

Wayland compositors are basically complete Xorg Server implementations. The complexity and the amount of features that need to be implemented are staggering.

Maybe start with the basics before heroically raging out about something you completely fail to understand.

The irony of this post is palpable.
Do you know why the entire Xorg team abandoned it? Because it's filled to the brim with absolutely useless and outmoded features.
Wayland has nothing Xorg has, in a good way. No ridiculous APIs to build shapes that nobody uses. No useless, insecure remote session system. Wayland composits. Xorg is basically Windows 3.1. To compound the point, Xorg literally has an ELF interpreter.
You seem to be very ignorant of what Xorg even is. There's a very good reason why it literally has a comment in it's source code that says "Here be dragons".

I can certainly excuse mistaking GNOME and KDE being "Wayland compositors that mimic Xorg", considering their complexity. Yes, they do have to implement their own convoluted custom APIs for things the Wayland protocol does not define. That does not mean Wayland protocols themselves need to implement those "missing APIs", there are plenty of other compositors (like Sway) that don't need to do those things. A Wayland compositor doesn't inherently need to mimic Xorg, it's just that GNOME and KDE are expected to support so many things, so many users, so much ancient software made for Xorg, that they have no choice.

[oiaohm]

Yeah, considering that X11 window managers have nothing to do with Wayland compositors.

https://en.wikipedia.org/wiki/Compositing_window_manager

There are two X11 Windows managers.
The historic X11 Windows manager and the X11 compositing windows manager.

Wayland compositors have way more in common with X11 compositing windows managers.

Wayland compositors are basically complete Xorg Server implementations. The complexity and the amount of features that need to be implemented are staggering.

X11 compositing windows Managers where already close to a 95% re-implementation of Xorg server features of importance.

https://people.freedesktop.org/~dani...ayland-x11.pdf page 82 on.
Yes 2013 this was known.

The number of features you need to implement so wayland works is wayless. Xwayland means that wayland compositor does not have to deal with with the 12 uniqiue copy/paste implementations of X11 and so on. Turns out making a functionality X11 compositing windows manger requires lots of stuff.

Something had to change X11 compositing windows managers have been getting more quirky as the X11 protocol just keeps on growing with more and more unique stuff to deal with.

Something else to take serous note of avis. Wayland compositors don't want to implement drivers. Input is done by libinput. Graphics drivers done by mesa/kms/drm... Yes Nvidia really did not like when Wayland compositor developers were like no you will not be supporting per Wayland compositor drivers.

avis I guess are too young to remember you wanted accelerated opengl you had to buy a closed source X11 server implementation this is before 2000 Linux.

Wayland compositors ideal world x.org X11 modesetting driver on bare metal would be the only driver you need. X11 server has a lot of extra complexity that should be abstracted away by libraries.

[oiaohm]

I can certainly excuse mistaking GNOME and KDE being "Wayland compositors that mimic Xorg", considering their complexity. Yes, they do have to implement their own convoluted custom APIs for things the Wayland protocol does not define. That does not mean Wayland protocols themselves need to implement those "missing APIs", there are plenty of other compositors (like Sway) that don't need to do those things. A Wayland compositor doesn't inherently need to mimic Xorg, it's just that GNOME and KDE are expected to support so many things, so many users, so much ancient software made for Xorg, that they have no choice.

No there is a horrible side-effect with Gnome and KDE you don't see with weston and sway(wlroots). The gnome and KDE wayland compositors are based on their X11 compositor code bases. So both gnome and kde wayland compositors have a cargo cult problem where they have brought a few more things with them than they really need.

Yes some features gnome and kde both implemented as Wayland protocol extensions have being removed and replaced by dbus generic stuff.

Gnome and KDE wayland compostitors are based on a part intended for X11. That part when running on X11 when it starts up bipassed like 98% of X.org server anyhow.

KDE/Gnome Wayland compositors were not mimic of Xorg the mimic is the KDE/Gnome X11 compositors that KDE/Gnome wayland compositors are based off. We can hope that future refactors change this.

[avis]

The irony of this post is palpable.
Do you know why the entire Xorg team abandoned it? Because it's filled to the brim with absolutely useless and outmoded features.
Wayland has nothing Xorg has, in a good way. No ridiculous APIs to build shapes that nobody uses. No useless, insecure remote session system. Wayland composits. Xorg is basically Windows 3.1. To compound the point, Xorg literally has an ELF interpreter.
You seem to be very ignorant of what Xorg even is. There's a very good reason why it literally has a comment in it's source code that says "Here be dragons".

I can certainly excuse mistaking GNOME and KDE being "Wayland compositors that mimic Xorg", considering their complexity. Yes, they do have to implement their own convoluted custom APIs for things the Wayland protocol does not define. That does not mean Wayland protocols themselves need to implement those "missing APIs", there are plenty of other compositors (like Sway) that don't need to do those things. A Wayland compositor doesn't inherently need to mimic Xorg, it's just that GNOME and KDE are expected to support so many things, so many users, so much ancient software made for Xorg, that they have no choice.

You're excellent at whataboutism: "Xorg is abandoned crap, thus the Wayland protocol is infallible". Kudos! The fact that 10 years after Wayland was released we have the only usable rich DE for it does not really raise any blaring alarms for the people who preach it day in and day out.

The fact that Qt has created clutches for the Wayland protocol, and so will have all the other Wayland toolkits later on, again doesn't ring any alarms.

The fact that a metric ton of features are reimplemented over and over is just fine.

You know what distinguishes successful OSes from the likes of Wayland? Rich freaking APIs. You don't code this crap for Windows, MacOS, etc. You're given APIs which survive a window manager restart right from the box. No one is even talking about it. No one even knows such an issue ... exists.

"In Wayland a single toolkit heroically resolves the core glaring issue, OMFG, that's so great!"

A neat graphical protocol. Woah. Over and out. This is disgusting and beyond stupid. Enjoy Gnome-Wayland.

[oiaohm]

The fact that Qt has created clutches for the Wayland protocol, and so will have all the other Wayland toolkits later on, again doesn't ring any alarms.

https://invent.kde.org/plasma/kwin/-/wikis/Restarting

Make perfect sense thinking it a particular KDE developer who started the process of making Wayland Compositors being able to die and applications keep on running. But Qt is not where the key modifications are.

In Wayland a single toolkit heroically resolves the core glaring issue, OMFG, that's so great!

This is horrible miss representation.

libwayland-client and libwayland-server libraries at the core of Wayland were modified to address large amount of this issue. This is qt modified to obey the requests libwayland-client provides like it would have to obey the requests under Windows and MacOS when Windows manager or compositor on these platforms crashes and restarts as well. There is a reason why the number of lines of modification to qt to make this work

https://codereview.qt-project.org/c/qt/qtwayland/+/377104

This is the code alteration to make Qt work. +648 -29 Yes well less than 1000 lines of code. Yes about 410 of that 648 is testsuite.

avis making a toolkit support living past Wayland compositor death is less than 1000 lines of code with majority being testsuite. Yes the code is that small due to the fact the 99% functionality has to already exist for the toolkit to be cross platform and work on Windows and MacOS.

Resolves a core glaring issue is not really right. This is just on support for using the functionality they implemented for Windows and MacOS decades ago on Linux for Wayland. Under windows and Macos when compositor or windows manager dies the toolkit gets a stack of instructions of windows or macos to resend a stack of stuff and dispose of a stack of stuff that is now defunct and all we really need is this functionality to work with Wayland restart instructions that are in the Wayland-client library for client applications. There are a few things in the libwayland-server library for picking up a socket form a Wayland compositor that has died.

avis I would not say heroically its more like finally agreeing to accept a minor patch that removed a major functionality problem. The heroically resolving issue patch is in libwayland-client and libwayland-server particularly on how to defunct buffers so applications would not:
1) would not leak memory
2) Segfault or other horrible things if applications happened to use a defucted buffer before it was replaced.
3) correct replacement of buffers.
None of those 3 points is in qt/gtk/sdl or any of the others made support Restarting Wayland compositors instead are in fact in the commonly shared toolkit here just like Windows and Mac OS. Other thing the modifications to Wayland core libraries is also still under 2000 lines of code to make this stuff work.

So less than 100000lines of code is this functionality in all common Linux applications and toolkits. The problem is getting all these small changes approved and mainlined.

libwayland-client and libwayland-server was the first to get the functionally followed by mesa. Qt is also not the first here.

Now I don't know how light in code changes making X11 protocol and x.org X11 server would be to make this resistant to application death causing data loss but is most likely the X11 protocol complex mess of protocols will make it insanely hard to pull off.

[eagleoneraptor]

Yeah, considering that X11 window managers have nothing to do with Wayland compositors.

Wayland compositors are basically complete Xorg Server implementations. The complexity and the amount of features that need to be implemented are staggering.

Maybe start with the basics before heroically raging out about something you completely fail to understand.

Is it possible to not start raging out in this forum? It's a freaking rage factory.

I know pretty well what a Wayland compositor and X11 window manager (plus X11 server) are. My point is, even if each Wayland compositor has to implement most of the features from the X11 server/wm/compositor combo again and again, that problem is still not technical, but a problem of fragmentation, because we could have easily one compositor or one library for compositors to rule it all, yet we don't have it (even the linked issue complained of having too few, lol), but that's related to organization and lack of a unified vision for the Linux desktop, and that's what we want, we want choice, but we can't complain we can't have both, resources are scarce.

[eagleoneraptor]

and that's what we want, we want choice

I correct myself here, I don't want choice, choice complicate things, I want simplicity, sane design, something competitive and well funded.