Announcement

Collapse
No announcement yet.

NVIDIA Publishes EGL External Platform Interface & Wayland Library

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

  • #11
    Originally posted by shmerl View Post
    What about implementing all that for Mesa drivers? If Nvidia wants some common method, it should be universally available. Developers of Wayland compositors like KWin aren't going to use something that's Nvidia only.
    I don't understand why Wayland left the window compositing to the desktop environments, especially considering how many DEs there are on Linux. I'd have expected Wayland to include a window compositor with a plug-in API for DEs. Or is there some larger benefit to having lots of competing window compositors?

    I don't know if it is for that reason, but it feels like there is a vacuum left that Nvidia is trying to fill.

    Also, something like GLVND (vendor neutral interface to possibly multiple co-existing OpenGL implementations) should not have required Nvidia's initiative. Fortunately, it seems Nvidia is providing these things open-source. I'd guess that's probably because of an understanding that these areas should be provided by an open-source operating system in the first place.

    Comment


    • #12
      Originally posted by indepe View Post

      Or is there some larger benefit to having lots of competing window compositors?
      Wayland didn't want to limit them. Compositors can have different needs. One size fits all isn't a good approach here.

      If Nvidia want to fill the vacuum, let them implement EGLstreams for all widely used Mesa drivers. I don't think anyone opposes EGLstreams specifically. But since it's nowhere to be found, it's not the proper solution (yet).

      Comment


      • #13
        Originally posted by shmerl View Post

        Wayland didn't want to limit them. Compositors can have different needs. One size fits all isn't a good approach here.
        That sounds a bit theoretical. How are the needs of Gnome, Qt, and KDE different? Or would you say there could be a common compositor for the desktop, as long as there is the possibility, for example for phones, to use a different compositor?

        Originally posted by shmerl View Post
        If Nvidia want to fill the vacuum, let them implement EGLstreams for all widely used Mesa drivers. I don't think anyone opposes EGLstreams specifically. But since it's nowhere to be found, it's not the proper solution (yet).
        How does that make sense?
        Last edited by indepe; 18 January 2017, 04:49 PM.

        Comment


        • #14
          Originally posted by indepe View Post

          That sounds a bit theoretical. How are the needs of Gnome, Qt, and KDE different? Or would you say there could be a common compositor for the desktop, as long as there is the possibility, for example for phones, to use a different compositor?


          How does that make sense?
          Desktop is one use case. Tablets and handsets is another. Some kiosks, digital cameras, watches and etc. can differ from all the above. You can't fit them all into one abstraction necessarily. And it's better to focus on common interfaces and protocols, instead of limiting the abstraction of compositor itself.

          Comment


          • #15
            Originally posted by indepe View Post
            How does that make sense?
            See https://blog.martin-graesslin.com/bl...stream-or-not/

            Comment


            • #16
              The EGLStreams vs GBM discussion.... my understanding was that NVidia and the open source developers agreed to work on an enhanced-GBM, so to speak, solution. We haven't heard about that for a while, I think... that sounded like a good thing to me.

              Comment


              • #17
                Originally posted by indepe View Post

                I don't understand why Wayland left the window compositing to the desktop environments, especially considering how many DEs there are on Linux. I'd have expected Wayland to include a window compositor with a plug-in API for DEs. Or is there some larger benefit to having lots of competing window compositors?

                I don't know if it is for that reason, but it feels like there is a vacuum left that Nvidia is trying to fill.

                Also, something like GLVND (vendor neutral interface to possibly multiple co-existing OpenGL implementations) should not have required Nvidia's initiative. Fortunately, it seems Nvidia is providing these things open-source. I'd guess that's probably because of an understanding that these areas should be provided by an open-source operating system in the first place.
                Here is the problem with plugin systems, you need to account for every possible use case and incorporate a design flow into your API that fits. But in the case of Wayland, there are going to be drastically different useage scenarios. You probably could design a compositor interface that works well with all kinds of desktop compositors, but would that same API's work flow fit in with a handheld device? Partially maybe at best.

                EDIT: It's why I think this whole concept of convergence is retarded. You'll end up with a watch interface on a handheld or a desktop interface on a handheld/ Or some horrible flub of them all.
                Last edited by duby229; 18 January 2017, 07:31 PM.

                Comment


                • #18
                  Originally posted by duby229 View Post

                  Here is the problem with plugin systems, you need to account for every possible use case and incorporate a design flow into your API that fits. But in the case of Wayland, there are going to be drastically different useage scenarios. You probably could design a compositor interface that works well with all kinds of desktop compositors, but would that same API's work flow fit in with a handheld device? Partially maybe at best.

                  EDIT: It's why I think this whole concept of convergence is retarded. You'll end up with a watch interface on a handheld or a desktop interface on a handheld/ Or some horrible flub of them all.
                  Yes, I can see that... also that on a phone, you might not want to pay the overhead of a generic compositor that supports all kind of use cases...

                  Nevertheless, for the desktop, my guess would be that once Gnome, Qt and KDE all have their own window compositor working, if you then filter out the actually *meaningful* differences, you could easily abstract them out in some way.

                  Comment


                  • #19
                    Originally posted by indepe View Post

                    Yes, I can see that... also that on a phone, you might not want to pay the overhead of a generic compositor that supports all kind of use cases...

                    Nevertheless, for the desktop, my guess would be that once Gnome, Qt and KDE all have their own window compositor working, if you then filter out the actually *meaningful* differences, you could easily abstract them out in some way.
                    That actually sounds like a great idea to me. I suppose a similar abstraction could be made for handheld compositors too. I guess that is what Weston was suppossed to be, basically a reference guide that other desktop compositors could use to implement their design. I think it's partially why there are so many desktop compositors available. If the same was done, i.e. developing a reference handheld compositor there probably would be more handheld compositors.

                    EDIT: I guess what I mean to say is that a desktop compositor "standard" doesn't have to be the same as a handheld compositor "standard". And they can both still be implemented on the same Wayland protocol.
                    Last edited by duby229; 18 January 2017, 08:39 PM.

                    Comment


                    • #20
                      Originally posted by duby229 View Post

                      That actually sounds like a great idea to me. I suppose a similar abstraction could be made for handheld compositors too. I guess that is what Weston was suppossed to be, basically a reference guide that other desktop compositors could use to implement their design. I think it's partially why there are so many desktop compositors available. If the same was done, i.e. developing a reference handheld compositor there probably would be more handheld compositors.

                      EDIT: I guess what I mean to say is that a desktop compositor "standard" doesn't have to be the same as a handheld compositor "standard". And they can both still be implemented on the same Wayland protocol.
                      pretty sure this is why libweston was made. KDE and Gnome were well down their own paths when libweston became a thing. any new DE would be crazy to at least not start with it

                      Comment

                      Working...
                      X