Announcement

Collapse
No announcement yet.

LightDM Caught Off-Guard By Mir, Plans For Wayland

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

  • #16
    Originally posted by dstaubsauger View Post
    related posts on LightDM mailing list:
    From those posts...

    "More warning on this would have been nice"

    Agreed. I would have loved to make this public ages ago but was not able to.
    Says it all, really. Ubuntu depends on all of these other people to build the software they ship, but actually cooperating with those people comes second to Canonical's desire for secrecy.

    Comment


    • #17
      Originally posted by talvik View Post
      LightDM is under the CLA. Canonical probably won't use his lib.

      http://www.canonical.com/contributors
      That's new. Check http://web.archive.org/web/201301170...m/contributors

      Comment


      • #18
        If I were a voluntary contributor to an Ubuntu project, I'd be jumping ship right about now.

        The ability to develop his own libraries suggests a fair amount of intelligence.

        Sticking by Canonical suggests a lack of intelligence.

        These two don't seem to reconcile with each other, is it like when a battered spouse sticks by an abusive partner seemingly against common sense?

        Comment


        • #19
          If I understand it correct? The guy has in the last half a year written a qt library for lightdm (a Canonical project) to use with kde. He do this because he expect Canonical to develop the wayland backend to lightdm.
          Instead Canonical switch to MIR and UNITY next. The result canonical use his qt library for Unity next but do not support the wayland port. So he gave Canonical a half a year work with the qt support but can as it's now not use it himself? At least if he don't also do the wayland port?

          Comment


          • #20
            Of course he can use it himself. If it's under GPL, he just has to fork his own project, so that it stays under GPL. A GPL-licensed software cannot be fully closed - if Canonical owns the copyright to it, they can only "close" it so that the next version they release would be proprietary, but the last GPL-released version would still be under GPL and anyone can fork or use it under GPL.

            The GPL is designed specifically to prevent the code being closed. So anyone can use it as long as they keep it under GPL - no matter who "owns" the code.

            Comment


            • #21
              Originally posted by dee. View Post
              Of course he can use it himself. If it's under GPL, he just has to fork his own project, so that it stays under GPL. A GPL-licensed software cannot be fully closed - if Canonical owns the copyright to it, they can only "close" it so that the next version they release would be proprietary, but the last GPL-released version would still be under GPL and anyone can fork or use it under GPL.

              The GPL is designed specifically to prevent the code being closed. So anyone can use it as long as they keep it under GPL - no matter who "owns" the code.
              Obviously he probably don't even need to fork it, only write the backend. But the project was sold as "in future wayland compatible" a years ago and I suppose something like that could have impacted the choice of project to use.

              Comment


              • #22
                Originally posted by dee. View Post
                Ok so from what I gather it looks something like this (please correct me if I'm wrong about any of this):

                Code:
                + Wayland system compositor 
                +--- Splash screen 
                +--- Display manager
                +--+ Wayland compositor
                   +--- XWayland
                Wayland is the standard that defines how these parts interact. The implementation of these different parts can vary. The system compositor can be the default reference implementation or something else. The display manager can be LightDM, GDM, KDM or something else. The Wayland compositor can be Weston or something else.

                The system compositor is at the bottom of the stack, and basically doesn't do any actual compositing per se, it just switches inputs between splash screen, display manager and the actual compositor.
                This isn't the first time that I read about "switching input" and I think that this should be more detailed because I'm not sure that I fully get it: is-it just sending input events (like mouse clicks, keyboard) to either the splash screen, the display manager or the actual compositor?
                But what about the *output*? Each of these component display things.. So either they takeover the videocard in which case there may be some synchronisation issue or the system compositor must "compose" their output but this reduce performance because now the composition is done twice (once in the session compositor, once in the system compositor).

                Comment


                • #23
                  Originally posted by renox View Post
                  This isn't the first time that I read about "switching input" and I think that this should be more detailed because I'm not sure that I fully get it: is-it just sending input events (like mouse clicks, keyboard) to either the splash screen, the display manager or the actual compositor?
                  But what about the *output*? Each of these component display things.. So either they takeover the videocard in which case there may be some synchronisation issue or the system compositor must "compose" their output but this reduce performance because now the composition is done twice (once in the session compositor, once in the system compositor).
                  Well the way I understand it (again, anyone who knows better, correct be if I'm wrong) wayland works by passing references to buffers. So the window manager composites the buffers from the clients, then it writes the composited image on the buffer given by the system compositor. But since the system compositor doesn't do any actual compositing, it can pass a direct reference to video memory instead, so in practice the window manager writes directly on the screen, except in the transition periods where the system compositor changes its input from window manager to display manager or vice versa. So there shouldn't be any performance loss, and this also allows effects like crossfades between the dm and wm.

                  Also, it seems that the system compositor is an optional part of the stack, it's not necessary to have it at all.

                  Comment


                  • #24
                    Originally posted by dee. View Post
                    But since the system compositor doesn't do any actual compositing, it can pass a direct reference to video memory instead, so in practice the window manager writes directly on the screen, except in the transition periods where the system compositor changes its input from window manager to display manager or vice versa. So there shouldn't be any performance loss, and this also allows effects like crossfades between the dm and wm.
                    Interesting, thanks for your reply, IMHO your reply is similar to "each component take over the videocard", but there is still a fuzzy point: if there is a need to change the state of the videocard (to change the resolution for example), who is doing it? (1) the session compositor or (2)the system compositor.

                    Comment


                    • #25
                      Originally posted by renox View Post
                      Interesting, thanks for your reply, IMHO your reply is similar to "each component take over the videocard", but there is still a fuzzy point: if there is a need to change the state of the videocard (to change the resolution for example), who is doing it? (1) the session compositor or (2)the system compositor.
                      Well, I'm not totally clear on those kind of details. But from what I understand, Wayland is supposed to be designed so that clients can only request a change of resolution, and it's up to the compositor (and user settings) how it responds to the request. So I guess it depends on the implementation. In the case of a system with two nested compositors, it could probably be set up so that client requests resolution X from the window manager, and if the window manager is configured to allow clients to change the resolution, it will then request the system compositor for a change of resolution, and if the system compositor is configured to allow the window manager to change the resolution, it will then change the resolution. But it could also be that the window manager gets the request, and then says "no, I will just keep the native resolution, but I'll resize the client's buffer to fit the screen" or something else, whatever it's configured to do.

                      Comment

                      Working...
                      X