On 21.10.2011 15:16, Julien Danjou wrote: > I just hit a bad bug. awesome would not start! > > I discovered that this was caused by obvious. I use the volume_alsa > widget, which runs amixer. But I had pulseaudio installed. And doing a: > > xtrace amixer -c 0 -- get Master > > showed that the pulseaudio plugin of alsa was run and tried to connect > to the X server to fetch some atoms. > The problem is that while startup, awesome is grabbing the X server. > Therefore, the awesome startup was totally blocked. > > Removing pulseaudio resolved the problem for now, but I think we should > do something in obvious to avoid that, like unsetting the DISPLAY > environment variable. > > WDYT?
That problem is relatively common. I only ever saw it happening due to pulseaudio. In other news, you have a great timing. Let's look at the recent git history for the master branch: commit bf76b3842b92922b8d3fa23a105d9e9b1aad521c Author: Uli Schlachter <[email protected]> Date: Wed Oct 19 15:11:11 2011 +0200 Ungrab the server before parsing the config This moves the loading of the rc.lua and managing of pre-existing clients to after we ungrab the server during startup. To make sure we have no races with clients which start up parallel to awesome, we do the QueryTree for all the clients that we have to manage before the ungrab, but start managing the clients only after the ungrab. This means that we have already selected our event mask on the root window in scan() and thus received an UnmapNotify event when we reparent windows into a frame window. This has the effect that we immediately unmanage the client again, whoops. To fix this, we grab the server again and remove our event mask on the root window again while we reparent. This should hopefully fix all cases where we deadlock during startup because pulseaudio wants to talk to the X server, but is being ignored because we have the server grabbed while at the same time we are waiting for pulseaudio. Signed-off-by: Uli Schlachter <[email protected]> To make this perfect, this just needs someone to port it to the 3.4 branch. That won't be me since I don't have the necessary stuff for that since quite a long time. That shouldn't actually be too hard. I don't think the patch would apply cleanly, but if someone fixes that up bad hand *and actually tests the result*, stuff should be working smoothly. Thinking about it, I'm not sure if all that patch is even necessary in 3.4. 3.4 isn't a reparenting WM and thus it wouldn't get an UnmapNotify due to the reparent which should make the hack in client.c unnecessary... @jd: Are you on the 3.4 branch or is your git clone just too old? Did I break your config badly enough to make you switch to 3.4? :-) Uli -- "Do you know that books smell like nutmeg or some spice from a foreign land?" -- Faber in Fahrenheit 451 -- To unsubscribe, send mail to [email protected].
