Rambles around computer science
Diverting trains of thought, wasting precious time
Fri, 27 Feb 2009
Standalone ksmserver, part 1
I've been looking for an X11 session manager that actually works recently (since sadly xsm doesn't fit that bill) and was experimenting with KDE's session manager. It's peculiarly underdocumented but seemed like it should have all the functionality I needed, and should also be reasonably well-used and well-tested. So I was a bit disappointed when my basic set-up attempt at integrating it with fvwm appeared not to work. I was simply replacing the fvwm command in my .xsession with the following:
ksmserver -r -w fvwm
which should launch fvwm rather than kwin. Then in my fvwm configuration, to end the session properly when I quit the window manager, I tried the following.
AddToFunc SessionInitFunction + I Exec echo hello from SessionInitFunction AddToFunc SessionExitFunction # kill ksmserver when we exit + I Exec dcop ksmserver ksmserver logout 0 2 2 ## from http://andrejserafim.wordpress.com/2008/05/16/kde-shutdown-logout-restart/ #First parameter: confirm #Obey the user?s confirmation setting: -1 #Don?t confirm, shutdown without asking: 0 #Always confirm, ask even if the user turned it off: 1 #Second parameter: type #Select previous action or the default if it?s the first time: -1 #Only log out: 0 #Log out and reboot the machine: 1 #Log out and halt the machine: 2 #Third parameter: mode
(Thanks to Andrej Kazakov for the summary of logout's invocation that I pasted above, in turn extracted from the KDE source code.)
Of course, it didn't work, so I put my developer hat on and had a look. Attaching gdb revealed that the session manager was entering a (non-tight) endless loop when I requested the logout---setting a timer which fired after one second, disabled itself and then recursively re-started the process. The problem was that the session manager has an internal state machine, and in my case it was stuck in state AutoStart0, whereas it was expected to end up in Idle after a while---the only state from which it can initiate a shutdown.
To get out of AutoStart0, and subsequent start-up states, you have to manually call a bunch of other DCOP methods with names like autoStart0Done, kcmPhase1Done and so on. This is among what startkde does for KDE users, after performing various KDE-specific configuration updates. (These updates are exactly what a non-KDE user doesn't want to happen, at least in my case---since one major reason I don't use KDE is that I like to stick with the simple X11-provided ways of controlling backgrounds, cursors, input devices and so on.) We can manually invoke the DCOP methods to signal that it's time for the next state.
We successfully avoid most of the KDE interference in this way, because the relevant other processes (like kcminit) haven't been launched. However, we do get some, because the klauncher process does exist -- it's started when running any KDE app if not already running. In particular, ksmserver's signals to klauncher have the unwanted consequence of starting up a bunch of “autostart” applications, like the KDE desktop background and panel, that have shortcuts in ~/.kde/Autostart and /share/autostart/. To avoid this, we tell the launcher to bump our start-up “phase”, which is just an integer, to a high value---since autostart apps are marked with a “phase” attribute, and are only started when moving through that phase. ksmserver only covers as far as phase 2, so we can set the phase to 3 and they won't be started up. So, here's my final fvwm config for use with ksmserver.
[Update, 2009-03-02: not so fast! What I had here earlier didn't quite work, because fvwm doesn't necessarily execute each part of a compound function in sequence. So instead, it needs to all be rolled into one command. What's more, I had to hack in an arbitrary sleep because, depending on how long it takes to start up all the saved clients, the kcmPhase2Done call may come too soon (state machine not yet progressed into FinishingStartup, I think) and be ignored (causing ksmserver to get stuck in the latter state). Now, what follows does seem to work.]
AddToFunc SessionInitFunction + I Exec dcop klauncher klauncher autoStart 3; \ dcop ksmserver ksmserver autoStart0Done; \ dcop ksmserver ksmserver kcmPhase1Done; \ dcop ksmserver ksmserver autoStart1Done; \ dcop ksmserver ksmserver kcmPhase2Done; \ sleep 4; dcop ksmserver ksmserver autoStart2Done # signal ksmserver when we exit AddToFunc SessionExitFunction + I Exec dcop ksmserver ksmserver saveCurrentSessionAs "saved at previous logout"; \ dcop ksmserver ksmserver logout 0 0 3
I still haven't actually made the session management functionality work, which I think is going to take some more commands along “save” and “restore” lines. [Update, 2009-03-02: turns out to need just the one “save” command at exit, as shown above -- restoring happens by default, using the magic session name shown.] My ultimate goal is the ability to start multiple ksmserver processes, so that I can independently save and restore separate groups of clients within a single X login session. Fingers crossed... if it's nontrivial I'll write a follow-up post. There's also the joy of KDE 4 to think about later, which has exchanged DCOP for D-BUS and may well alter the undocumented behaviour I'm relying on.
The Important Science to take away from all this is I suppose that interface protocol specifications and timing specifications are useful! Not just for checking, which seems a long way off here, but just for understanding. It'd also be useful to have more convenient support for interposing on DCOP communication, by having client-specific message routing (or name-bindings) so that the “phase” hack could be handled a bit more elegantly by cutting off the connection to klauncher.
[/devel] permanent link contact
Lab lunch
Often when someone (like me) feels the need to bemoan a relative lack of communication and collaboration within our research group, the topic of food and lunching always comes up. Everybody seems to agree in principle that lunching together is a Good Thing. But I can tell this is never going to happen for me in my time here. The concept of lunching before 1pm is foreign to me, and certainly doesn't appeal. But it appears that in this Laboratory, lunchtime, for all those who take it communally, is almost unfailingly at or before noon! What's that about? Just now I saw a bunch of theory people in West finishing lunch at 12.30. I used to see, from my window, the Xen guys going off in a car to some pub or other every 12 noon. And I'm told the queue starts forming at the burrito van around 11.40am.
It's particularly puzzling because hackers, and computer scientists generally, are stereotypically considered to be a bit nocturnal, and so unlikely to be up particularly early in the morning. You'd think this would shift their eating schedule later, rather than bizarrely early. Perhaps they eat badly, skipping breakfast and therefore taking an early lunch. Perhaps selection pressure has left us with a super-hardworking Lab, where only those who not only stay up late, but also get up early and can survive on almost no sleep, are admitted. Perhaps the stereotype is not at all true. More likely, there's an arms race going on: food is scarce in our back-of-beyond West Cambridge location, so there's a pressure towards earlier lunchtimes for the sake of ensuring a good selection of food remaining at the supply. We should all know better than to participate in such a race, but clearly many don't. In any case, late lunchers are penalised, and this is not a good thing. My chosen lunchtime has been 1.30pm for years now, and since I only finish breakfast around 11am, I refuse to compromise earlier than 1pm. Eat lunch at noon if you like, you strange people, but it'll be without me. Your loss, perhaps, although more likely mine.
[/research] permanent link contact
