Bug 88826 - [sna suse] screen is not redrawn after dpms on
Summary: [sna suse] screen is not redrawn after dpms on
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Chris Wilson
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-27 15:14 UTC by Jiri Slaby
Modified: 2015-02-04 09:16 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
xorg log (47.44 KB, text/plain)
2015-01-27 15:14 UTC, Jiri Slaby
no flags Details
Always restore the scanout (6.15 KB, patch)
2015-02-03 18:42 UTC, Chris Wilson
no flags Details | Splinter Review

Description Jiri Slaby 2015-01-27 15:14:28 UTC
Created attachment 112886 [details]
xorg log

Having sna 2.99.917-52-g913afaf24920, if I leave the machine and it goes dpms off/standby and later I wake it by some event, the screen is not redrawn. I.e. monitors are turned on, but I see old time, old status of my IM client (being away), old window contents. It takes some time, or maybe it is waiting for me to hover the apps (and the task bar) to see the up-to-date contents.

It must be one of the latest changes (either mesa patch from bug 80948 or sna updates due to bug 70461) to cause this, since this is a new behaviour.
Comment 1 Chris Wilson 2015-01-27 21:11:25 UTC
Do you have a compositing WM? Nothing has dramatically changed, at least so I thought. How much gets redrawn at a time?
Comment 2 Jiri Slaby 2015-01-29 09:11:40 UTC
(In reply to Chris Wilson from comment #1)
> Do you have a compositing WM?

Yes, it's KDE4 with opengl 2.o  compositing and native qt.

> How much gets redrawn at a time?

From my observation, whole screen is redrawn at a time.
Comment 3 Chris Wilson 2015-01-29 15:30:10 UTC
I've mixed in some testing of fedora 21 + KDE4 (with opengl2.0, native and automatic vsync) today to see if I could reproduce the dpms off/on issue. Afaict the screen came back with the right time in the system tray.
Comment 4 Chris Wilson 2015-02-03 10:45:25 UTC
This one is bugging me. First of all are you still able to reproduce it easily?

Could you please capture a full-debug log of master and of 2.99.917 (since I presume it is the recent DPMS reworking) and let me see if I can spot a crucial difference?
Comment 5 Chris Wilson 2015-02-03 18:42:09 UTC
Created attachment 113132 [details] [review]
Always restore the scanout
Comment 6 Chris Wilson 2015-02-04 09:16:41 UTC
I think I have it resolved:

commit 3855a728e5522452f0d6208e569ef23389d32d20
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Feb 3 17:06:27 2015 +0000

    sna: Always restore the scanout on DPMS on
    
    As we may exchange the frontbuffer whilst the outputs are hidden (DPMS
    off), when we turn them back on, unless we force the CRTCs to be
    updated, we may end up simply showing a stale scanout buffer not the
    current frontbuffer. If the two are same, it will just be a kernel
    no-op.
    
    Reported-by: Jiri Slaby <jirislaby@gmail.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88826
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.