LightDM Caught Off-Guard By Mir, Plans For Wayland

[Akka]

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.

[renox]

Ok so from what I gather it looks something like this (please correct me if I'm wrong about any of this):

+ 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).

[dee.]

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.

[renox]

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.

[dee.]

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.