I went to Guadec last week, wearing my Gnome hoodie to slip in
undiscovered. I made some notes from their wayland BOF.

Everyone was super helpful and awesome, some of these comments aren't
necessarily directly relevant to us, some are pre-warnings about some
changes that might be coming.


They also have a problem with menus and lacking correct transient parents -
they also have a hacks to guess in GTK.


Mutter is switching the way they do scaling to being from per window to per
output (i.e the way that weston and kwin do it)

XWayland with scaling has a bug. We [kwin] need to implement xdg-output
(I'll do that - David)


A lot of games want to change the resolution. For direct scanout that's
fine, but for xwayland that obviously doesn't work.

There is a plan to make xwayland "fake" changing the resolution when a
client makes an xrandr call and changing the xwayland buffer size.
This will require the compositor to do some work. Details to be discussed
on the wayland mailing list in due course.


Xdg potential changes

set_fullscreen() will need a way for an app to specify it spans multiple

I wanted to expand xdg_output with some monitor metadata
(isExternal/primary/whatever), mostly so we can have the primary display
info in Plasma without custom protocol code; and used set_fullscreen as an
excuse. They suggest maybe we want to extent set_fullscreen with requested
metadata, which is probably actually better.


Screen Recording / Casting

Mutter is going to use "pipewire" [1] for video buffer sharing.
Pipewire is dubbed as the new pulseaudio of video. (and rumour has it,
potentially replacing pulseaudo and jack too).
The docs right now are ridiculously sparse.

As a sharing protocol it seems pretty good, it has direct gstreamer sources
and sinks; an out-of-process vlc server was only 50 lines, same for screen

Mutter currently sends a file descriptor over DBus, and does the
glReadPixels/blit in the compositor.

I think it's quite interesting as it has the potential for common a common

It's not necessarily mutually exclusive with Oleg's GBM sharing [2]. We
already need a custom app to read the pixels and do the saving, instead it
could "just" proxy them into pipewire and let someone else do something
with the data.

They also didn't really have a particularly good plan of dealing with
multi-screen, just sending multiple buffers like we're going to do.


[2] D1230 et al. We should try and merge these at some point.


Reply via email to