Announcement

Collapse
No announcement yet.

Why Wayland & Weston Were Forked

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

  • #16
    That was an interesting read, yes. I thought to myself, "hey, maybe this time people will stick to the technical side of the discussion, given that this post is all about that." A few seconds later, "nah, who am I kidding, this is Phoronix, this will degenerate into trolling sooner than one could blink..." Then I read the first comment, and soreau himself is giving people more troll bait. Oh come on...

    But speaking about the technical side, I see both sides now, and both have a point. Wayland developers are trying to settle down at this point, so that something bad doesn't happen, now that it's past 1.0. All changes need a lot of thinking and testing now. And Northfield developers, on the other hand, want to work on the compositor to take advantage of all the power that Wayland allows, compared to X. Though due to certain things that are not yet finished in Wayland, they can't really proceed further. They can, however, use some makeshift changes that do allow them to move forward, even if in a somewhat unorthodox manner. Or at least that's what I've gathered of the overall situation.

    Overall that isn't much of an issue. The biggest question now is whether Northfield will be able to adapt to the changes in Wayland, once the missing functionality gets implemented officially. If yes, then perfect, in the end Northfield will not be needed and we'll just have Norwood, the non-reference Wayland compositor, that can run on stock Wayland without any patches. But if not, there could be further complications.

    As for the EGL problem... I suppose that's something that the Mesa developers should answer. In theory, you could fork Mesa into Plateau or something, but I don't think there really is a need or motivation to do so, since it's just one unimplemented feature, and it's pretty far from the display server anyway.

    Comment


    • #17
      Originally posted by GreatEmerald View Post
      Wayland developers are trying to settle down at this point, so that something bad doesn't happen, now that it's past 1.0. All changes need a lot of thinking and testing now. And Northfield developers, on the other hand, want to work on the compositor to take advantage of all the power that Wayland allows, compared to X.
      No, that's not it at all. Although that does seem to be what Scott wants you to think. Or maybe he's genuinely that confused. The wayland developers are all entirely happy with what Scott wants to do - fork weston and the necessary wayland protocol code and develop it into a more usable and fancy desktop environment. That's great. That's basically what weston is for. Others have forked it, and the response was good (everybody even responded positively to ubuntu forking it).

      He explained why he couldn't do it in a plugin alone - which wasn't even relevant.

      What he has failed to explain is why he couldn't do as requested and copy the existing protocol code into a new extension and edit it there, to use the existing mechanism to retain protocol compatibility.

      Comment


      • #18
        Originally posted by GreatEmerald View Post
        That was an interesting read, yes. I thought to myself, "hey, maybe this time people will stick to the technical side of the discussion, given that this post is all about that." A few seconds later, "nah, who am I kidding, this is Phoronix, this will degenerate into trolling sooner than one could blink..." Then I read the first comment, and soreau himself is giving people more troll bait. Oh come on...
        hehe :-)

        Originally posted by GreatEmerald View Post
        But speaking about the technical side, I see both sides now, and both have a point. Wayland developers are trying to settle down at this point, so that something bad doesn't happen, now that it's past 1.0. All changes need a lot of thinking and testing now. And Northfield developers, on the other hand, want to work on the compositor to take advantage of all the power that Wayland allows, compared to X. Though due to certain things that are not yet finished in Wayland, they can't really proceed further. They can, however, use some makeshift changes that do allow them to move forward, even if in a somewhat unorthodox manner. Or at least that's what I've gathered of the overall situation.

        Overall that isn't much of an issue. The biggest question now is whether Northfield will be able to adapt to the changes in Wayland, once the missing functionality gets implemented officially. If yes, then perfect, in the end Northfield will not be needed and we'll just have Norwood, the non-reference Wayland compositor, that can run on stock Wayland without any patches. But if not, there could be further complications.

        As for the EGL problem... I suppose that's something that the Mesa developers should answer. In theory, you could fork Mesa into Plateau or something, but I don't think there really is a need or motivation to do so, since it's just one unimplemented feature, and it's pretty far from the display server anyway.
        Yes, I am happy I was able to help you understand. Thanks for your support.

        Comment


        • #19
          Yet Another Technical Concern

          One technical concern I forgot to mention was one that I just noticed when a user notified me about a problem when using the window list (taskbar) found in northfield/norwood. The problem is, that there is supposed to be a protocol versioning system in place so that you can make additions to the protocol and increment the relevant interface version number. In theory, this is supposed to work in a way that clients would only use the highest interface version it supports locally, to avoid problems with potential crashes when related events/requests are processed. It is yet another technical problem involving the protocol interface versioning system. See the very bottom of http://lists.freedesktop.org/archive...ch/008084.html

          My questions there have yet to answered. I tried to work out a solution to this problem with them but they seem like they don't want this new stuff to happen in the first place for some reason. I followed protocol but the version control system is broken by design apparently.

          - Scott

          Comment


          • #20
            Originally posted by Darxus View Post
            No, that's not it at all. Although that does seem to be what Scott wants you to think. Or maybe he's genuinely that confused. The wayland developers are all entirely happy with what Scott wants to do - fork weston and the necessary wayland protocol code and develop it into a more usable and fancy desktop environment. That's great. That's basically what weston is for. Others have forked it, and the response was good (everybody even responded positively to ubuntu forking it).
            All right, so what do you think is not correct in my interpretation? I mean, I don't suppose Wayland developers are happy with fast changes to the protocol at this point, and I don't suppose Northfield developers are happy with the slow and steady pace of Wayland development? Or were you referring to something else? Because I agree with what you said here and I don't really see a contradiction.

            Originally posted by Darxus View Post
            He explained why he couldn't do it in a plugin alone - which wasn't even relevant.

            What he has failed to explain is why he couldn't do as requested and copy the existing protocol code into a new extension and edit it there, to use the existing mechanism to retain protocol compatibility.
            An interesting question. If it's possible to create an extension to the protocol itself, and then dump all the necessary unorthodox changes to the protocol there, then it would seem that it would be overall easier for Northfield developers to maintain it in the first place, and also more easily remove duplicate functionality once it gets implemented into Wayland. Any technical reasons why you can't do that, soreau?

            By the way, thanks for contributing to the technical discussion without the whole drama, it's very much appreciated!

            Comment


            • #21
              Minimise as a result of window stacking

              If the "desktop" (e.g. background picture) was a full-screen surface, then minimise could just mean stacking minimised windows behind it. Then you would only need to deal with windows being normal, maximised and full-screen. Restoring the window would mean stacking it in front of the desktop, probably as the top window.

              With minimised windows stacked behind the desktop, then doing previews should not be a problem.

              Comment


              • #22
                Originally posted by soreau View Post
                One technical concern I forgot to mention was one that I just noticed when a user notified me about a problem when using the window list (taskbar) found in northfield/norwood. The problem is, that there is supposed to be a protocol versioning system in place so that you can make additions to the protocol and increment the relevant interface version number. In theory, this is supposed to work in a way that clients would only use the highest interface version it supports locally, to avoid problems with potential crashes when related events/requests are processed. It is yet another technical problem involving the protocol interface versioning system. See the very bottom of http://lists.freedesktop.org/archive...ch/008084.html

                My questions there have yet to answered. I tried to work out a solution to this problem with them but they seem like they don't want this new stuff to happen in the first place for some reason. I followed protocol but the version control system is broken by design apparently.
                1) No, you can't mix and match versions, since the scanner generates opcodes sequentially. So, if you insert a request in the middle, it changes the opcode of everything after it and your extension is broken.
                2) Simple: when the client binds to an interface, it sends the highest version it supports to the compositor. The compositor's then responsible for not sending events to a client it won't be able to understand since it doesn't support a high enough version of the interface.
                3) If you're talking about the wl_surface implicit attach semantics, they were stuck in a halfway house, so got changed to be one definite state. It was unpleasant but had to be changed one way or another.

                I didn't reply to explain this at the time because every conversation with you usually ended in either a torrent of abuse (much like the recent ones where you were repeatedly threatening to try to get me fired in private, whilst acting all nice and reasonable on the forums ...) or you flat-out ignoring what I said, so my desire to go out of my way to help you by explaining how the core Wayland protocol works is roughly zero.

                Comment


                • #23
                  Originally posted by GreatEmerald View Post
                  I mean, I don't suppose Wayland developers are happy with fast changes to the protocol at this point
                  Specifically, we didn't want our core interfaces to include protocol with design flaws which were pointed out in review and left unfixed. http://lists.freedesktop.org/archive...ch/008116.html is where Scott's minimisation patches ended up, as far as Wayland goes: in review, with issues pointed out, and Scott refusing to engage with the process, just sitting out and demanding that his code be merged into core protocols (not extensions), with known issues that he'd neither fixed nor managed to explain away. The rate of change in itself was never an issue.

                  Comment


                  • #24
                    Originally posted by GreatEmerald View Post

                    But speaking about the technical side, I see both sides now, and both have a point. Wayland developers are trying to settle down at this point, so that something bad doesn't happen, now that it's past 1.0. All changes need a lot of thinking and testing now. And Northfield developers
                    you seem to have a spare s there.

                    Dave.

                    Comment


                    • #25
                      Originally posted by daniels View Post
                      1) No, you can't mix and match versions, since the scanner generates opcodes sequentially. So, if you insert a request in the middle, it changes the opcode of everything after it and your extension is broken.
                      2) Simple: when the client binds to an interface, it sends the highest version it supports to the compositor. The compositor's then responsible for not sending events to a client it won't be able to understand since it doesn't support a high enough version of the interface.
                      3) If you're talking about the wl_surface implicit attach semantics, they were stuck in a halfway house, so got changed to be one definite state. It was unpleasant but had to be changed one way or another.

                      I didn't reply to explain this at the time because every conversation with you usually ended in either a torrent of abuse (much like the recent ones where you were repeatedly threatening to try to get me fired in private, whilst acting all nice and reasonable on the forums ...) or you flat-out ignoring what I said, so my desire to go out of my way to help you by explaining how the core Wayland protocol works is roughly zero.
                      Right, but the problem is 2). This is the broken part. The clients do not currently do as you describe here. When you bump the version, no client changes are needed as in the very first protocol bump in wayland protocol by Ander Conselvan de Oliveira here http://cgit.freedesktop.org/wayland/...5306f27c699fff I did not notice any evidence of client changes surrounding this commit that I could tell specifically regarding the version interface client code.
                      Last edited by soreau; 03-29-2013, 05:04 PM.

                      Comment


                      • #26
                        Originally posted by airlied View Post
                        you seem to have a spare s there.

                        Dave.
                        In correct. I will refer you to the northfield and norwood repository commit lists:

                        https://github.com/soreau/northfield/commits/next
                        https://github.com/soreau/norwood/commits/next

                        You can see commits from many other contributers than myself not found in upstream wayland/weston repositories. Read up before posting, I encourage it. Thanks.

                        Comment


                        • #27
                          Originally posted by soreau View Post
                          Right, but the problem is 2). This is the broken part. The clients do not currently do as you describe here. When you bump the version, no client changes are needed as in the very first protocol bump in wayland protocol by Ander Conselvan de Oliveira here http://cgit.freedesktop.org/wayland/...5306f27c699fff I did not notice any evidence of client changes surrounding this commit that I could tell.
                          There weren't any client changes because there were no new events. There's nothing from v2 the compositor could send to a v1-only client which would confuse it, and a v1-only client can't exactly send v2 requests to the compositor. If you look at clients/window.c, all the binds explicitly specify which version of each interface they support. So I'm not sure what exactly you want to change ... ?

                          Comment


                          • #28
                            Originally posted by daniels View Post
                            There weren't any client changes because there were no new events. There's nothing from v2 the compositor could send to a v1-only client which would confuse it, and a v1-only client can't exactly send v2 requests to the compositor. If you look at clients/window.c, all the binds explicitly specify which version of each interface they support. So I'm not sure what exactly you want to change ... ?
                            I will show you what I mean through code, in due time. Thanks for your concern.

                            Comment


                            • #29
                              Originally posted by soreau View Post
                              I will show you what I mean through code, in due time. Thanks for your concern.
                              If clients start using set_buffer_transform, then yes, they should declare that they support v2 in their bind. I think one of the key parts you're missing is that the protocol is strictly append-only, and requests do not - ever - get reordered, which was the answer to your question 1.

                              And this is _exactly_ why everyone is happy for you to fork Weston, but doesn't want you to fork libwayland and the core protocols. You don't understand how the versioning system works, so I can only assume you're on course to break it, and thus break compatibility between clients built against your library, and Wayland clients. That's the absolute disaster scenario we've all been trying to avoid, and this conversation has given me as little confidence of avoiding that, as when you refused to create your own extension protocol in the first place, and insisted on forking literally the entire Wayland protocol into your own project.

                              Comment


                              • #30
                                Originally posted by daniels View Post
                                If clients start using set_buffer_transform, then yes, they should declare that they support v2 in their bind. I think one of the key parts you're missing is that the protocol is strictly append-only, and requests do not - ever - get reordered, which was the answer to your question 1.

                                And this is _exactly_ why everyone is happy for you to fork Weston, but doesn't want you to fork libwayland and the core protocols. You don't understand how the versioning system works, so I can only assume you're on course to break it, and thus break compatibility between clients built against your library, and Wayland clients. That's the absolute disaster scenario we've all been trying to avoid, and this conversation has given me as little confidence of avoiding that, as when you refused to create your own extension protocol in the first place, and insisted on forking literally the entire Wayland protocol into your own project.
                                And the key point you're failing to understand is that I tried to ask how the core devs wanted me to do it on the mailing list. This is after querying several times on IRC in efforts to get an answer. But now I realize, the best answer is the one that I come up with, using my own common sense.

                                Comment

                                Working...
                                X