Created attachment 130992 [details]
dmesg with drm.debug=0x1e log_buf_len=1M
-- system architecture: x86_64
-- kernel version: 4.11.0-rc7+ (from drm-tip commit bc781a3cf9a80e4c5ed0d47fd0c67923bcfcdf2c), same happens with 4.10.11
-- Linux distribution: Gentoo
-- Machine or mother board model: Gigabyte Z170X-Gaming 7 rev 1.0 (includes Alpine Ridge) and Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
-- Display connector: DP
-- Monitor: Samsung LU28E590DS/EN
When the monitor is meant to be off with DPMS, it instead alternates between backlight off and backlight on every few seconds. When the backlight is on, the monitor's OSD says "DisplayPort" in the top left as if it's just been connected.
If done from X with "xset dpms force off", the screen is black except for the "DisplayPort" indicator. If done from the console with "setterm -blank force", then the console appears when the backlight alternates to on. This is not caused by input; it works fine with HDMI.
Motherboard | Distro | Connection | Monitor | Result
Z170X-Gaming 7 | Gentoo | DisplayPort | Samsung | Alternates
Z170X-Gaming 7 | Gentoo | USBC->DisplayPort| Samsung | Alternates
Z170X-Gaming 7 | Gentoo | HDMI 2.0 | Samsung | Correct
Z170X-Gaming 7 | Gentoo | DisplayPort->DVI | Sceptre | Correct
Z170X-Gaming 7 | Gentoo | USBC->VGA | Sceptre | Correct
Z170X-UD5 TH | Ubuntu 16.10 | USBC->DisplayPort| Samsung | Correct
USBC connection means the Thunderbolt Type C port with an adapter.
The baseline monitor is a Sceptre X24WG-1080P with VGA and DVI inputs.
Alternates is the problem that the monitor backlight turns on and off every few seconds. Correct means the backlight stays off.
Relevant piece of xrandr --verbose:
DP3 connected 3840x2160+0+0 (0x4a) normal (normal left inverted right x axis y axis) 610mm x 350mm
CRTCs: 0 1 2
Transform: 1.000000 0.000000 0.000000
0.000000 1.000000 0.000000
0.000000 0.000000 1.000000
Broadcast RGB: Automatic
supported: Automatic, Full, Limited 16:235
supported: force-dvi, off, auto, on
supported: Good, Bad
3840x2160 (0x4a) 533.250MHz +HSync -VSync *current +preferred
h: width 3840 start 3888 end 3920 total 4000 skew 0 clock 133.31KHz
v: height 2160 start 2163 end 2168 total 2222 clock 60.00Hz
Adding tag into "Whiteboard" field - ReadyForDev
*Status is correct
*Platform is included
*Feature is included
*Priority and Severity correctly set
I just tried to reproduce the problem with following configuration:
KBL NUC, using mini-DP to DP and HDMI - HDMI with 2 external monitor (acer) 3840 x 2160.
Attaching my configuration used to test
kernel version : 4.12.0-rc3-drm-tip-ww22-commit-187376e+
architecture : x86_64
os version : Ubuntu 17.04
os codename : zesty
kernel driver : i915
bios revision : 5.12
bios release date : 09/12/2016
mesa : 17.0.3
modesetting : modesetting_drv.so
xorg-xserver : 1.19.3
libdrm : 2.4.76
libva : 1.7.3-2
vaapi (intel-driver) : 1.7.3
cairo : 1.14.8-1
intel-gpu-tools : 1.17-1
platform : KBL-Nuc
motherboard model : MS-B142
motherboard id : MS-B1421
form factor : Desktop
manufacturer : Micro-StarInternationalCo.,Ltd.
cpu family : Core i7
cpu family id : 6
cpu information : Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz
gpu card : Intel Corporation Device 5916 (rev 02) (prog-if 00 [VGA controller])
memory ram : 7.65 GB
max memory ram : 64 GB
display resolution : 1600x900
cpu thread : 4
cpu core : 2
cpu model : 142
cpu stepping : 9
socket : Other
signature : Type 0, Family 6, Model 142, Stepping 9
hard drive : 111GiB (120GB)
current cd clock frequency : 540000 kHz
maximum cd clock frequency : 675000 kHz
displays connected : DP-1 HDMI-A-2
dmc fw loaded : yes
dmc version : 1.1
guc fw loaded : NONE
guc version wanted : 0.0
guc version found : 0.0
quiet splash fastboot drm.debug=0xe
I tried to reproduce this issue but i was unable to get it.
Actually this configuration works for me.
Can I convince you to test this with a Samsung monitor? The people over at NVIDIA had a very similar problem: https://devtalk.nvidia.com/default/topic/968059/dpms-not-working-with-displayport-monitor/
In particular, I'm not convinced that:
- Different processor line (KBL vs SKL)
- Different motherboard
- Different monitor
counts as "this configuration."
I could bring it into work, where I am 40% funded by Intel and work closely with the pathfinding group and Altera, but they're probably not the right people to debug graphics drivers.
Thanks for your patient. Could you please try to reproduce with latest drm-tip or vanilla mainline: https://cgit.freedesktop.org/drm-tip, https://www.kernel.org/.
From 4.12 and up, some DP patches that may help with this problem were added.
Experiment 1. Send the monitor in to Samsung for repair. Result: came back with longer pauses between turning on and off but still has the same fundamental problem.
Experiment 2. Connect returned monitor to Dell XPS 113 9360 (Kaby Lake) via type-C to DisplayPort. Result: works correctly.
Experiment 3. Vanilla 4.14.13 from kernel.org with Gigabyte Z170X-Gaming G7 revision 1.0. Still has the alternating issue when connected to DisplayPort from the motherboard or a type-C to DisplayPort adapter.
Experiment 4. Buy a type-C to HDMI 2.0 cable and connect it to the monitor's HDMI input. Power management works. xrandr identifies the monitor as DP-2.
So in the end DPMS via DisplayPort is still broken with this Samsung monitor. But I have a configuration that works (type-C to HDMI cable).
I suspect my Gigabyte Z170X-Gaming 7 rev 1.0 motherboard is slightly broken. Additional evidence from this is that the HDMI output directly from the motherboard blanks on random occasions. Which is why I started trying to use DisplayPort in the first place.
First of all. Sorry about spam.
This is mass update for our bugs.
Sorry if you feel this annoying but with this trying to understand if bug still valid or not.
If bug investigation still in progress, please ignore this and I apologize!
If you think this is not anymore valid, please comment to the bug that can be closed.
If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Seems like not driver issue?
Closing, please re-open if still occurs or seeing closed wrongly.