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 ASAP. (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 monitors. 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 recording. 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 standard. 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. --- [1]https://github.com/wtay/pipewire [2] D1230 et al. We should try and merge these at some point. ---
