Wayland Protocols 1.38 Brings System Bell, FIFO & Commit Timing Protocols

[Errinwright]

Seems like a lot of the time progress seems slow because shit is complicated (way more than one might imagine and Dunning-Kruger is in full effect for most of us on this forum) and/or waiting on stuff elsewhere in the stack. Wasn't the latest triplebuffering delay requested by the author because of some technical issues regarding the nvidia driver.

(BTW, MD is posting here occasionally)

Exceptions do not make the norm, and your presentation of the topic is misleading. There are (and have been) multitudes of stalled propositions that objectively perform an X-desired feature, that does not meet subjective quality standards. Don't even get me started on window decorations.

[MastaG]

Seems like a lot of the time progress seems slow because shit is complicated (way more than one might imagine and Dunning-Kruger is in full effect for most of us on this forum) and/or waiting on stuff elsewhere in the stack. Wasn't the latest triplebuffering delay requested by the author because of some technical issues regarding the nvidia driver.

(BTW, MD is posting here occasionally)

I know it's complicated and I'm in no shape or form educated on how to implement a certain feature into some Wayland compositor.

But let me give an example:

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441#note_2236368

If the GBM spec doesn't say anything about synchronization you can be like:

1. Okay NVIDIA does it differently, lets take it into account and implement it so it works for both Mesa and NVIDIA.

2. Fuck NVIDIA, if is doesn't behave like Mesa then just flush it down the toilet.

Ya'll can hate on a binary driver as much as you like but that doesn't change that there's millions of devices with NVIDIA gpu's and the fact that NVIDIA is actually trying to actively support Wayland.
So it's perhaps a little disrespectful calling him a pain in the ass, but he could be a little bit more cooperative and think about what's best for all users, including those with NVIDIA devices.

I mean you want the desktop experience to be great for everyone.

[bearoso]

Well some of the Gnome devs can be a pain in the ass for sure.
If you look at the whole Gnome dynamic triple buffering MR.. then this dude named "Michel Dänzer" is always critizizing everything.

Michel Dänzer used to be at AMD and has a lot of experience with lower level graphics. From what I can tell, what he says is usually valid, even if it's not what you want to hear.

The current mutter triple buffering patch is a hack. The idea is to get weak Intel GPUs to ramp up their clock speed to maintain the max framerate. If performance is sub-refresh rate, when it switches to triple-buffering it tells the driver to draw two frames at once, briefly doubling the workload. This will raise the clock speed, but it's not sustainable. Once the swap queue is full, it returns to drawing one frame again and clocks drops off, creating a microstutter cycle. The more obvious thing to do would be to directly, not indirectly, instruct the GPU to raise the clock speed.

I'm guessing that the problem with triple buffering and explicit sync is that it's hard to tell whether it's working on the 2nd or 3rd framebuffer or keep track of resources.

*edit*: The problem vanvugt is having with NVIDIA seems to be that when turning on explicit sync support, it absolutely refuses to queue extra frames, and instead blocks. I would consider this acceptable, if not desired behavior for the layer it's operating on. It's certainly the opposite of when they used to force a triple-buffer queue on all of OpenGL and your only recourse was to inject glFinish with LD_PRELOAD everywhere.

[pharmasolin]

Gnome should become niche DE for enterprises which don't need latest features.
I hope valve will fix wayland and DEs which will implement proper protocols will win desktop users and those DEs will be gamer friendly as well as not buggy mess like mutter.

[fitzie]

i recently upgraded from fedora 39 to fedora 41, and after seeing a regression which is clear gnome did on purpose (applications without an xdg desktop entry show generic icon, ignoring wm_icon hints) I took a look at cosmic de alpha, to see what state of affairs it is in, as well as review the wayland protocols. I will say that it's obvious that gnome-shell is the most bug free desktop, but that only makes the fact that they keep breaking standards/rejecting their new replacement all the more disappointing. there's a wayland protocol that's directly relevant to this issue I'm seeing call call xdg-toplevel-icon, and the attitude from the gnome team is abysmal. not only do they not understand their own desktop (they state icons are only shown in the desktop overview, but, in fact, it's also used in the alt-tab menu, and of course if you use extentions it's very much used there too), but they also state that since we use it in one place we will not adopt this standard. just awful.

so I was pushed to try cosmic, and I have a lot to say about it's potential, but it clearly shows that they didn't come from the x11 world, there's just many things that would be a big pill to swallow for me to cutover any time soon. that being said, it's mostly usable today, which is nice that there's a viable stacking compositor besides kde/gnome for wayland.

[ahrs]

I know it's complicated and I'm in no shape or form educated on how to implement a certain feature into some Wayland compositor.

But let me give an example:

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441#note_2236368

If the GBM spec doesn't say anything about synchronization you can be like:

1. Okay NVIDIA does it differently, lets take it into account and implement it so it works for both Mesa and NVIDIA.

2. Fuck NVIDIA, if is doesn't behave like Mesa then just flush it down the toilet.

Ya'll can hate on a binary driver as much as you like but that doesn't change that there's millions of devices with NVIDIA gpu's and the fact that NVIDIA is actually trying to actively support Wayland.
So it's perhaps a little disrespectful calling him a pain in the ass, but he could be a little bit more cooperative and think about what's best for all users, including those with NVIDIA devices.

I mean you want the desktop experience to be great for everyone.

Where do you stop? Because Nvidia is not the only proprietary graphics driver in town, there are also various proprietary drivers for ARM devices. Have these been tested too? I think in an attempt to be great for everyone it will be very easy to stall indefinitely and then no progress gets done.

It's definitely much easier when all you have to care about is Mesa.

[curfew]

It's definitely much easier when all you have to care about is Mesa.

It's also easier for proprietary drivers to fix their own performance issues inside those drivers and not try to bloat random window managers and whatnots with their crap.

[reba]

so I was pushed to try cosmic, and I have a lot to say about it's potential, but it clearly shows that they didn't come from the x11 world, there's just many things that would be a big pill to swallow for me to cutover any time soon. that being said, it's mostly usable today, which is nice that there's a viable stacking compositor besides kde/gnome for wayland.

Let me drop a link to labwc

https://github.com/labwc/labwc

https://labwc.github.io/

Labwc is a wlroots-based window-stacking compositor for wayland, inspired by openbox.

It is light-weight and independent with a focus on simply stacking windows well and rendering some window decorations. It takes a no-bling/frills approach and says no to features such as animations. It relies on clients for panels, screenshots, wallpapers and so on to create a full desktop environment.

Labwc tries to stay in keeping with wlroots and sway in terms of general approach and coding style.

Labwc has no reliance on any particular Desktop Environment, Desktop Shell or session. Nor does it depend on any UI toolkits such as Qt or GTK.

[curfew]

But, Wayland designers glossed over the buffer transfer protocol in their original design of Wayland, so each GPU manufacturer created their own buffer transfer protocol. And, each one of those was bad.

So now, each GPU manufacturer is "bloating" Wayland compositors with their own mutually incompatible protocols for all functionality that Wayland initially omitted.

Maybe that's a thing that could've used some friendly consultation from GPU vendors then. Unfortunately the likes of Nvidia pretty much tried to nuke Wayland in the beginning instead of embracing it, so people with less know-how had to make do alone.

[loganj]

Maybe that's a thing that could've used some friendly consultation from GPU vendors then. Unfortunately the likes of Nvidia pretty much tried to nuke Wayland in the beginning instead of embracing it, so people with less know-how had to make do alone.

nuke wayland? i think its better to say that nvidia wanted to use different approach for wayland and the rest refuse it. well maybe i understood wrong