Created attachment 125054 [details] dmesg output Since commit 9b58e352b463f2f096d699d47b1c4c57879b617f which enables PSR by default on Haswell, my external screen flashes as long as the system is docked and idle. Moving the mouse or compiling a kernel keeps the screen readable. When it flashes it looks like it takes a single line of output and fills the screen with this line. The issue goes away by adding i915.enable_psr=0 or i915.enable_psr=2 to the kernel command line. System Information Manufacturer: LENOVO Product Name: 20ANCTO1WW Version: ThinkPad T440p Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz Running openSUSE 13.2 and KDE. > cat /sys/kernel/debug/dri/0/i915_edp_psr_status^ i915_edp_psr_status Sink_Support: yes Source_OK: yes Enabled: yes Active: yes Busy frontbuffer bits: 0x000 Re-enable work scheduled: no Main link in standby mode: yes HW Enabled & Active bit: yes Performance_Counter: 76716 Attaching dmesg output.
Thanks for a good bug report. I know it's a lot to ask, but could you test whether connecting the display directly to the laptop (rather than through a docking station) makes a difference? Also, could you try drm-intel-nightly? I realise it's a bit of a hassle, but there have been quite a lot of patches related to PSR (and to MST, which might be how your display is connected via the docking station) merged since the 4.6 kernel.
Sorry, forgot to mention that I did in fact test with yesterday's drm-intel-nightly before posting the bug report. Commit 9561f5c5e1918cfaeb2a39f90eed046730ae7399 to be precise. Trying with the display directly connected to the laptop using a DP cable I get more or less the same results. Instead of screen flashes the screen goes completely blank though. It does come back when I move the mouse or run some compilation. I'm also going to attach the results of the kms_psr_sink_crc kms_frontbuffer_tracking tests as was indicated by the Enable PSR commit. Took a while to find that "kms_psr_frontbuffer_tracking" as written in the commit message is not the correct name ;) Please tell me where else I can dig to get you needed information. Btw. the external display is a HP ZR24w
Created attachment 125073 [details] Results of kms_psr_sink_crc tests
Created attachment 125074 [details] Results of kms_frontbuffer_tracking tests
I've now tested this on a ThinkPad Yoga (I don't have access to any ThinkPad T440p) with a Core i5-4200U (HD Graphics 4400), and a HP ZR24w display connected via the mini-HDMI connector on that laptop. With PSR enabled (/sys/module/i915/parameters/enable_psr == 1) and drm-intel-nightly from 28th of September I cannot reproduce this. I am *not* using the xserver-xorg-video-intel driver, my setup is using the xorg modesetting driver. That's the only difference I can think of (except that I'm not using the except same laptop model, obviously). I've tested setting the external display as a secondary display, and as a mirror, both worked as they should. Before testing I ran powertop --auto-tune (to ensure that nothing blocks power management).
removing regression-keyword due to failure to be visible with parameter change on kernel. PSR is disabled on HSW by default at this point.
*** Bug 98583 has been marked as a duplicate of this bug. ***
Hello Nine, Is this still reproducible on latest kernels? A lot of changes have been made since 4.7, could you try last drm-tip and check if the problem persist? Thanks.
Sorry for the late reply. On Saturday's drm-tip (4.13.0-rc3-6.g3a35823-default+) the issue is gone. Of course that's to be expected as PSR seems to be disabled by default: > cat /sys/kernel/debug/dri/0/i915_edp_psr_status Sink_Support: yes Source_OK: no Enabled: no Active: no Busy frontbuffer bits: 0x000 Re-enable work scheduled: no Main link in standby mode: no HW Enabled & Active bit: no Performance_Counter: 0
(In reply to nine from comment #9) > Sorry for the late reply. > On Saturday's drm-tip (4.13.0-rc3-6.g3a35823-default+) the issue is gone. Of > course that's to be expected as PSR seems to be disabled by default: > > > cat /sys/kernel/debug/dri/0/i915_edp_psr_status > Sink_Support: yes > Source_OK: no > Enabled: no > Active: no > Busy frontbuffer bits: 0x000 > Re-enable work scheduled: no > Main link in standby mode: no > HW Enabled & Active bit: no > Performance_Counter: 0 Thanks for the updated. The bet is that now is detecting correctly that is a HSW. Then I'm proceeding to close this bug. If problem arise again please file a new bug with HW /SW information and logs. Thanks again.
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.