Bug 104531

Summary: Cannot turn monitor off over DP cable
Product: DRI Reporter: Marcin Deranek <gringo>
Component: DRM/AMDgpuAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED MOVED QA Contact:
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
xorg log file (amdgpu over DP cable)
none
dmesg none

Description Marcin Deranek 2018-01-07 19:44:44 UTC
Created attachment 136602 [details]
xorg log file (amdgpu over DP cable)

NOTE: This is very similar to Bug #38030.

"sleep 5; xset dpms force off" turns my monitor off, then turns it on again when using DP cable although works just fine with HDMI cable (monitor permanently turns off). I have this problem with both radeon and amdgpu drivers.

card: MSI R9 270 GAMING 2G
xf86-video-amdgpu: latest git
xf86-video-ati: 7.10.0
xorg-server: 1.19.6
kernel: 4.14.11
Comment 1 Marcin Deranek 2018-01-07 19:45:15 UTC
Created attachment 136603 [details]
dmesg
Comment 2 Parag 2018-09-21 00:27:42 UTC
This is happening to me with a R7 240 with DP or HDMI cables, with 4 different monitors - Acer, Dell, 2x Lenovo. No errors in dmesg, just that screen refuses to stay off after DPMS standby/off - wakes back up instantly.

Tried on Ubuntu 18.04.1 and OpenSUSE Tumbleweed all the way up to latest 4.9.x kernel with same results.

Any pointers on how to debug this greatly appreciated.
Comment 3 Alex Deucher 2018-09-21 03:59:24 UTC
(In reply to Parag from comment #2)
> This is happening to me with a R7 240 with DP or HDMI cables, with 4
> different monitors - Acer, Dell, 2x Lenovo. No errors in dmesg, just that
> screen refuses to stay off after DPMS standby/off - wakes back up instantly.
> 
> Tried on Ubuntu 18.04.1 and OpenSUSE Tumbleweed all the way up to latest
> 4.9.x kernel with same results.
> 
> Any pointers on how to debug this greatly appreciated.

Are you manually turning off the displays using xset or something like that, or are you seeing this behavior when your desktop environment enters a dpms state?
Comment 4 Marcin Deranek 2018-09-26 21:08:15 UTC
I'm manually turning it off by:

sleep 10; xset dpms force off

My desktop environment (XFCE) nor Xorg server cannot switch it off either.
Comment 5 Michel Dänzer 2018-10-04 16:35:51 UTC
I suspect amdgpu_connector_dp_detect might need similar logic as amdgpu_connector_dvi/vga_detect related to amdgpu_connector->detected_by_load .
Comment 6 Marcin Deranek 2018-10-20 14:12:19 UTC
It looks like this might be chipset/firmware specific.

I had this problem with MSI R9 270 Gaming 2G (https://www.msi.com/Graphics-card/R9-270-GAMING-2G.html) which broke last week (I couldn't power on computer). I replaced it with Sapphire Nitro+ Radeon RX580 8GB GDDR5 (http://www.sapphiretech.com/productdetial.asp?pid=B66182B7-1EA6-42A9-8762-FCCE003B491A&lang=eng) which does not exhibit this behaviour even though the rest of the system is the same: same hardware, same OS.

Now when running:
sleep 5; xset dpms force off

monitor goes permanently into sleep.
Comment 7 Parag 2018-10-21 20:47:46 UTC
(In reply to Alex Deucher from comment #3)
> (In reply to Parag from comment #2)
> > This is happening to me with a R7 240 with DP or HDMI cables, with 4
> > different monitors - Acer, Dell, 2x Lenovo. No errors in dmesg, just that
> > screen refuses to stay off after DPMS standby/off - wakes back up instantly.
> > 
> > Tried on Ubuntu 18.04.1 and OpenSUSE Tumbleweed all the way up to latest
> > 4.9.x kernel with same results.
> > 
> > Any pointers on how to debug this greatly appreciated.
> 
> Are you manually turning off the displays using xset or something like that,
> or are you seeing this behavior when your desktop environment enters a dpms
> state?

Correction : this happens to me on RX560 card - R7 240 was the one that worked fine. It happens with 1xAcer 1x Dell monitor combo as well 2x Lenovo ones - so monitor brand doesn't seem to matter.

5:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Baffin [Radeon RX 460/560D / Pro 450/455/460/555/560] (rev e5)

Also to answer your question it happens when I set it manually using xset dpms force standby for example. But problem also happens when desktop tries to enter dpms state - tried with various distros/GNOME/KDE with same results - the monitor fails to go to sleep. The difference being in the first case the screen turns black for a second or so, monitor power light is still white and then the screen comes back on. 

In the second case I either see grey screen with mouse some times and lock screen in others but I am able to move the mouse and log back in - nothing seems broken in either case other than the fact that both monitors fail to sleep.
Comment 8 Parag 2018-10-21 20:53:29 UTC
(In reply to Marcin Deranek from comment #6)
> It looks like this might be chipset/firmware specific.
> 
> I had this problem with MSI R9 270 Gaming 2G
> (https://www.msi.com/Graphics-card/R9-270-GAMING-2G.html) which broke last
> week (I couldn't power on computer). I replaced it with Sapphire Nitro+
> Radeon RX580 8GB GDDR5
> (http://www.sapphiretech.com/productdetial.asp?pid=B66182B7-1EA6-42A9-8762-
> FCCE003B491A&lang=eng) which does not exhibit this behaviour even though the
> rest of the system is the same: same hardware, same OS.
> 
> Now when running:
> sleep 5; xset dpms force off
> 
> monitor goes permanently into sleep.

Just to add a data point - problem card in my case is a XFX Radeon RX 560.  1xDP 1xHDMI outputs - disconnecting the DP cable from one monitor doesn't help - same issue with single monitor over HDMI.
Comment 9 Martin Peres 2019-11-19 08:28:31 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/290.

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.