GNOME Bugzilla – Bug 523272
libwnck stops tracking window state after xrandr update
Last modified: 2018-01-24 13:44:39 UTC
Please describe the problem: I use xrandr to switch between single-head and dual-head desktop. Every now and then after a switch the window list and workspace applets on my panel stop updating their information and just keep showing a now-stale picture. Restarting gnome-panel *or* compiz fixes things. Steps to reproduce: 1. Use xrandr to change the output configuration (e.g. xrandr --output VGA --above LVDS, if you happen to have a laptop with intel video) 2. Look at the workspace applet Actual results: The workspace applet should reflect the changed desktop size. It should also indicate the active workspace and show open windows. Expected results: The workspace applet shows the old picture. It doesn't change when you move windows around, open or close windows, or switch between workspaces. The task list doesn't update either. Does this happen every time? No, but it happens pretty often. Other information:
This is hard to reproduce on purpose. I wanted to check whether this also happens with metacity, and repeated several iterations of xrandr --output VGA --auto --above LVDS xrandr --output VGA --off without managing to reproduce the bug. I then did the same with compiz -- no bug either, after several tries. However when I'm not intentionally trying to reproduce, it happens -- I saw it earlier today, after doing just this with xrandr (and with several hours of work between the --above and the --off incantations). I also had more windows open than I do right now.
Marius: are you still seeing this? If this was hard to reproduce, then I have some hopes that maybe it's now just fixed ;-)
Yes, I just saw this last week on Ubuntu 8.10 with GNOME 2.24.1. On the other hand I'm mostly certain now it's not libwnck's fault. When I use xrandr with Compiz running, one of the following things happen with approximately equal probability: (0) things work fine (1) the whole screen (except for the hardware-drawn mouse cursor) stops updating and just shows whatever happens to be in the video memory -- until I restart compiz (blindly), after which things work fine (2) compiz draws a smaller desktop in the top-left corner, and the rest of the screen shows whatever happens to be in video memory It's possible (1) and (2) are the same bug, where (1) happens when I shrink the desktop and (2) happens when I enlarge it. (3) window list, workspace switcher, and window switcher applets stop updating; everything else works fine until I restart compiz (or gnome-panel) <-- this bug (4) the Applications/Places/System menu becomes invisible, multiload applet stops updating, I think the calendar applet also becomes invisible -- things get fixed when I restart compiz (or gnome-panel) <-- very similar to this bug, but different (5) the X server crashes with an assertion error in mesa, and I'm left staring at a new gdm login screen and thanking Firefox for the restore-session-after-crash feature. Actually, now that I think more, it may be that I saw bug (4) rather than bug (3) last week. Bug (5) makes me reluctant to use xrandr often, as you can imagine. ;) I seem to remember that when I last studied this bug, I could interact with the workspace applet -- clicking on it would correctly turn me to the right cube face, but the applet would not redraw itself showing the newly activated workspace as the current one. Bug (4), on the other hand, makes the affected applets stop interacting with me -- again, if I remember correctly. Next time this happens, I'll head over here and update the report. Is there any interesting debugging info I could supply? Is there some way to intercept the messages pasing between libwnck and the window manager, to bisect the problem? Would strace help?
Marius: well, I would first try with metacity to see if there's still a bug ;-) There's no magic way to debug this, unfortunately. I guess adding a new panel on another border with the same applets to see if they exhibit the same issue would be a good first step.
Just reproduced (unintentionally) the bug in Ubuntu Jaunty: xrandr and the workspace switcher applet stops redrawing. A newly added workspace switcher on a new panel works fine, and so does a new workspace switcher added to an existing panel. This would indicate that the bug is in the applets themselves, rather than in libwnck, no?
Hey, I just discovered that it is sufficient to alt-drag the panel from bottom to top to get the workspace and window list applets to unfreeze (they're both on the bottom panel in my configuration).
I'm really unsure what's going on there, but someone able to reproduce it should just play with gdb, I guess :/
I have not seen this bug affect my window list applet in a long while. I've seen something very similar, which I think is the same bug, and which makes me think it has nothing at all to do with libwnck. Sometimes, after an xrandr desktop size change (single monitor -> dualhead or back), some of my windows stop being redrawn. This affects only maximized windows. Sometimes it affects GNOME panels (especially one I've just added on the newly-attached monitor, with the result that when I try adding new applets to it, I still see an empty panel until I apply the workaround and then discover those new panels actually are there). The workaround is the same: change the size/position of the window (e.g. alt-drag the panel). This might be a Compiz bug, or it might be an X server bug (DAMAGE events getting lost? I don't even know if Compiz uses those, actually, just stumbling in the dark), but it's unlikely to be a libwnck bug.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libwnck/issues/102.