On Mon, Mar 7, 2011 at 3:41 AM, Bill Spitzak <[email protected]> wrote: > I think the original poster's idea is exactly what is needed: > > I the compositor crashes or exits, the clients will detect this. It is then > the client's job to find a new compositor and recreate their state on the > new one. Most toolkits store quite enough redundant information that they > should be able to do this, I would suspect the biggest trick will be to > completely forget any ids from the previous compositor.
Indeed - we also need to make a difference here between the session going down and the compositor going down. Right now the assumption is that dead X server == dead session, since there is some minimal session management built in there (also because normal users couldn't for the longest time run the X server, so it was assumed that the privileged user would start it up again and bring it back to XDM) > > The way the client will detect when the new compositor is available is by > following exactly the same rules they use when the first start up to locate > the compositor. If for instance when a client starts it attempts to open a > named pipe, this is exactly what it will do after the previous compositor > exits. If it fails to open it probably should try repeatedly with a timeout > between each try, and only exit with an error after a very long time (30 > seconds or so). This will give time for the compositor to restart, and would > also solve the current problem where you can't launch a compositor and a > bunch of clients simultaneously. > > Besides handling crashing, this should also be the way to switch > compositors. A compositor could actually force a client to a different > compositor by first modifying the client's environment in whatever way is > needed so it will connect to the new one, then closing the connection. This is quite handy for networking too. > > On Mar 6, 2011, at 10:04 AM, Marty Jack wrote: > >> >> >> On 03/06/2011 12:41 PM, nerdopolis wrote: >>> >>> Hi. >>> >>> >>> I just want to bring this up for early consideration: >>> >>> >>> It seems that many things in Wayland will be determined by they type of >>> compositor server you are running, such as if you want to have a tiling >>> window manager in Wayland, or one that has other features. >>> >>> >>> My question is that will users be able to have the ability to change >>> their Wayland servers on the fly? not only would such a thing allow the >>> users to change functionality, but it will also help in the case if the >>> Wayland server goes down, where the session is not lost. >>> >>> >>> Will this have to happen in the apps themselves? If so, how would the >>> apps "know" that the socket (or maybe even a new socket) is available for >>> reconnect? >>> >>> >>> >>> _______________________________________________ >>> wayland-devel mailing list >>> [email protected] >>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel >> >> An interesting point. A parallel to <window-manager> --replace, and >> probably something that users would want to do while they are experimenting >> with different looks. >> _______________________________________________ >> wayland-devel mailing list >> [email protected] >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > _______________________________________________ > wayland-devel mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- Sam Spilsbury _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
