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

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

    How about features like screen recording, screen sharing and so on? That shouldn't be left up to compositors to design, but should be based on some standard Wayland features (protocol extensions or what not). That's what's very much lacking and causing a lot of pain for compositors developers who need to come up with incompatible solutions, which results in even bigger pain for end user applications developers who can't make their applications work across multiple Wayland compositor cases.

    Originally posted by Weasel View Post
    instead of having all of it bundled into Wayland itself directly?
    Wayland defines protocols, it's not providing their implementation on the compositor side. You aren't viewing Wayland in the manner of what it is.
    Last edited by shmerl; 03 June 2018, 10:15 AM.

    Comment


    • #12
      Originally posted by Weasel View Post
      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..
      Even the X11 protocol does not cover all stuff you are talking about. http://www.jcraft.com/weirdx/ Try some of the side X11 servers some time and learn a few things. You have got use to everything using x.org X11 server.

      Yes X11 servers do implement feature differently like it or not. Current compositors are no different, Wayland is the wire protocol between client and server. Weston is reference implementation and its the reference implementation with X11 that stabilised it behaviour not the X11 protocol. If you compositor behaves to an application different to Weston is defective. As yet we do not have solid conformance suite this is how Vulkan and Opengl does it. Basically we need weston go grow a conformance suite.

      Comment


      • #13
        Originally posted by shmerl View Post
        How about features like screen recording, screen sharing and so on? That shouldn't be left up to compositors to design, but should be based on some standard Wayland features (protocol extensions or what not). That's what's very much lacking and causing a lot of pain for compositors developers who need to come up with incompatible solutions, which results in even bigger pain for end user applications developers who can't make their applications work across multiple Wayland compositor cases.
        Screen recording comes very hard where should it be implemented. Should it be in KMS/DRM should it be Video 4 Linux. Screen sharing is the same problem. This feature really should not be based in wayland protocol.

        Next question is a good one why are compositors implementing features they have not submitted to the reference implementation?????????

        https://github.com/krh/weston/blob/m...s/screenshot.c << Like there is a screen shot feature in the reference implementation. Remember if you implementation does not perform like the reference implementation its broken.

        Reality here the fact each compositor maker is taking their own path is totally invalid and is totally disrespecting the role of a reference implementation. We have seen the same thing with X11 and Opengl over the years. Heck how often wine project has an X11 WM fall over dead just because it asked the WM to do something exactly to X11 reference implementation and specifications.

        Yes failure to understand Protocol and Reference implementation. General rule reference implementation exists its you gold standard ahead of protocol. Protocol is just general guidance.

        Comment


        • #14
          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
          Yeah, with Mir it's much better 'cause it's a very great idea to run a compositor (any) on top of an abstraction layer (Mir) on top of a protocol (Wayland)!

          Comment


          • #15
            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
            That's because Wayland is just a protocol.

            The same would apply to X11, but since X.Org is there, nobody is willing to create another X server.

            (P. S.: I am actually worried that Wayland was created so people complain about this issue, and eventually Red Hat will propose a solution, and that solution is that GNOME/Mutter becomes the only Wayland-implementing compositor/desktop... )
            Last edited by tildearrow; 03 June 2018, 11:51 AM.

            Comment


            • #16
              Originally posted by Vistaus View Post

              Yeah, with Mir it's much better 'cause it's a very great idea to run a compositor (any) on top of an abstraction layer (Mir) on top of a protocol (Wayland)!
              Why can't people say exactly this but for Sway?

              Yeah, with wlroots it's much better 'cause it's a very great idea to run a compositor (Sway) on top of an abstraction layer (wlroots) on top of a protocol (Wayland)!
              (or is wlroots not an abstraction layer?)

              Comment


              • #17
                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
                mir is not anywhere near dead

                Comment


                • #18
                  Originally posted by davidbepo View Post

                  this is the problem with wayland EVERYTHING has to be implemented by the compositor...
                  That's by design, they chose it to be that way (do one thing and do it well...). And by they, I mean the Wayland devs who were Xorg devs and know all the problems with Xorg. Xorg is broken by design at this point. It may work and is convenient, but it's horribly insecure, dated and bloated. It has no business being the unpinning of a modern Linux desktop.

                  When people critisize Wayland, they talk as if the Wayland devs didn't put much thought into everything and just made it up as they went along.

                  Comment


                  • #19
                    Originally posted by kaprikawn View Post

                    That's by design, they chose it to be that way (do one thing and do it well...). And by they, I mean the Wayland devs who were Xorg devs and know all the problems with Xorg. Xorg is broken by design at this point. It may work and is convenient, but it's horribly insecure, dated and bloated. It has no business being the unpinning of a modern Linux desktop.

                    When people critisize Wayland, they talk as if the Wayland devs didn't put much thought into everything and just made it up as they went along.
                    well your second phrase is interesting, beacuse if wayland devs did really put much thought then desktops would have reached feature parity with Xorg, none has done that yet, gnome is the closest, but for example (and there are more) i cant run any app that doesn't support my current resolution, this matters for old games especially under wine, i think the problem is that wayland is designed for developers and not for end users, gparted not running because the root thing is another example

                    Comment


                    • #20
                      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
                      Wayland isn't ready yet, and some DE devs might just not want to implement it yet. Take Cinnamon for example, it is the standard DE for Mint which is a very conservative distribution. People who run Mint don't want to be dealing with issues related to cutting edge software, they want it to just work. For them, Xorg is the obvious choice right now. Whereas Fedora is a testing ground for the latest software, and therefore it was no surprise it was the first fixed-release distro to have Wayland by default.

                      If the DE dev team isn't corporate sponsered, I think it's a bit rough to call them incompetent and lazy. If they're donating their free time you can't expect them to support something which doesn't even have feature parity with Xorg yet. I have a Wacom tablet, and it didn't work on Wayland until Xorg 1.20 was released very recently because of an issue with XWayland. This is one bug amongst many, and I'd expect to run into stuff like that on Fedora (or Arch which is what I'm on), but if I plug my tablet into a machine running Mint, I'd expect it to work.

                      Comment

                      Working...
                      X