Weston's Full-Screen Shell Protocol Revised Again

[phoronix]

Phoronix: Weston's Full-Screen Shell Protocol Revised Again

The full-screen shell protocol for Wayland's Weston compositor will allow for features like splash screens and terminal emulators as simple full-screen clients, but the code is still being revised ahead of its hopeful merger...

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

[Rexilion]

Is a total bystander in all this, I would have expected fullscreen to be pretty easy to implement. Make a boolean switch for each window that wants to go fullscreen (or not) and boom you are done... . I wonder what makes it so hard.

[erendorn]

Is a total bystander in all this, I would have expected fullscreen to be pretty easy to implement. Make a boolean switch for each window that wants to go fullscreen (or not) and boom you are done... . I wonder what makes it so hard.

This is for making full-screen shells. Making a windows full-screen in a full blown shell (like a desktop shell) is indeed straight forward.
The idea is that sometimes the whole system UI is a single application, eg a virtual terminal (for a server), or a splash screen (during boot, replaced when the login manager is ready) or whatever. They want to make such case easier by creating a single app, full-screen shell.

[Rexilion]

This is for making full-screen shells. Making a windows full-screen in a full blown shell (like a desktop shell) is indeed straight forward.
The idea is that sometimes the whole system UI is a single application, eg a virtual terminal (for a server), or a splash screen (during boot, replaced when the login manager is ready) or whatever. They want to make such case easier by creating a single app, full-screen shell.

Ah, thanks.

But what's wrong with a shell and then displaying a full screen application? Are they considering a shell as overhead since the app can do without, and thus implement this? I'm confused.

[giucam]

Ah, thanks.

But what's wrong with a shell and then displaying a full screen application? Are they considering a shell as overhead since the app can do without, and thus implement this? I'm confused.

This is mainly to make the life easier for little compositors. With this protocol a compositor can just implement a Wayland backend and run on top of Weston instead of implementing all the X11, KMS, fbdev, RDP,... backends.

[stativ]

But what's wrong with a shell and then displaying a full screen application? Are they considering a shell as overhead since the app can do without, and thus implement this? I'm confused.

Generally one of the biggest problems with fullscreen is that you need to handle things like resolution change ? you need to take care that if you app changes resolution it won't affect your desktop (eg. you icons won't get reordered to fit a smaller resolution because of a full screen app), you need to make sure that if the application closes unexpectedly the resolution is restored (unfortunately that's still a common problem) also you need to handle input like alt-tab switching? There's a lot of things that can go wrong.

[old486whizz]

Generally one of the biggest problems with fullscreen is that you need to handle things like resolution change ? you need to take care that if you app changes resolution it won't affect your desktop (eg. you icons won't get reordered to fit a smaller resolution because of a full screen app), you need to make sure that if the application closes unexpectedly the resolution is restored (unfortunately that's still a common problem) also you need to handle input like alt-tab switching? There's a lot of things that can go wrong.

I don't quite understand how this would be such an issue going forward in Weston.
Can't the compositor simply create a (kind-of) virtual desktop for the fullscreen app?
That way if the application dies then the virtual desktop can also be destroyed and the previous desktop with it's original resolution can be restored.

The compositor is simply handling a group of shared memory resources anyway (compositing them together to be the main desktop) so it hardly seems like it's beyond the capability.
The use could even be presented with an option to prevent fullscreen apps and have them forced-windowed, and so it would be composited on the current desktop.

Any alt+tab would "minimize" the current window and/or switch back to the old desktop + old resolution.
Compositing would still work - the shared rendering memory would still be rendering at the smaller resolution, and you could even switch to windowed mode if you wanted to.

I agree that the protocol should be fairly simple to implement - "I want to be treated as a fullscreen app please" (with possibly a return of 'yep' or 'no' - although the app shouldn't need to act any differently so it shouldn't matter).
I also agree that the coding around said protocol would be harder to work out and fix any bugs (input grabbing etc).

[nanonyme]

FWIW typically the point of fullscreen rendering is that the compositor is bypassed because it slows down things a *lot*. (think of games) It already happens with X on all OpenGL compositors in fullscreen mode. I don't know if this is the main use case for this feature but I wouldn't be surprised if it was.

[giucam]

Why does noone go to read the proposed patches before starting typing nonsense?

The point of this protocol is *not* to deal with fullscreen apps. Period.
The point of this protocol is to deal with fullscreen *compositors* and fullscreen applications where only *one* app is supposed to be running, with no desktop behind it.

[erendorn]

Ah, thanks.

But what's wrong with a shell and then displaying a full screen application? Are they considering a shell as overhead since the app can do without, and thus implement this? I'm confused.

Complexity. A desktop shell (like plasma, or GNOME SHELL) must handle pointers, composition (between different windows), windows sizes and states (minimized) and possibly decorations, and its own privileged applications to deal with application rights, display settings, and thousands of other things. A phone shell can be much simpler (no compositor, pointers or windows sizes).
But if you want a shell to display something during the early boot sequence, or when debugging the kernel in a virtual console, you explicitly need something very simple.

If I'm not mistaken these patches come in a wider effort to provide a default shell that would be enough in such cases.