Announcement

Collapse
No announcement yet.

Wayland's Weston Compositor Introduces Kiosk/Fullscreen Shell

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

  • Wayland's Weston Compositor Introduces Kiosk/Fullscreen Shell

    Phoronix: Wayland's Weston Compositor Introduces Kiosk/Fullscreen Shell

    While there is already the Cage kiosk full-screen shell as well as the likes of Ubuntu's Mir Kiosk Shell, Wayland's Weston reference compositor now has its own implementation...

    http://www.phoronix.com/scan.php?pag...on-Kiosk-Shell

  • #2
    Nonsense rant:

    It just feels to me that Wayland was never designed for real desktop usage, but rather just for embedded and stuff like that.
    The lack of server-side decorations support is an example.
    The fact that most Wayland compositors use OpenGL ES rather than real OpenGL is another example.


    Heck, the Weston repo even has a whole directory for IVI (in-vehicle infotainment) support, which clearly indicates Wayland was never designed for the desktop.
    Oh, and look at the vast amount of experimental compositors out there.

    Comment


    • #3
      Originally posted by tildearrow View Post
      Nonsense rant:

      It just feels to me that Wayland was never designed for real desktop usage, but rather just for embedded and stuff like that.
      The lack of server-side decorations support is an example.
      The fact that most Wayland compositors use OpenGL ES rather than real OpenGL is another example.


      Heck, the Weston repo even has a whole directory for IVI (in-vehicle infotainment) support, which clearly indicates Wayland was never designed for the desktop.
      Oh, and look at the vast amount of experimental compositors out there.
      I think you got it the wrong way. As evidence I would say that Wayland works fine for the desktop, as mutter or KWin can say. I'm sure other window manager have similar programs.

      The thing is: X11 works badly for embedded plaforms and wayland is a good way to, for the very first time, propose an somewhat standardized alternative to the dreaded direct /dev/fb access. So as a consequence wayland is seeing some success in the embedded world. So it's not that wayland is designed for the embedded world; it's that the embedded world seized wayland because it's way better than X11 for this specific use case.

      Comment


      • #4
        Hopefully this will lead (quickly) to the rise of an on screen keyboard for use on touch screens that works in nearly universal situations. Currently, this is a very sore spot.

        Comment


        • #5
          Originally posted by tildearrow View Post
          Nonsense rant:

          It just feels to me that Wayland was never designed for real desktop usage, but rather just for embedded and stuff like that.
          The lack of server-side decorations support is an example.
          The fact that most Wayland compositors use OpenGL ES rather than real OpenGL is another example.


          Heck, the Weston repo even has a whole directory for IVI (in-vehicle infotainment) support, which clearly indicates Wayland was never designed for the desktop.
          Oh, and look at the vast amount of experimental compositors out there.
          The lack of server side decorations isn't an example of why Wayland isn't desktop friendly. If that was the case compositors on other platforms wouldn't be desktop friendly either.

          There's no reason to have the compositor drawing anything, it's just going to muck your compositor design and we see the reasons why KDE is so behind when it comes to their Wayland implementation compared to GNOME that stuck closely to the reference compositor.

          Time to follow other platforms and keep window creation where it belongs, in the toolkit.

          Comment


          • #6
            tildearrow Wayland is a protocol. Blame your compositor.

            Comment


            • #7
              I know I'm feeding the troll, but...

              144Hz, that's exactly the problem, way too much depends on what the compositor has implemented and how well it is implemented. In the X world, you can mix and match various components from different projects to create something that works well, because there's standards that facilitate interoperability. Not possible in the Wayland world, because protocols that would allow it don't exist. And may not ever exist. The issue with "blame your compositor" is that you don't choose just the compositor, you're forced to also take the entire environment that comes bundled with the compositor. And if that environment doesn't suit you, well, tough luck.

              And that's why people say Wayland is still not ready on the desktop even though it has widespread use in the embedded world, because on the desktop it's largely a "Gnome or bust" thing. And that's not a failing of other compositor developers, as you'll for sure try to spin it, it's a failure of Wayland to provide the required protocols. Some environments refusing to implement certain protocols that do already exist is another problem.


              Britoid, the problem with your argument is that there is no "the toolkit". While some will see this as a negative, I see it as a plus that you aren't limited to the whims of a single toolkit's developers and even have the ability to not use a toolkit at all. Such a multi-toolkit environment can work well, it just needs well defined interfaces at a lower level.
              Last edited by Gusar; 07-31-2020, 03:02 AM.

              Comment


              • #8
                Originally posted by Gusar View Post
                144Hz, that's exactly the problem, way too much depends on what the compositor has implemented and how well it is implemented. In the X world, you can mix and match various components from different projects to create something that works well, because there's standards that facilitate interoperability. Not possible in the Wayland world, because protocols that would allow it don't exist. And may not ever exist. The issue with "blame your compositor" is that you don't choose just the compositor, you're forced to also take the entire environment that comes bundled with the compositor. And if that environment doesn't suit you, well, tough luck.

                And that's why people say Wayland is still not ready on the desktop even though it has widespread use in the embedded world, because on the desktop it's largely a "Gnome or bust" thing. And that's not a failing of other compositor developers, as you'll for sure try to spin it, it's a failure of Wayland to provide the required protocols. Some environments refusing to implement certain protocols that do already exist is another problem.

                Sorry but 144Hz is right most likely not for the reasons he thinks. And you need to remove your rose colour glasses about X11 because the compositor screws things over..

                Lets say you need a desktop with full Accessibility features on Linux does not matter of it X11 or Wayland it is Gnome or bust. X11 does not provided the required protocols for Accessiblity yes its AT-SPI2 stuff that is between the assistance applications to dbus to the applications in use to get information. Issue is since X11 servers stopped rendering fonts the result has been client(by X11 define) rendered fonts that means asking what Text is on X button from X11 server tells you basically nothing. X11 protocol has trimmed it supported protocols to the point you are doing a hell of a lot around the outside of X11.

                Does X11 protocols provide any interface for doing proper GPU accelerated screen capture again the answer is no. X11 mandates that all screen be merged into a single image this is highly not useful either if you have one monitor that is HDR and one that is not so another case of horrible no. What about mixing high dpi monitors with old standard monitors again the X11 protocol single screen idea comes back and be a nightmare..

                Gusar once you start looking closer X11 has not been working well at all. Now fixing X11 is going to basically gut it. Like screen capture using pipe-wire allows using GPU accelerated screen capture. AT-SPI2 stuff is required for disabled interfaces

                There are a lot of things when you look at X11 protocols made no sense to be mainline X11 protocols. Screen capture independent to the main X11 protocol is the way the pipewire screen capture is does make sense of that screen capture method can be replaced without having to alter core protocol. Just like those who wrote X11 protocol originally could not dream that we would have multi screen setups. Lot of Wayland choices that applications don't know where they are on screen or how they are being displayed is future proofing.

                There have been different X11 screen compositors that have resulted in doing screen captures and getting black windows or missing missing windows.

                Horrible as it is there are a stack of unfix-able problems with X11 only fix is basically scrap the protocol because too many features were welded into the core protocol without being individually replaceable. So you arguement about you can mix and match various components from different projects and make something that works well is in fact the problem with X11 protocol where its in fact blocking mixing and matching various components because too much was weld into the core protocol.

                We need a core protocol with a collection of individual replaceable protocol parts and the core protocol must only contain the future proof stuff or close to future proof stuff. So the highly restricted Wayland core protocol makes sense. Now getting all the individual replaceable protocol parts done that is one hell of a job.


                Comment


                • #9
                  Good post oiaohm, you've listed a few genuine weak points of X11. But that still does not address the issues of Wayland, issues that do have solutions in X - lack of interoperability, requiring tight coupling between compositor and environment - panel/task manager, desktop manager, screen configuration, input configuration, etc, etc. In Wayland, input and screen configuration is limited by what the compositor devs decided to expose in their environment's configuration panel. There's no xinput or xrandr, environment-independent command-line tools that expose *everything* the underlying protocol is capable of.

                  Then, only recently have wlroots devs written a protocol that allows communication between window management and panels/task managers, so that you're not limited to the panel/task manager that the compositor is coupled with. Now the question becomes, will the protocol see widespread adoption? The Weston panel is very basic, use of that protocol would allow you to use a different panel with Weston. Will this become a reality, will Weston get support for that protocol? Will Gnome and KDE? I kinda doubt it. So you'll be limited to compositors that do implement the protocol, basically wlroots-based ones. Limitations like that all over the place.

                  Comment


                  • #10
                    Gusar Facts are never trolling. It’s perfectly valid to tell people that the protocol is fine and they need to re-evaluate their choice of experimental compositors if it has been broken for half a decade.

                    Comment

                    Working...
                    X