Announcement

Collapse
No announcement yet.

Weston's Full-Screen Shell Protocol Revised Again

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Weston's Full-Screen Shell Protocol Revised Again

    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

  • #2
    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.

    Comment


    • #3
      Originally posted by Rexilion View Post
      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.

      Comment


      • #4
        Originally posted by erendorn View Post
        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.

        Comment


        • #5
          Originally posted by Rexilion View Post
          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.

          Comment


          • #6
            Originally posted by Rexilion View Post
            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.

            Comment


            • #7
              Originally posted by stativ View Post
              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).

              Comment


              • #8
                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.

                Comment


                • #9
                  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.

                  Comment


                  • #10
                    Originally posted by Rexilion View Post
                    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.

                    Comment


                    • #11
                      Originally posted by erendorn View Post
                      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.
                      Ah, that explains it.

                      It wants to scale from a full fledged desktop to a small scale phone. Hence some stuff might look duplicate but will benefit certain scenario's. I can get into that. So, this is Wayland trying to be the same as Mir (or better) I guess... .

                      Comment


                      • #12
                        Originally posted by Rexilion View Post
                        Ah, that explains it.

                        It wants to scale from a full fledged desktop to a small scale phone. Hence some stuff might look duplicate but will benefit certain scenario's. I can get into that. So, this is Wayland trying to be the same as Mir (or better) I guess... .
                        No, that's for Weston.
                        Wayland has the full blown complexity, but because it is built on extensions, this complexity is optional (and extensible).
                        But wayland is just the protocol that clients can use, facing them you need a shell + compositor (the compositor is the one implementing wayland, but it also has impact on the shell).
                        Weston is the reference compositor for wayland, and although it is made to test functionality, it is quite usable (much like the Xorg server). It also has a mechanism to implement shells as Weston plug-ins. For example, Kwin will be implemented as a weston plug-in, but GNOME shell and Enlightenment will provide their own compositor. There is also an IVI shell plug-in, that is there to easily make OS environments for in-car devices (and also follow more closely the development standards of this industry). And then, there is this effort (for Weston) to provide pre-made functionality for cases where you don't need an environment at all (single app), and don't want to package the full gnome shell with you.

                        Comment


                        • #13
                          Originally posted by erendorn View Post
                          For example, Kwin will be implemented as a weston plug-in,
                          Are you sure about that? Do you have a source?

                          Comment


                          • #14
                            Originally posted by TheBlackCat View Post
                            Are you sure about that? Do you have a source?
                            I was sure, but it appears I was wrong

                            "No, KWin doesn’t “use” Weston. KWin is currently not yet a Wayland compositor, but can render to a Wayland surface instead of an X Overlay Window."
                            Martin Gräßlin, http://blog.martin-graesslin.com/blo...-frameworks-5/

                            So they use it at the moment, but will eventually provide their own compositor.

                            Comment

                            Working...
                            X