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

31–40 of 62 posts

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#31

Post by sho_hn »

sprash wrote: post #28
sho_hn wrote: post #20

Earlier quoted context omitted.

> But this time it's worse because the APIs are DE/Toolkit specific without the standardization that X11 offered. On this one: It's not really that different. Very little if any KDE code made any direct calls to Xlib or xcb past the very early years. Most of this was also hidden by Qt abstractions, and toward app/shell devs most certainly by further KDE library abstractions. Directly interacting with X11 was an almos…

> Wayland has some widely-respected values around who gets to introspect what state and who acts as authority And this is a main problem. These "widely-respected values" (by whom actually?) make sure that you can't implement an app that allows dragging tabs from one window to another because windows are not allowed to know their absolute coordinates. > But there's a lot of value in agreed-upon protocols, and X11 also…

> These "widely-respected values" (by whom actually?) make sure that you can't implement an app that allows dragging tabs from one window to another because windows are not allowed to know their absolute coordinates.

I don't understand why they would need to for a DND operation (or why a custom protocol would be needed - X11 didn't need one for the same use case either).

> Wayland as such has zero value. I still can't decide that is designed by retarded morons ore geniuses as means of sabotage. Either way it destroys the FOSS ecosystem very effectively. Good job!

This comes across as very irate and emotional. I'm glad you care about the FOSS ecosystem this deeply. I do as well, and have spent 20 years of my career working on making it succeed. I'd rather we don't presume malice in each other.

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#32

Post by throwaway1984s »

renox wrote: post #23

This reminds me of Arcan where the goal number 1 is robustness, which is probably a good idea given the complexity of GUIs.

https://arcan-fe.com/2017/12/24/crash-resilient-wayland-comp...

6 years ago and no toolkit modifications required.

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#33

Post by pseudotrash »

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 like the plague (even for windows)

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#34

Post by sprash »

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.

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.

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#35

Post by sho_hn »

throwaway1984s wrote: post #32
renox wrote: post #23

This reminds me of Arcan where the goal number 1 is robustness, which is probably a good idea given the complexity of GUIs.

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 post being discussed here is about handling a crash in "waybridge" instead, so to speak, and having this ability in Wayland itself instead of requiring an additional abstraction and protocol.

Arcan can use multiple waybridge instances, e.g. one per client, to get some isolation between the clients (from the post), but it does start to sound a bit heavy perhaps (I don't know much about the inter-Arcan IPC though).

Cool stuff, though.

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#36

Post by hulitu »

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…

> expecting a bunch of unpaid open source developers to go and re-implement everything

We are really wondering why those "unpaid open source developers" would want to "re-implement everything". Fixing existing systems is hard, i presume. /s

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#37

Post by hulitu »

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…

> X11 is dead. After decades of serving us well it's not maintainable

Why not ? Is the wayland "maintainable " ?

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#38

Post by hulitu »

vidarh wrote: post #19
josefx wrote: post #7

> clients relied on memory stored by the Xserver, they made synchronous calls that were expected to return values, and multiple clients talked to multple clients. Wasn't that just an issue with the Xlib interface? I thought Xcb made everything async.

Yeah, very little in the protocol is sync. E.g. when you create a window the client picks the id, and you just go on assuming it will be created until/unless an error arrives. Only things explicitly querying for information is "somewhat" sync, but then too the reply will arrive back with a sequence number, so the client API can just keep returning events and hold on to the replies until you ask for them. X has many w…

> X has many warts, but it being synchronous isn't one of them.

I seem to remember that there was a command line switch to run X (or some clients) in syncronous mode. It was mostly used for debugging.

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#39

Post by hulitu »

sho_hn wrote: post #20
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…

> But this time it's worse because the APIs are DE/Toolkit specific without the standardization that X11 offered. On this one: It's not really that different. Very little if any KDE code made any direct calls to Xlib or xcb past the very early years. Most of this was also hidden by Qt abstractions, and toward app/shell devs most certainly by further KDE library abstractions. Directly interacting with X11 was an almos…

> Most of this was also hidden by Qt abstractions, and toward app/shell devs most certainly by further KDE library abstractions. Directly interacting with X11 was an almost-never occurence.

How do you think Qt draws on the screen ?

Re: QtWayland 6.6 Brings Robustness Through Compositor Handoffs

#40

Post by vidarh »

hulitu wrote: post #38
vidarh wrote: post #19

Earlier quoted context omitted.

Yeah, very little in the protocol is sync. E.g. when you create a window the client picks the id, and you just go on assuming it will be created until/unless an error arrives. Only things explicitly querying for information is "somewhat" sync, but then too the reply will arrive back with a sequence number, so the client API can just keep returning events and hold on to the replies until you ask for them. X has many w…

> X has many warts, but it being synchronous isn't one of them. I seem to remember that there was a command line switch to run X (or some clients) in syncronous mode. It was mostly used for debugging.

Xlib is peculiar in that it doesn't really expose you to the protocol very well. For starters, it doesn't immediately write every request. Partly because it saves bandwidth on slow networks to not send lots of tiny requests that might end up in separate packets.

Partly because the Xlib API is pathological in making it hard for you to minimize requests yourself. E.g. a lot of calls to modify graphics contexts can be batched up, but that requires Xlib to not worth requests immediately.

So hence there being some value on testing with different flush behaviour.

But this is Xlib specific, not really X.

Post reply on HN