Bug 322970 - "Scaled" display after unplugging HDMI monitor
Summary: "Scaled" display after unplugging HDMI monitor
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: multi-screen (show other bugs)
Version: 4.10.95
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL: https://git.reviewboard.kde.org/r/111...
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-30 00:50 UTC by Loïc Yhuel
Modified: 2013-08-06 08:28 UTC (History)
0 users

See Also:
Latest Commit: http://commits.kde.org/kde-workspace/b0dbf3b49adf26753805cd59576dd3db61b86328
Version Fixed In: 4.11
thomas.luebking: ReviewRequest+

Attachments
screenshot (65.55 KB, image/png)
2013-07-30 00:53 UTC, Loïc Yhuel 		Details
qdbus org.kde.kwin /KWin supportInformation (4.85 KB, text/plain)
2013-07-30 00:56 UTC, Loïc Yhuel 		Details
View All Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Loïc Yhuel 2013-07-30 00:50:56 UTC 
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.
Comment 1 Loïc Yhuel 2013-07-30 00:53:07 UTC 
Created attachment 81432 [details]
screenshot
Comment 2 Loïc Yhuel 2013-07-30 00:56:40 UTC 
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
Comment 3 Thomas Lübking 2013-07-30 09:42:57 UTC 
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?
Comment 4 Loïc Yhuel 2013-07-30 12:06:47 UTC 
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.
Comment 5 Loïc Yhuel 2013-07-30 13:08:05 UTC 
Reproduced with my mesa 9.1.5 build.
Comment 6 Thomas Lübking 2013-07-30 13:41:49 UTC 
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/
Comment 7 Loïc Yhuel 2013-07-30 16:53:59 UTC 
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"
Comment 8 Loïc Yhuel 2013-07-30 19:47:50 UTC 
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 ?
Comment 9 Thomas Lübking 2013-07-30 21:12:49 UTC 
(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.
Comment 10 Loïc Yhuel 2013-07-30 21:32:20 UTC 
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 ?
Comment 11 Thomas Lübking 2013-07-31 11:16:02 UTC 
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/
Comment 12 Loïc Yhuel 2013-07-31 19:46:56 UTC 
(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.
Comment 13 Thomas Lübking 2013-08-06 08:28:51 UTC 
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