Wayland's Fullscreen Shell Protocol Is Still Baking

[phoronix]

Phoronix: Wayland's Fullscreen Shell Protocol Is Still Baking

At the end of August there was a proposal for a Wayland System Compositor protocol but now those patches have been revised and are being put out as a new Wayland full-screen shell protocol...

http://www.phoronix.com/vr.php?view=MTQ5MzU

[blackout23]

What's the real world advantage?

[mannerov]

What's the real world advantage?

There are many.

For Prime support under Wayland, better performance will be under an embedded compositor, and you would like to
control the resolution of the screen to adapt it to the game you're playing right? Moreover you'll be able to have fancy options when
you have multiple monitors (have a part of the game on screen X, the other part on screen Y, ... or have a clone mode, ...)


Finally, KWin plans to be an embedded Wayland compositor, to avoid writing the drm code to bypass scanout, manage screens, ...
So it'll need these features.

[blackout23]

There are many.

For Prime support under Wayland, better performance will be under an embedded compositor, and you would like to
control the resolution of the screen to adapt it to the game you're playing right? Moreover you'll be able to have fancy options when
you have multiple monitors (have a part of the game on screen X, the other part on screen Y, ... or have a clone mode, ...)


Finally, KWin plans to be an embedded Wayland compositor, to avoid writing the drm code to bypass scanout, manage screens, ...
So it'll need these features.

Thanks!

"The message you have entered is to short...."

[Ericg]

What's the real world advantage?

Also, as David mentions in the original thread... writing directly against DRM/KMS is HARD. There's a lot of pieces you have to get 'just right' and its really easy to screw those parts up. He also mentions that at one point (I dont know if these plans hold true still, Martin could chime in if he sees the thread) Kwin was planned to be a weston plugin, not its own stand-alone compositor. This would mean Weston would be the "Full screen" shell. and Kwin would be the sub-compositor passing surfaces back up to weston to be displayed. EFL and Gnome have decided to write their own compositors, not as weston plugins.

The idea of a "full screen" compositor is just a way to kind of abstract away KMS and DRM. If you KNOW the layer between DRM/KMS and your compositor is done RIGHT (Probably why Kwin was doing a weston plugin) then you just have to write against the layer, not against DRM/KMS directly. And if that middle layer starts immediately, then doing something like Plymouth or a Gnome/KDE/EFL splash screen for login? Thats as simple as writing a wayland client, because youre just writing against the middle layer, not DRM/KMS.


If any of the devs want to chime in with anything I got wrong, more than welcome . But all info was taken from these two threads:

http://lists.freedesktop.org/archives/wayland-devel/2013-August/010720.html

http://lists.freedesktop.org/archives/wayland-devel/2013-October/011626.html

[plonoma]

I hope they have enough attention for being able to use multiple processors to do things (GPU's + CPU's), able to code in hardware, good responsiveness even under heavy load and efficient.

[Ericg]

I hope they have enough attention for being able to use multiple processors to do things (GPU's + CPU's), able to code in hardware, good responsiveness even under heavy load and efficient.

Multiple GPUs, and probably by extension CPU + GPGPU, "is a client problem". Wayland wants buffers filled with contents, end of story.

[xeekei]

Multiple GPUs, and probably by extension CPU + GPGPU, "is a client problem". Wayland wants buffers filled with contents, end of story.

That's the best part of it. KISS.