| Summary: | "Scaled" display after unplugging HDMI monitor | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Loïc Yhuel <loic.yhuel> |
| Component: | multi-screen | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | Flags: | thomas.luebking:
ReviewRequest+
|
| Priority: | NOR | ||
| Version: | 4.10.95 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| URL: | https://git.reviewboard.kde.org/r/111811/ | ||
| Latest Commit: | http://commits.kde.org/kde-workspace/b0dbf3b49adf26753805cd59576dd3db61b86328 | Version Fixed In: | 4.11 |
| Sentry Crash Report: | |||
| Attachments: |
screenshot
qdbus org.kde.kwin /KWin supportInformation |
||
|
Description
Loïc Yhuel
2013-07-30 00:50:56 UTC
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 |