> There are two approaches to this endorsed by different camps in Wayland: these Wayland protocols, and a dbus protocol based on Pipewire.
Pipewire approach looks the best for screenshots and video recording. I hope all Wayland compositors will settle on it.
> Secondary clipboard support <...> wp-primary-selection
I guess the standard is very recent. Last time I tried, KWin didn't support it yet.
> We fought long and hard over this and we now have a protocol for negotiating client- vs server-side decorations, which is now fairly broadly supported, including among some of its opponents.
A major problem with Mutter remains. Mutter developers don't want to depend on GTK for whatever reason, but so are SDL, mpv and other non-GUI applications and toolkits developers. The result are ugly looking windows for such cases in Gnome.
> You have to step up, though: no one working on Wayland today seems to care.
It's a problem with Wayland in general. The end user gets the short end of the stick, since with removal of some functionality that was in X, some use cases are cut off. But there is no one player like with X server. Tons of compositors are developed by different people. So even raising the issue let alone coming to some consensus takes a very long time.
I'm not saying Wayland isn't the way to go, just pointing out it's a very hard transition.
> Wayland doesn’t support Nvidia!
How is the progress of using Vulkan for Wayland compositors and avoiding the whole EGLstreams mess?
The problem is that it requires dbus, which not everone is on board with. Our argument is that the Wayland compositor should speak the Wayland protocol. That being said, the software I mentioned can be used to bridge between the two camps.
Following your edit: yes, the new standard protocol for primary selection is very new. But everyone supports the GTK protocol and the transition will not be visible to users.
Dude, so many edits: "But there is no one player like with X server" -> this player is wlroots
Oh my god man, stop editing your comment: "How is the progress of using Vulkan for Wayland compositors and avoiding the whole EGLstreams mess?" -> hard to say now, it's very very early.
A strong majority of Wayland compositors are using wlroots. Those that don't are in the minority, but they are mostly cooperative with wlroots aside from GNOME and E.
Looking at GOL stats for example, Gnome usage grew when Ubuntu switched from Unity to Gnome (on roughly the amount of Ubuntu users). Before that, KDE had higher usage overall. So my conclusion is that Gnome's majority today can be driven by implicit Ubuntu's choices.
AFAIK KWin mostly uses QtCore and maybe QtOpenGL and does most of the XCB/Wayland stuff by itself, precisely because they're a X11/Wayland compositor, not client.
But it's enough to be able to draw basic window decorations (i.e. border with title bar with control buttons). So why can't Mutter do the same to address the case of SDL-like windows that would prefer server side decorations?
> But it's not clear from it whether now there is a way to avoid using GBM or EGLstreams.
There's no avoiding GBM or EGLstreams, if you want a compositor, that can get a OpenGL/VA-API/whatever handle (as opposed to pixmap in system RAM) from the client and be able compose it on GPU (as opposed to being rendered by client by whatever means it wants, maybe transferred to system RAM, and then by compositor back to the GPU).
Do you mean even purely Vulkan based compositor will need GBM/EGLstreams? Or only when it needs to create an OpenGL context (which is obviously necessary to support as well).
Then I suppose Nvidia should finish their proposed common memory manager, which looks stalled now.
Even Vulkan compositor wants to compose OpenGL (or other non-Vulkan) clients, so it needs a generic way to work with a cross-API handles to buffers allocated in Video RAM. That's what GBM/EGLstreams/that stalled Nvidia memory manager solve.
Pipewire approach looks the best for screenshots and video recording. I hope all Wayland compositors will settle on it.
> Secondary clipboard support <...> wp-primary-selection
I guess the standard is very recent. Last time I tried, KWin didn't support it yet.
> We fought long and hard over this and we now have a protocol for negotiating client- vs server-side decorations, which is now fairly broadly supported, including among some of its opponents.
A major problem with Mutter remains. Mutter developers don't want to depend on GTK for whatever reason, but so are SDL, mpv and other non-GUI applications and toolkits developers. The result are ugly looking windows for such cases in Gnome.
> You have to step up, though: no one working on Wayland today seems to care.
It's a problem with Wayland in general. The end user gets the short end of the stick, since with removal of some functionality that was in X, some use cases are cut off. But there is no one player like with X server. Tons of compositors are developed by different people. So even raising the issue let alone coming to some consensus takes a very long time.
I'm not saying Wayland isn't the way to go, just pointing out it's a very hard transition.
> Wayland doesn’t support Nvidia!
How is the progress of using Vulkan for Wayland compositors and avoiding the whole EGLstreams mess?
I see this: https://github.com/KhronosGroup/Vulkan-Docs/issues/294
But it's not clear from it whether now there is a way to avoid using GBM or EGLstreams.