Announcement

Collapse
No announcement yet.

OpenWF Working Group Offers Hand To Wayland

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

  • OpenWF Working Group Offers Hand To Wayland

    Phoronix: OpenWF Working Group Offers Hand To Wayland

    While not a huge item as no work has yet been rendered, the Khronos Working Group responsible for the OpenWF standard have offered their support to the Wayland Display Server project...

    http://www.phoronix.com/vr.php?view=OTQwNA

  • #2
    is OpenWF supported by the kernel or it doesn't matter in case someone wants to use it instead of linux technologies???

    anyone care to explain?

    Comment


    • #3
      Originally posted by 89c51 View Post
      is OpenWF supported by the kernel or it doesn't matter in case someone wants to use it instead of linux technologies???

      anyone care to explain?
      I'm working on implementing it on drm/kms here:
      http://cgit.freedesktop.org/~bnf/owfdrm/

      Still early in progress, but that is what is used by compositor-openwfd.c currently.

      Comment


      • #4
        Originally posted by 89c51 View Post
        is OpenWF supported by the kernel or it doesn't matter in case someone wants to use it instead of linux technologies???
        It doesn't matter. It's just an API specification. You have to write an actual implementation of it to be useful. The Mesa implementation will wrap the KMS/DRI2/Gallium infrastructures so that it Just Works on Linux without any new kernel APIs. The proprietary drivers will maybe include an implementation in the future that wraps their proprietary library/kernel interfaces. Either way, it abstracts away the specifics of the platform/driver so that you don't need to care if you're on Linux, Windows, iOS, or whatever else.

        Comment


        • #5
          Doesn't this step on egl's toes?

          Comment


          • #6
            Originally posted by elanthis View Post
            It doesn't matter. It's just an API specification. You have to write an actual implementation of it to be useful. The Mesa implementation will wrap the KMS/DRI2/Gallium infrastructures so that it Just Works on Linux without any new kernel APIs. The proprietary drivers will maybe include an implementation in the future that wraps their proprietary library/kernel interfaces. Either way, it abstracts away the specifics of the platform/driver so that you don't need to care if you're on Linux, Windows, iOS, or whatever else.
            thanks @benjamin and elanthis

            Elanthis got me covered BUT since the only thing we need to run wayland is its owf backend (which ~bnf is also writing) and an implementation of openwf that can be provided by anyone (nvidia, ATI) why we need to have openwf over drm. Isn't KMS enough????

            Comment


            • #7
              Originally posted by 89c51 View Post
              thanks @benjamin and elanthis

              Elanthis got me covered BUT since the only thing we need to run wayland is its owf backend (which ~bnf is also writing) and an implementation of openwf that can be provided by anyone (nvidia, ATI) why we need to have openwf over drm. Isn't KMS enough????
              It is over KMS. The name is just misleading.
              Same situation as for compositor-drm.c which is also using kms.
              Its all part of the drm subsystem. But we'll rename them at some point.

              Comment


              • #8
                Originally posted by liam View Post
                Doesn't this step on egl's toes?
                Nope. EGL solves an entirely different problem.

                EGL is basically a generalization of WGL/AGL/GLX, that is, it attempts to generalize context creation, to the extent that this is possible (it's not 100% possible, because e.g. on X11 you still need to know which Window you're creating the context for).

                WF is an abstraction of layers like KMS and some of the other bits inside of DRI/Gallium3D that deal with getting the data in applications' windows onto the actual screen.

                Very generally speaking: OpenGL hanldes the "draw this stuff to that framebuffer." EGL handles "attach this framebuffer to that window." WF handles "composite these windows onto that display."

                Comment


                • #9
                  If they want to help, that's fine by me. But they can leave their patents at home. Let's hope it doesn't become ClosedWL.

                  Khronos loves to speak with two tongues. Sure, you're free to "implement" the "open" GL specification, but if you try to fully comply with all of it, you step on 5 or 6 patents by fairly large corporations. Gee. Not very open at all, is it?

                  A group setting standards like that should have the balls to create an organizational policy that forbids any sitting members of the Khronos working groups from enforcing a software patent on any part of a compliant implementation of the standards that Khronos releases, with a failure to comply resulting in the offending portions of the standard being struck from the standard in the next major API bump (or struck from the draft if they seek a patent before the standard is ratified). It's common sense.

                  Now if some patent troll from outside of Khronos tries to come in from on high and claim that implementors of a Khronos spec can't help but use their patents, that is not the fault of anyone in the Khronos working group, and they can say "Well, at least we tried". But at the very least, those who are supporting, financing, designing and ratifying the standards should have no role in patenting and enforcing patents on the standards. Unfortunately, that's exactly what they do. If the same folks (err, I mean, companies) are behind OpenWF, I wouldn't put it past them to repeat recent history (hello floating point textures and S3TC).

                  Comment


                  • #10
                    Replying to myself here, but wouldn't it be considered 'prior art' if they only file for a patent after a standard is already ratified? They would have to get the patent FIRST, and thus you have disclosure. So the WG has plenty of opportunity to strike down patented features before they go into a final document.

                    Comment


                    • #11
                      Originally posted by allquixotic View Post
                      Replying to myself here, but wouldn't it be considered 'prior art' if they only file for a patent after a standard is already ratified? They would have to get the patent FIRST, and thus you have disclosure. So the WG has plenty of opportunity to strike down patented features before they go into a final document.
                      AFAIK, there is no such thing as "patented features", but rather "features that cannot be implemented without practicing a patent". It sounds like an academic distinction, but the point is that standards themselves typically specify requirements of a feature without specifying the specific techniques or algorithms used to implement them, and patents would cover the latter. So I would not expect that the standard alone is prior art (absent sample code or the like implementing the relevant feature(s)).

                      Comment


                      • #12
                        Originally posted by elanthis View Post
                        Nope. EGL solves an entirely different problem.

                        EGL is basically a generalization of WGL/AGL/GLX, that is, it attempts to generalize context creation, to the extent that this is possible (it's not 100% possible, because e.g. on X11 you still need to know which Window you're creating the context for).

                        WF is an abstraction of layers like KMS and some of the other bits inside of DRI/Gallium3D that deal with getting the data in applications' windows onto the actual screen.

                        Very generally speaking: OpenGL hanldes the "draw this stuff to that framebuffer." EGL handles "attach this framebuffer to that window." WF handles "composite these windows onto that display."
                        Thanks for this.
                        I read the overview on khronos.org and it seemed like it was overlapping somewhat. Aside from what I read there was a diagram that placed egl between the hardware apis and owf. The later obviously makes more sense given what you've said.
                        I suppose what was confusing to me was that I knew egl to be a way to connect drawing contexts to parts of the display(indicating it knew of the display but still window level) while owf seemed to provide compositing and mode-setting/xrandr. It was the compositing that I thought egl was capable of(if nothing other than placing a window with an alpha channel).

                        Comment


                        • #13
                          hope this helps clean up a bit the linux graphical mess

                          Comment


                          • #14
                            Originally posted by madjr View Post
                            hope this helps clean up a bit the linux graphical mess
                            it seems to create more options as far as i can understand it.

                            desktop toolkit --> wayland --> openwf (implemented over kms or by somekind of blob) or kernel API stuff

                            seems kind of duplication having openwf implemented (by kernel people) since we already have something to use with wayland

                            Comment


                            • #15
                              Originally posted by allquixotic View Post
                              A group setting standards like that should have the balls to create an organizational policy that forbids any sitting members of the Khronos working groups from enforcing a software patent on any part of a compliant implementation of the standards that Khronos releases, with a failure to comply resulting in the offending portions of the standard being struck from the standard in the next major API bump (or struck from the draft if they seek a patent before the standard is ratified). It's common sense.
                              The way the khronos group works is that a specification proposal is published to all members of a working group before it goes public. Members get 30 days to claim any patent infringements and if none are filed the specification is ratified. If no objections have been filed a patent holder that is part of the working group cannot file a claim against another khronos member for implementing the specification.

                              Extensions like S3TC is not in the core specification, so you can implement OpenGL without supporting it.

                              Comment

                              Working...
                              X