I often use a 1080p HDMI monitor configured to be the primary screen, on the left of the 1600x900 laptop screen. When unplugging the HDMI, kscreen reconfigures the display. Then randomly, I get something like the attached screenshot : - the cursor is correctly displayed - the konsole window, which was on the monitor, is displayed scaled on the bottom left of the screen - the rest of the screen displays some static content (here it's the konsole window too, but it depends, and it won't update any more) - I opened krunner later : it's scaled like the konsole window, but you can see its blurred area on the right Reproducible: Sometimes "xrandr --verbose" is normal "kwin --replace" fixes the problem. I never reproduced the bug with "xrandr --output HDMI1 --off", but the final screen configuration is the same, so it could be a race condition or different intermediate states.
Created attachment 81432 [details] screenshot
Created attachment 81433 [details] qdbus org.kde.kwin /KWin supportInformation It's the one after the HDMI unplug (it's the same whether the bug happened or not). Before, it's the same, but with : Number of Screens: 2 Screen 0 Geometry: 0,0,1920x1080 Screen 1 Geometry: 1920,180,1600x900
Looks like bug #322156, but that was so far only confirmed for EGL. One thing: > OpenGL version string: 3.0 Mesa 9.2.0-devel Does it also happen with stable MESA?
There is no stable mesa on F19 repositories, I will try to build it myself. I don't remember seeing this bug with KDE 4.10.x, but it doesn't mean it cannot be mesa.
Reproduced with my mesa 9.1.5 build.
It's a very wild guess, but in case you (can) build kwin, please try the impact of https://git.reviewboard.kde.org/r/111416/
I tried the patch on top of KDE/4.11 branch. It seems to fix the bug in the usual case, but I managed to reproduce it by switching to another VT, unplugging HDMI, then switching back to X11 VT (screen reconfiguration happens at this moment). While this second use case seems quite unusual, I need it since I have another screen which doesn't seem to trigger the unplug event until a VT switch (perhaps a kernel issue, I need to look at it). It may be unrelated, but I have an error trace when plugging the HDMI (not on unplug). It's the same with or without the patch. KWin::checkGLError: GL error ( PostPaint ): "GL_INVALID_VALUE"
If I understand correctly, the timer is here to improve performance by squashing multiple XRandR events together. But it also helps masking kwin or driver bugs by reducing intermediate states. With the patch still applied, I tried several experiments : 1) change the timer interval to 1s : - the VT switch case still doesn't work - on the simple HMDI unplug, I can see an intermediate state where the screen is like the screenshot 2) in shortcut case, don't stop the timer (so there will still be an additional "changed" event) Everything seems to work properly 3) Remove the timer, connecting desktop signals to updateCount() and changed() Both cases show the bug. So it seems the delayed "changed" signal provided by the timer is useful, but why ?
(In reply to comment #8) > So it seems the delayed "changed" signal provided by the timer is useful, > but why ? It triggers a second signal on the now "correct" values which fixes the setup. The shortcutting was (only) necessary because otherwise we operated on non existsing screens - causing out of bound accesses. We'll require a solution that fixes the clients screen attachment immediately (to prevent out of bound crashes) but leaves the scene alone until the randr storm has settled down.
The question was more : why is the timer needed to work correctly ? It should only be here to reduce unnecessary intermediate steps. I tried without the timer, with a "changed" signal emitted on every screenCountChanged/resized signal received from the QDesktopWidget, but it's didn't work. I added some traces, and I didn't see any change in m_desktop->screenGeometry()/m_desktop->screenCount() which wasn't preceded by the correct QDesktopWidget signal. Is someone is using this "changed" signal for things which aren't tracked by the QDesktopWidget, so which can happen after it has emitted its signals ?
Concurrent event handling and value access between kwin and QDesktopWidget, i'd say. This patch should work (conflicts with the other one) and just ensures to validate the screen count (preventing the crash) but defers the scene update (which is expensive enough to blur several updates anyway) https://git.reviewboard.kde.org/r/111811/
(In reply to comment #11) > This patch should work (conflicts with the other one) and just ensures to > validate the screen count (preventing the crash) but defers the scene update > (which is expensive enough to blur several updates anyway) > > https://git.reviewboard.kde.org/r/111811/ It works for me. I tried everything I could imagine : plug/unplug while compiling, with VT switch, during standby : no problem.
Git commit b0dbf3b49adf26753805cd59576dd3db61b86328 by Thomas Lübking. Committed on 31/07/2013 at 10:55. Pushed by luebking into branch 'KDE/4.11'. validate screens w/o direct update largely reverts b164e9912c9b5f9c9ae619bbd79355d317174115 which prevented the crash but due to early screen updating causes issues with scene/overlay update on at least intel chips Related: bug 322156 FIXED-IN: 4.11 REVIEW: https://git.reviewboard.kde.org/r/111811/ M +5 -16 kwin/screens.cpp M +3 -20 kwin/screens.h http://commits.kde.org/kde-workspace/b0dbf3b49adf26753805cd59576dd3db61b86328