Announcement

Collapse
No announcement yet.

Weston Might Move To 4 Month Releases While Wayland's Maturity May Stop Timed Cycles

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

  • Weston Might Move To 4 Month Releases While Wayland's Maturity May Stop Timed Cycles

    Phoronix: Weston Might Move To 4 Month Releases While Wayland's Maturity May Stop Timed Cycles

    Derek Foreman at Samsung's Open-Source Group has initiated a formal discussion over the Wayland and Weston release schedules...

    http://www.phoronix.com/scan.php?pag...8-Release-Talk

  • #2
    Wayland mature? But it can't even do[list of stuff that should be handled by the compositor...] yet!

    Comment


    • #3
      Originally posted by kaprikawn View Post
      Wayland mature? But it can't even do[list of stuff that should be handled by the compositor...] yet!
      this is the problem with wayland EVERYTHING has to be implemented by the compositor, leading to duplicated work and a lot of issues that didnt happen in X, using mir as an abstraction layer might improve this

      Comment


      • #4
        major question concerns with the inability of the several operating systems' developers to implement wayland because of their incompetence and their laziness

        Comment


        • #5
          Originally posted by davidbepo View Post

          this is the problem with wayland EVERYTHING has to be implemented by the compositor, leading to duplicated work and a lot of issues that didnt happen in X, using mir as an abstraction layer might improve this
          It's definitely a problem, though it's hard to find "the" problem, there are many. I have thus far avoided doing any real kind of technical posts on the matter (current notes would put it into the ten-thousand-word range and my patience is running thin), but really - the technical underpinnings are *extremely* shaky, the ecosystem scattered, fragmented and incomplete thanks to the 'extensions and community will fix things' and as a dev, it is extremely frustrating to use. The issues highlighted by the WLC dev before he quit ( https://github.com/Cloudef/orbment/i...ment-227720157 ) just scratches the surface.

          Comment


          • #6
            Originally posted by davidbepo View Post
            this is the problem with wayland EVERYTHING has to be implemented by the compositor, leading to duplicated work and a lot of issues that didnt happen in X, using mir as an abstraction layer might improve this
            This is 100% not true. There 1 part true and most of it bogus idea..
            https://www.phoronix.com/scan.php?pa...KMS-Progress-1
            Not everything has to be implemented by the compositor. As the Virtual KMS is showing some things need to be rethought.

            Also you have libweston
            https://www.phoronix.com/scan.php?pa...and-Compositor
            Result of libweston is that each wayland compositor does not need to duplicate everything. So there is already an abstraction layer.

            Its important to understand the split between weston the reference implementations also the project that provides the generic abstraction layer then you have the protocol wayland. Protocol wayland is getting fairly closed to complete so they are talking about slowing down updates. The abstraction layer libweston and the reference compositor needs more work.

            Yes with wayland everything has to be implemented by the compositor since it only a protocol it does not forbid a compositor using a common library to implement most of wayland. Using a library means most of the duplicated work with wayland is totally optional and the duplicated work is caused by a implementation not using libweston. Of course someone could choose to write X11 server or mir from scratch as well if they have determination to duplicate work.

            People forgot at one point of history there were 20 different implementations of the X11 server.

            Comment


            • #7
              Originally posted by Azrael5 View Post
              major question concerns with the inability of the several operating systems' developers to implement wayland because of their incompetence and their laziness
              Its not easy process. Does not help with Nvidia being late to say GBM will not work.

              Originally posted by crazyloglad View Post
              It's definitely a problem, though it's hard to find "the" problem, there are many. I have thus far avoided doing any real kind of technical posts on the matter (current notes would put it into the ten-thousand-word range and my patience is running thin), but really - the technical underpinnings are *extremely* shaky, the ecosystem scattered, fragmented and incomplete thanks to the 'extensions and community will fix things' and as a dev, it is extremely frustrating to use. The issues highlighted by the WLC dev before he quit ( https://github.com/Cloudef/orbment/i...ment-227720157 ) just scratches the surface.
              https://lists.freedesktop.org/archiv...ch/037610.html
              Fragmented is a big problem. Input under X11 was very fragmented in configuration. Moving that it libinput is taking some time. Yes issue list from 2016 some of the issues are gone but others still need work.

              Replacing X11 is not an easy process. The need to add to protocol coming to end now opens up path to focus on generic configuration options and the like.

              Comment


              • #8
                Can I make up a protocol that does absolutely nothing and delegate everything to the compositor and call it a success? I mean, since it has no bugs and all and no unnecessary features because they will all have to be implemented in the compositor.

                Originally posted by oiaohm View Post

                This is 100% not true. There 1 part true and most of it bogus idea..
                https://www.phoronix.com/scan.php?pa...KMS-Progress-1
                Not everything has to be implemented by the compositor. As the Virtual KMS is showing some things need to be rethought.

                Also you have libweston
                https://www.phoronix.com/scan.php?pa...and-Compositor
                Result of libweston is that each wayland compositor does not need to duplicate everything. So there is already an abstraction layer.

                Its important to understand the split between weston the reference implementations also the project that provides the generic abstraction layer then you have the protocol wayland. Protocol wayland is getting fairly closed to complete so they are talking about slowing down updates. The abstraction layer libweston and the reference compositor needs more work.

                Yes with wayland everything has to be implemented by the compositor since it only a protocol it does not forbid a compositor using a common library to implement most of wayland. Using a library means most of the duplicated work with wayland is totally optional and the duplicated work is caused by a implementation not using libweston. Of course someone could choose to write X11 server or mir from scratch as well if they have determination to duplicate work.

                People forgot at one point of history there were 20 different implementations of the X11 server.
                Sorry but you're missing the mark here. The point is that Wayland misses a TON of actually useful features from X11, with the excuse that it's the compositor's job to implement them.

                This is a bad thing for application DEVELOPERS, not necessarily users of said compositor. If they want to use a feature in compositor ABC, they will be bound to compositor ABC for it. What if another compositor implements the same feature but in a different way? Now you need two different code paths in your app to deal with both compositors. What if in the future there will be another compositor but you got sick of working on your app (which is now in a finished state) and work on something else entirely (another app maybe)? Now you need to update it to work with the new compositor, just because there is no standard, backwards-compatible protocol.

                This is why stuff like this has to be in the PROTOCOL itself, so that a STANDARD WAY to get access to that feature is done. Developing for these features is a massive pain in the ass for Wayland, end of story.

                I mean, dude, it's like saying we don't need OpenGL or Vulkan, they have too many features, just code directly for the graphics card in question! This way it doesn't have "unnecessary features"? wtf. The protocol's job is to abstract away so that these features are accessible in a standard and backwards compatible manner. If a new graphics card is released, your app written for Vulkan will still work, because it's in the protocol. If a graphics card wants to advertise itself as Vulkan capable, it will have to adhere to that protocol.

                That's why if someone makes a different implementation of X11, he will have to implement the whole protocol if he wants it to actually be X11 and not something else. And apps written for X11 will "just work". On the other hand with Wayland a compositor isn't required to use a standard protocol to implement a feature Wayland misses.
                Last edited by Weasel; 06-03-2018, 09:47 AM.

                Comment


                • #9
                  Replacing X11 is with the difficult of managing legacy and migration from legacy - Apple level of skills are needed there. The actual technical parts in how clients interact with the display server isn't unless you chose to ignore almost all prior work on it. Whatever the extent you need a protocol (locally, you don't... windows, osx and android are all better off for not having one), there are many competent alternatives that predates Wayland - Including Quamranet/RedHat's own SPICE. Anything that fulfils the criterion for a remote desktop protocol is obviously a potential building block for a protocol.
                  Wayland devs should have a ton of credit, rewards and back-patting for the work done decoupling drivers from Xorg, just none for the protocol itself.

                  Comment


                  • #10
                    Originally posted by tpruzina

                    I was ready to agree with your comment right until I saw your suggestion to use effectively dead project as a stop gap solution. That is purely retarded IMHO.
                    What we actually need is unifying library on top of wayland which would make writing compositors easier.
                    Something like wlroots, but actually stable (both API-wise and code quality wise) and working well (even with nvidia).

                    https://github.com/swaywm/wlroots
                    But that's the thing. What is the point of having a "standard" library on top of Wayland that "everyone should use" (to reduce fragmentation) to provide much needed features, instead of having all of it bundled into Wayland itself directly?

                    Comment

                    Working...
                    X