GNOME Shell 3.35.3 Released With NVIDIA Driver Offloading, Fixes To Shell + Mutter

[Britoid]

Understandably some people are sore about something like that but at the same time Wayland is expected to work with any GPU. It requires it and so Wayland devs are technically the problem too. Well, I say Wayland devs are a punch in the face to their users. Its a lose lose situation.

Well yes, for Wayland (well its compositors) to be a success it needs to work with the vast majority of hardware out there, which includes Nvidia cards. That is why GNOME and KDE have both added support for EGLStreams (with Nvidia's help for the latter). However the smaller projects don't have this kind of man power.

This isn't perfect, and EGLStreams works quite differently from GBM.

Wayland compositors achieve a lot of benefits by working a lot closer with the kernel interfaces for driving graphics hardware (passive composition is a huge win), so a OEM like Nvidia which doesn't want the kernel to natively support it's hardware, is going to be more difficult.

[Hibbelharry]

You have to draw a line at some point between responsibilities: whats the scope of work for the device vendor, whats the scope of the operating system, whats the scope for the graphical subsystem of the OS,...

Wayland and it's ecosystem is designed in a way it works out mostly well for Intel/AMD and also others in the ARM and x86 world. It's nvidia to blame, because they don't get along, trying to push their own crap into common place, technically above their reach, not complying to common decisions of how things should be done, putting a maintenance burden on other developers trying to support a blackbox.

The one thing: Nvidia won't stop wayland efforts going on, slower than thought, but steady. nvidia will offer a worse experience, and will have a less good and useful product. Years ago, people had to avoid ATI/AMD when running linux, as it stands nowadays people will have to avoid nvidia.

I don't care, since I did the move long ago and switched all our company PCs to AMD Graphics, Notebooks to purely Intel. We do application development, but we don't need high performance 3D, just stable operation and low maintenance. AMD is painfree, even more than intel integrated graphics. On my private machine I'm running Vega64, since I do some gaming in my spare time, and I'm satisfied there, too.

Maybe the big announcement Michael did tell us to be upcoming this year will be a correction of their strategy because nvidia is going to fail in an important market, let's see.

[ix900]

So it's a flaw in the protocol? Please enlighten us how exactly. Because, you know, Wayland is a protocol.

I'm not going to argue. Like I said, some people are sore about it. Wayland without the X doesn't work with Nvidia GPUs so you figure it out with yourself. You can be sore about it on your own. Its what it is.

The one thing: Nvidia won't stop wayland efforts going on, slower than thought, but steady. nvidia will offer a worse experience, and will have a less good and useful product. Years ago, people had to avoid ATI/AMD when running linux, as it stands nowadays people will have to avoid nvidia.

Nvidia works fine on Linux using XWayland so unless XWayland goes away then there's no need to avoid Nvidia. If you want to do something else like use Wayland without the X sure but I won't be until they support Nvidia. That's what makes the world go round.

[Britoid]

Xwayland certainly does not work with the Nvidia driver.

[Gusar]

I forgot GNOME was closed source, sorry!

Gnome is not closed source, but it does require developers to have Gnome-specific code in their application, because Gnome doesn't play ball with wayland-protocols. It's a smaller effort than coding EGLStreams into a compositor, bit it's still effort, coding wise but also maintenance and quality-assurance wise.

[NotMine999]

"Be energy efficient: Drive a smaller shell."

[Britoid]

Gnome is not closed source, but it does require developers to have Gnome-specific code in their application, because Gnome doesn't play ball with wayland-protocols. It's a smaller effort than coding EGLStreams into a compositor, bit it's still effort, coding wise but also maintenance and quality-assurance wise.

Redesigning your compositor to add drawing code into a pipeline that isn't designed to handle drawing is a pretty big task. The goal iirc is for Mutter to not call into GTK.

If we follow your definition, Weston breaks the Wayland protocol, which makes no sense given it's the reference compositor.

[Gusar]

If we follow your definition, Weston breaks the Wayland protocol, which makes no sense given it's the reference compositor.

I never said Mutter "breaks" the protocol. It doesn't. Neither does Weston. But they are missing features, features that are described in wayland-protocols, and the lack of those features causes additional work for application developers.

You see not following wayland-protocols as not a big deal, because it's "optional". But that exactly *is* the big deal, that interoperability is considered optional. It shouldn't be. Just like EWMH isn't optional in the X world, so shouldn't wayland-protocols be optional.

And if it isn't possible to add SSD to Mutter due to design decisions, that's crappy design then. A consequence of the devs not willing to see that there is a world beyond Gnome out there.

[Britoid]

I never said Mutter "breaks" the protocol. It doesn't. Neither does Weston. But they are missing features, features that are described in wayland-protocols, and the lack of those features causes additional work for application developers.

You see not following wayland-protocols as not a big deal, because it's "optional". But that exactly *is* the big deal, that interoperability is considered optional. It shouldn't be. Just like EWMH isn't optional in the X world, so shouldn't wayland-protocols be optional.

And if it isn't possible to add SSD to Mutter due to design decisions, that's crappy design then. A consequence of the devs not willing to see that there is a world beyond Gnome out there.

Not many developers are going to be affected. If you use Qt, GTK or WxWidgets the toolkit already has you covered and that covers the vast majority of Linux applications.

Anything else? libdecoration or XWayland.

[Gusar]

As I already wrote on another discussion, libdecoration is a back-burner project that may or may not ever get done. And interfacing with that is still extra work and it's still just to placate one environment (few people use Weston as a daily driver). And presenting Xwayland as a "solution" when the goal is to move away from X to something allegedly better and more modern is... weird to say the least.

Besides, the issue isn't just window decorations. There's also idle-inhibit. Then there's cursor handling - configure a cursor in Gnome, but that's not what an application calling wl_cursor_theme_load will get, because Gnome has its own way of applying the cursor theme. This one isn't completely Gnome's fault though because there's no protocol for cursor handling, not even in wayland-protocols. Then there's the inability to use your own panel for example, you're stuck with the one the compositor ships with. There are one or two standalone Wayland panels out there, but they only work with wlroots-based compositors, presumably because a private protocol that's not part of wayland-protocols is used. Then, what about keyboard settings, is there an equivalent of xmodmap in Wayland, that would allow manipulating with the keymap in a DE-independent way, or are you stuck with whatever the DE's control panel exposes. Then there's display output configuration. There are a few xrandr-like commandline utilities out there, but they too only work with wlroots, while elsewhere you're probably again limited by what the DE's control panel exposes. Then... well, you get the idea already, though I could find more examples of were Wayland is just plain and simple limited, compared to what's possible in X. There's much greater flexibility in the X world, and interoperability remains because things are well defined at lower levels. Whereas in Wayland, even things that are already well defined are "optional", so you have to write compositor-specific code in your app. Or you're limited in your configuration options by what a compositor-specific control panel exposes.