Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

QtWayland 6.6 Brings Robustness Through Compositor Handoffs

blog.davidedmundson.co.uk

Post reply on HN
Print view View original

41–50 of 62 posts

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#41

Post by DyslexicAtheist »

hulitu wrote: post #37
pseudotrash wrote: post #33

Earlier quoted context omitted.

Nitpick: there is no "vs." ... because in the long run X11 is dead. After decades of serving us well it's not maintainable and not a good base to build anything on top that you want to continue maintaining in 5 or 7 years. Any warranty of a "cyber physical systems" is better off starting on Wayland IMHO What issues are you facing with screen recording? Can't say anything about NVIDIA because I avoid these chipsets li…

> X11 is dead. After decades of serving us well it's not maintainable Why not ? Is the wayland "maintainable " ?

The Real Story Behind Wayland and X - Daniel Stone (linux.conf.au 2013) https://www.youtube.com/watch?v=RIctzAQOe44

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#42

Post by akvadrako »

sho_hn wrote: post #35
throwaway1984s wrote: post #32

Earlier quoted context omitted.

https://arcan-fe.com/2017/12/24/crash-resilient-wayland-comp... 6 years ago and no toolkit modifications required.

Apples vs. oranges, though. If I read the blog post right, he's demonstrating that he can restart the main Arcan process while an auxiliary process called "waybridge" lives on, which for the Wayland clients is the actual compositor. This still requires the same type of "reconnect and restore" dance, but internal to Arcan-proprietary bits, pushing the problem up one level from the native Wayland exchange. The blog pos…

That's an irrelevant distinction. In both cases, if there is a crash in the bridging logic, it'll fail. In the QT case, the bridging logic is just living in each app process.

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#43

Post by akvadrako »

sprash wrote: post #34
agildehaus wrote: post #30

Earlier quoted context omitted.

Wayland sounds a bit like what Vulkan is to OpenGL? Am I anywhere close? I'm a novice when it comes to the implementation of compositors and display servers, but as a user it's been a far better experience than X11/Xorg ever was. Seeing this robustness video just proves it to me even more.

Rather the opposite. Wayland is a far more opaque abstraction layer than X11. Also the "robustness" is achieved with KDE/Qt specific protocols and as such has nothing to do with Wayland. Similar functionality could be achieved with X11.

X11 can't do this because memory allocations happen in the X server.

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#44

Post by type0 »

traverseda wrote: post #8
CoastalCoder wrote: post #4

Could someone explain the significance of this for Wayland adoption? As an outsider to the X11 vs. Wayland discussions, my impression has been that the main barriers to simply ditching X11 have been: (1) poor Wayland support in nVidia's proprietary drivers (2) Wayland's security model making some X11 use cases, e.g. screen recording, difficult or impossible. Does QtWayland 6.6 address either of those (and/or some oth…

Well KDE has been pretty good about implementing wayland extensions for things like screen recording, accessibility, etc. Gnome has also been implementing extensions but they tend to go off and do their own thing. The main barrier is honestly expecting a bunch of unpaid open source developers to go and re-implement everything. Stuff like barrier/synergy technically has the extensions needed to add in wayland support…

> There are common desktop extensions that Gnome just isn't really interested in developing.

In GNOME 45 all current extensions will loose backward compatibility, that's one of the yet more changes that will force many to migrate to other desktop environments

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#45

Post by SpaceNugget »

sprash wrote: post #27
kaba0 wrote: post #16

Earlier quoted context omitted.

> to reinvent the wheel Libraries are a thing > because the APIs are DE/Toolkit specific That’s false in itself, what do you think Wayland protocols are? They might add some DE-specific protocol for themselves, but I don’t see why that would be a problem. > standardization that X11 offered What standardization? A single implementation that does its thing is not a standard, by definition. > Also X11 was never "monolit…

> They might add some DE-specific protocol for themselves, but I don’t see why that would be a problem. What Wayland advocates don't see as a problem is the one of the main problems. I see a pattern here. > years of hard work. The only thing that takes "years of hard work" is writing a simple native Wayland client that takes screenshots.

https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.free...

Without knowing much about dbus, or freedesktop I was able to make it work on a lazy afternoon. And it worked for me in wlroots and on gnome, I am assuming kde also implements it. How were you trying to do it that it took so long?

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#46

Post by charcircuit »

agildehaus wrote: post #30
sprash wrote: post #10

Earlier quoted context omitted.

The severely limited scope of Wayland forces all DE vendors to reinvent the wheel and basically recreate their own X11. But this time it's worse because the APIs are DE/Toolkit specific without the standardization that X11 offered. Also X11 was never "monolithic" but in reality completely modular. It allows for example to change the window manager or even compositor at runtime without affecting running programs. For…

Wayland sounds a bit like what Vulkan is to OpenGL? Am I anywhere close? I'm a novice when it comes to the implementation of compositors and display servers, but as a user it's been a far better experience than X11/Xorg ever was. Seeing this robustness video just proves it to me even more.

>Am I anywhere close?

It's close, but since the services are much simpler you don't run into the problem of needing an older of magnitude of more lines to draw a triangle.

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#47

Post by nsajko »

pseudotrash wrote: post #33
CoastalCoder wrote: post #4

Could someone explain the significance of this for Wayland adoption? As an outsider to the X11 vs. Wayland discussions, my impression has been that the main barriers to simply ditching X11 have been: (1) poor Wayland support in nVidia's proprietary drivers (2) Wayland's security model making some X11 use cases, e.g. screen recording, difficult or impossible. Does QtWayland 6.6 address either of those (and/or some oth…

Nitpick: there is no "vs." ... because in the long run X11 is dead. After decades of serving us well it's not maintainable and not a good base to build anything on top that you want to continue maintaining in 5 or 7 years. Any warranty of a "cyber physical systems" is better off starting on Wayland IMHO What issues are you facing with screen recording? Can't say anything about NVIDIA because I avoid these chipsets li…

This is just FUD.

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#48

Post by tadfisher »

type0 wrote: post #44
traverseda wrote: post #8

Earlier quoted context omitted.

Well KDE has been pretty good about implementing wayland extensions for things like screen recording, accessibility, etc. Gnome has also been implementing extensions but they tend to go off and do their own thing. The main barrier is honestly expecting a bunch of unpaid open source developers to go and re-implement everything. Stuff like barrier/synergy technically has the extensions needed to add in wayland support…

> There are common desktop extensions that Gnome just isn't really interested in developing. In GNOME 45 all current extensions will loose backward compatibility, that's one of the yet more changes that will force many to migrate to other desktop environments

There is a really good technical reason for that, and honestly, I don't want to use extensions that aren't being maintained as new versions of Shell get released.

The reason Gnome doesn't have a stable extensions API is the same reason extensions are powerful: extensions are user code running in the same JS environment as Shell and can do anything. I think that's a decent tradeoff for a best-effort system without a ton of manpower and ecosystem involvement.

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#49

Post by tadfisher »

hulitu wrote: post #37
pseudotrash wrote: post #33

Earlier quoted context omitted.

Nitpick: there is no "vs." ... because in the long run X11 is dead. After decades of serving us well it's not maintainable and not a good base to build anything on top that you want to continue maintaining in 5 or 7 years. Any warranty of a "cyber physical systems" is better off starting on Wayland IMHO What issues are you facing with screen recording? Can't say anything about NVIDIA because I avoid these chipsets li…

> X11 is dead. After decades of serving us well it's not maintainable Why not ? Is the wayland "maintainable " ?

The X11 maintainers said as much, then created Wayland?

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#50

Post by tadfisher »

yjftsjthsd-h wrote: post #24
kaba0 wrote: post #16

Earlier quoted context omitted.

> to reinvent the wheel Libraries are a thing > because the APIs are DE/Toolkit specific That’s false in itself, what do you think Wayland protocols are? They might add some DE-specific protocol for themselves, but I don’t see why that would be a problem. > standardization that X11 offered What standardization? A single implementation that does its thing is not a standard, by definition. > Also X11 was never "monolit…

> That’s false in itself, what do you think Wayland protocols are? They might add some DE-specific protocol for themselves, but I don’t see why that would be a problem. It sure looks like it's true, or did GNOME/KDE/wlroots manage to agree on a single screenshot API?

Yeah, XDG portals. Not something that's essential to the display protocol.

The idea that we need to be shoving tray icons and screen recording and permissions APIs into the display protocol is an Xism that folks need to let go. The display protocol should only deal with displaying things, meaning it's a standard way to give memory buffers to clients for them to draw into, and all the other crap can and should be handled elsewhere.

Post reply on HN