Bug 66306 - [HSW ULT] display port can't turn off by using xrandr --output xxx --off
Summary: [HSW ULT] display port can't turn off by using xrandr --output xxx --off
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium major
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-28 08:21 UTC by shui yangwei
Modified: 2017-10-06 14:45 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
dmesg: display port can't turn off by using xrandr (123.84 KB, text/plain)
2013-06-28 08:21 UTC, shui yangwei
no flags Details
picture: 5 X windows come up to screen after running xrandr to turn one display (1.11 MB, image/jpeg)
2013-06-28 08:24 UTC, shui yangwei
no flags Details

Description shui yangwei 2013-06-28 08:21:42 UTC
Created attachment 81621 [details]
dmesg: display port can't turn off by using xrandr

Environment:
-------------
kernel: (drm-intel-next-queued)9199918a1e148c18e3519cb7b2d90a127d7ea87b
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Jun 27 17:52:15 2013 +0200
          drm/i915: fix hpd interrupt register locking

HW info:
-------------
Shark Bay ULT Pre-Beta (Sawtooth Peak Fab3): 
Host bridge id=0x0a04 (rev 09)  
CPU i7-4550U 1.50GHz,cpu MHz:1400  
BIOS version: V126; 

Description:
------------
If I execute "xrandr --output xxx(eDP or DP or HDMI) --off", I find the screen is not turned off, and 5 X box will pop up. I attached the photo and dmesg here.


Reproduce steps:
--------------------
1. xinit &
2. xrandr --output eDP1 --off
Comment 1 shui yangwei 2013-06-28 08:24:11 UTC
Created attachment 81622 [details]
picture: 5 X windows come up to screen after running xrandr to turn one display
Comment 2 Chris Wilson 2013-06-28 11:12:17 UTC
A photo of the desktop before running xrandr would be useful to put the later picture into context.

I presume that you did have an xterm open, in which case instead of the pipe shutting down we left it enabled and sampling from a smaller framebuffer.
Comment 3 shui yangwei 2013-07-01 02:42:35 UTC
(In reply to comment #2)
> A photo of the desktop before running xrandr would be useful to put the
> later picture into context.
> 
> I presume that you did have an xterm open, in which case instead of the pipe
> shutting down we left it enabled and sampling from a smaller framebuffer.

Today, I find the phenomenon of test result become different. I test with latest -next-queued kernel, and eDP can be turned off, but DP and HDMI can't. If I re-enabled eDP, the other two monitor turned to black. I will file a new bug to track this issue. I think this bug can be closed.
Comment 4 Daniel Vetter 2013-07-01 08:14:30 UTC
Hm, that's interesting. Can you please bisect where the behaviour changed? And when you report the new bug please add links to both bugs so that we can find thema again.
Comment 5 shui yangwei 2013-07-02 08:09:59 UTC
(In reply to comment #4)
> Hm, that's interesting. Can you please bisect where the behaviour changed?
> And when you report the new bug please add links to both bugs so that we can
> find thema again.

Today I retest HSW ULT, and I find the test results changed again.(Today I'm using another disk, this is the only different with before). The result is much more clearly now. If use -next-queued kernel, I can  reproduce the bug below:
"Bug 66294 - [HSW mobile] eDP fails to restore backlight". The other two pipe(DP and HDMI) worked well.

If I use -nightly latest kernel, I find all pipe can worked very well, and restored perfect.

Now, I think there's no need to report a new bug. I will checked the disk which I used before.
Comment 6 Chris Wilson 2013-07-17 11:47:09 UTC
Worked in -nightly, so presuming fixed.
Comment 7 Elizabeth 2017-10-06 14:45:27 UTC
Closing old verified.


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.