Announcement

Collapse
No announcement yet.

Wayland's Wild Decade From v1.0 Release To Usable GNOME/KDE Desktop Support

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

  • #41
    Originally posted by bug77 View Post
    That's true, I have two friends that are into image recognition and ML and they both tell me virtually any framework worth anything is CUDA-only.

    But to be fair, Nvidia support is not a problem with Wayland, but with Wayland implementations. Weston used GBM and somehow the whole world got stuck on that. That's the real problem. Gnome yielded eventually and implemented EGL Streams support, but I think KDE still doesn't want to do that.
    Yeah because Weston was the reference compositor. I remember reading about how it was decided to keep technical documention to a minimum and release code as documentation instead. I don't remember all the details, but it was something about how too much technical description is bad for projects and so reference projects would be considered documentation instead. That was Weston's entire purpose. But it doesn't mean that other developers had to use that code line for line, it was just meant to be an example compositor to show documentation.

    Comment


    • #42
      Originally posted by Britoid View Post
      KDE added EGLStreams support.
      More like NVIDIA developers added that in KDE and it was merged.

      Comment


      • #43
        Originally posted by CommunityMember View Post
        EGLStreams is a standard.
        created by NVIDIA on the fly and not used by anyone else but them. Technically right but in practice it's bullshit.

        Comment


        • #44
          Originally posted by 144Hz View Post
          duby229
          Senior Member
          duby229 There’s no misconception. Mutter on Wayland Just Works(tm). There’s a lot of code and mindshare between Mutter and Weston so that’s kind of expected. I have no problems with Wayland. It’s well architected and doesn’t suffer from scope creep.

          People should stop blaming Wayland for their poor choice of Wayland compositors.

          Wayland=simple.
          Compositor=complex.
          I'd like to say it's the inverse of scope creep. Wayland is so simple it doesn't do hardly anything a compositor might want a display protocol to do.. I don't mean to knock on Mutter, it's amazing that they managed to get a mostly functional compositor working. Just that attributing that to wayland is super asinine. It's more like they managed to do it despite wayland, certainly not because of it. Wayland can't do most of what a compositor needs, so most of what Mutter does is waaaay beyond the scope of wayland.
          duby229
          Senior Member
          Last edited by duby229; 30 December 2019, 03:56 AM.

          Comment


          • #45
            Originally posted by 144Hz View Post
            duby229
            Senior Member
            duby229 Wayland’s simplicity is a deliberate design feature. Besides technical merits it comes with many other benefits. Gone are the days where protocols need to deal with other desktop compositors’ quirks and poor design.

            No more bastardizing “standards”. Just pure Mutter. And it comes with no downsides. The remaining desktop X resources just moved to work directly on Mutter instead.
            Go ahead and name some technical benefits of wayland then. I'd bet most or all you can name are of Mutter. Wayland's scope is so narrow it just doesn't do much.

            Comment


            • #46
              Originally posted by 144Hz View Post
              duby229
              Senior Member
              duby229 There’s no disagreement then. Wayland does one thing and do it well.
              Doesn't Wayland provide a reference compositor (Weston)? That is also pretty crap.

              The main bulk of the work (because Wayland has such a trivial useless scope) needs to be done by individual compositor developers (almost like the WM developers of X11). These are tiny teams and can simply not manage to provide a robust solution if they have to do it all from scratch. This is where a "Weston compositor SDK" comes in handy. Unfortunately these are all currently crap too.

              Its all crap, crap, crap XD

              The only benefit I can see is Wayland eliminates the overwhelming choice of Window Managers / Compositors because they become too hard to develop. Unfortunately I imagine many Linux users will not like this. However reducing fragmentation is good for the enterprise.
              kpedersen
              Senior Member
              Last edited by kpedersen; 30 December 2019, 08:52 AM.

              Comment


              • #47
                Originally posted by CommunityMember View Post
                EGLStreams is a standard. So is GBM.
                EGLStreams was pushed by Nvdia and there's only one implementation - Nvidia's. That's not a standard. A standard is something that's worked on by several entities *before* the spec is finalized and there are multiple independent implementations to validate the spec. GBM isn't a standard either. If you want an example of what could be considered a standard, it's GLVND. Pushed by Nvidia, but with input from the the community, and there are two implementations - Nvidia's and Mesa's.

                Originally posted by 144Hz View Post
                Just pure Mutter.
                Ah, yeah, "one compositor to rule them all!"

                Originally posted by 144Hz View Post
                And it comes with no downsides.
                No downsides, except that you're forced to use Mutter, and if you don't like a design decision of the devs, tough luck. No downsides, expect that it's GTK, while one wants a Qt based environment. No downsides, except one wants a small and simple environment without dragging in lots of DE-specific baggage. Yep, no downsides whatsoever .

                Originally posted by 144Hz View Post
                Mutter is doing well so no one can claim they are left without options.
                Yep, you have all the options in the world. As long as you choose Mutter . Vendor lock-in at its finest.


                As others have said, the core protocol is so narrow in scope that you can't create a fully functional environment without additional private protocols that each compositor has to reimplement over and over again, and so nothing is compatible with anything. Yay, fragmentation! wayland-protocols helps a little here, but even that is far from complete and then you also have compositor devs refusing to implement things that are part of wayland-protocols (like xdg-decoration <- and spare me your "CSD uber alles" mantra, if CSD was the answer to everything, xdg-decoration wouldn't exist).

                Comment


                • #48
                  Originally posted by 144Hz View Post
                  Gusar
                  Senior Member
                  Gusar Don’t like fragmentation? Then don’t do yet another compositor..
                  With proper standards and well-defined protocols there can be as many compositors as people feel like creating, and it won't cause fragmentation because the protocols will ensure interoperability.

                  Comment


                  • #49
                    Originally posted by starshipeleven View Post
                    created by NVIDIA on the fly and not used by anyone else but them. Technically right but in practice it's bullshit.
                    Yeah, well, that's how OpenGL works in general: somebody comes up with an extension first, it get adopted into some official version and then people start implementing it.
                    In this particular case, it seems GBM has acknowledged drawbacks (performance, iirc) and while EGL Streams improves on that, it doesn't fix everything. And the third solution, the one that people are supposed to be working on together, is still MIA.

                    Long story short, this seems to have landed in the hands of drama queens. Looking at this vary page's source code, it has "<!--[if IE]> ... <!--<![endif]-->" in it. Virtually every piece of code that's supposed to be portable has some target specific pieces in it, but in this case it seems it has become way more important to stick it to Nvidia instead.

                    Comment


                    • #50
                      Originally posted by 144Hz View Post
                      Mutter and Wayland/Weston are already our proper standards and well-defined protocols.
                      You wishing that to be the case doesn't make it reality.

                      Comment

                      Working...
                      X