TDE session manager (ksmserver) -------------------------------- Matthias Ettrich Lubos Lunak ksmserver is TDE's new session management server. It talks the standard X11R6 session management protocol (XSMP). Thus, in theory, it should be compatible with all session managment compliant X11R6 applications. Unfortunately, there aren't that many of them. To be precise, I have never seen a single commercial application that supports it and even within the official X11R6 distribution, 'xclock' is the only exception. Nevertheless we've chosen to support XSMP despites the complexity of the protocol in order to provide TDE users more interoperability with applications that were not explicitely written with TDE in mind. XSMP, as an official X standard, promised to be more likely to be supported by third parties than even a superior TDE-specific protocol. Let's see whether we were right and more applications will actually talk XSMP. At least all TDE applications do now. Here's a short overview on how session management works. Starting the server ------------------- The server is usually started from the 'starttde' script. It supports the following options: -r, --restore Restores the previous session if available -w, --windowmanager Starts 'wm' in case no other window manager is participating in the session. Default is 'twin' The default 'starttde' launches 'ksmserver --restore'. The 'windowmanager' option is useful for users that prefer a window manager other than twin. Since the window manager has to participate in the session (it has to remember window positions and states), it is usually restarted when the session is restored. To be *really* sure that this happens, even if the wm might have crashed during the previous session, ksmserver ensures that. The option specifies, which windowmanager shall be launched for sure. But again: if the stored session contains a window manager, the restored one will be used, not the specified one. As a special feature, ksmserver always starts the specified window manager first, which results in a much nicer startup sequence (less flashy). TDE startup sequence -------------------- Ksmserver controls the second part of the TDE startup sequence, after it gets control from the starttde script, which controls the first part of the startup sequence. All code related to startup should be in startup.cpp and going down in that source file should follow the startup order (but note that this is just a documentation which may get outdated, so in case of doubts the source wins ;) ). The starttde scripts already launches tdeinit, which in turns launches TDE daemons like dcopserver, tdelauncher and kded. Kded loads autoloaded kded modules, i.e. those that have X-TDE-Kded-autoload=true in .desktop files. The exact way autoloading works is controlled by X-TDE-Kded-phase=, which may be 0, 1 or 2 (the default). Kded phase 0 means the module is always loaded by kded, even outside of TDE session. It should used only by kded modules which must be always running. Kded phase 1 modules are loaded right after kded startup, but only during TDE startup, i.e. it is for modules that are always needed by the TDE session. Phase 2 modules will be loaded later. Startkde also launches kcminit, which performs initialization done by kcontrol modules. There are three kcminit phases, 0, 1 and 2, controlled by X-TDE-Init-Phase= in the .desktop file, which defaults to 1. Phase 0 kcminit modules should be only those that really need to be run early in the startup process (and those should probably actually use tdestartupconfig in starttde to be done even before tdeinit and daemons). After executing phase 0 modules kcminit returns and waits. When ksmserver is launched, the first thing it does is launching the window manager, as the WM is necessary before any windows are possibly shown. When the WM is ready, ksmserver tells tdelauncher to perform autostart phase 0 ($TDEHOME/share/autostart). There are 3 autostart phases, 0, 1 and 2, defined by X-TDE-autostart-phase, defaulting to 2. Phase 0 is reserved only for the actual visible base components of TDE, i.e. KDesktop and Kicker, in order to make the startup appear visually faster. Both KDesktop and Kicker use DCOP calls suspendStartup() and resumeStartup() to make ksmserver stay waiting for autostart phase 0 until both KDesktop and Kicker are ready. Next step is telling the waiting kcminit to perform phase 1 - all kcminit modules that should be executed before TDE startup is considered done. After that ksmserver tells tdelauncher to perform autostart phase 1, i.e. launching normal components of TDE that should be available right after TDE startup, and after this session restore is performed, i.e. launching all applications that were running during last session saving (usually logout). By this time TDE session is considered to be more or less ready and ksmserver does the knotify starttde event (i.e. plays the login sound). It also tells tdelauncher to perform autostart phase 2, kded to load all remaining autoload (i.e. kded phase 2) modules, kcminit to execute kcminit phase 2 (kcontrol modules that do initialization that can wait, like launching daemons) and kdesktop to execute the user Autostart folder. Technical note: There's a reason why kded modules and items in autostart default to the latest phase. Before you explicitly use a different phase, read and understand what's above. You should also consider whether something really needs to be launched during TDE startup and can't be loaded on-demand when really needed. Abusing the phases will result in public spanking for making TDE startup slower. Establishing the connection --------------------------- As required by the XSMP specification, the session management server propagates its network address in the SESSION_MANAGER environment variable. Probably not the best way to do it, but it's the way it is. All TDE (and plain Qt) applications simply read this variable and try to establish a connection to an XSMP server at this address. If the variable is undefined, nothing happens. This means, if you want to start a program that should not participate in the session, simply undefine SESSION_MANAGER in your terminal window and launch the application. If you want to see an application desparately trying to connect to something, try setting it to some bogus value. In addition, ksmserver propagates both its network address and its process id in ~/.trinity/socket-$HOSTNAME/KSMserver-$DISPLAY. A utility function TDEApplication::propagateSessionManager() reads this setting and sets SESSION_MANAGER accordingly, so that child processes can pick it up. The function is called by clients that are started outside the session ( i.e. before ksmserver is started), but want to launch other processes that should participate in the session. Examples are kdesktop or kicker, see below. Authorization ------------- XSMP is, just like DCOP, built on top of the Inter Client Exchange (ICE) protocol, which comes standard as a part of X11R6 and later. Authorization is done using 'iceauth', with MIT-MAGIC-COOKIE as used by X. In order to be able to access the session management server, you need to be able to read ~/.ICEauthority. For security reasons, we do not provide any host-based authorization (neither does DCOP, btw.). Requesting a shutdown --------------------- If an application wants to request a shutdown (i.e. a logout), it does this via an SmcRequestSaveYourself message to the server. In TDE, a utility function TDEApplication::requestShutDown() does exactly this. It's for example called by TDE's panel or by the context menu of the desktop. User Interface -------------- ksmserver has a very straight-forward user interface. It mainly asks the question "Shutdown TDE Session?" and provides two obvious command buttons "Yes" and "Cancel". The interesting bit is the additonal checkbox that says "Restore session when logging in next time". The checkbox remembers state within session, so simply use whatever you prefer. For those who remember, this was one of the main questions with TDE-1.x ("How to get rid of session managment?"). With TDE-2.x, most users will probably prepare a session once, store it with the checkbox enabled and keep the checkbox disabled in the future. This way you get a proper and clean 'homesession' each time. Troubleshooting --------------- If you experience trouble like 'logout does not work anymore' or 'I cannot start new applications', as a result of a previous crash, ensure that ksmserver is indeed not running anymore and remove the file ~/.trinity/socket-$HOSTNAME/KSMserver-$DISPLAY. Shouldn't be necessry, but one never knows.