Bug 46711

> On a AMD G-T56N (Radeon HD 6310) box connected to the monitor via DisplayPort 
> monitor does not come on after re-plugging the display cable but claims to be 
> in power save.
> 
> At the same time, according to xrandr it is connected and displaying.

Please attach the xrandr output from when the monitor is in power save after re-plugging.

# xrandr 
Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 8192 x 8192
DisplayPort-0 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 519mm x 320mm
   1920x1200      60.0*+
   1600x1200      60.0  
   1280x1024      60.0  
   NTB-vesa_cvt-1360x768   59.8  
   1024x768       60.0  
   800x600        60.3  
   Fallback       60.0  
   640x480        60.0  
DVI-0 disconnected (normal left inverted right x axis y axis)
VGA-0 disconnected (normal left inverted right x axis y axis)

Monitor is Dell 2408WFP in case it matters.

I'm seeing the same thing.  Na display after either replug/hotplug, front-panel soft-off power cycling, or back-panel power supply power cycling.

xorg-x11-server-Xorg-1.11.4-1.fc16.x86_64
xorg-x11-drv-ati-6.14.3-4.20120201git36c190671.fc16.x86_64

Samsung s27a850d displayport monitor
ATI Technologies Inc Cadar [FirePro 2460]   (I think they meant ATI "Cedar")

forcing DPMS off and on will restore display.  (I have this shell script bound to F12 and taping that key will restore the display.)

    xset dpms force off
    sleep 1
    xset dpms force on

(In reply to comment #4)
> forcing DPMS off and on will restore display.  (I have this shell script bound
> to F12 and taping that key will restore the display.)
> 
>     xset dpms force off
>     sleep 1
>     xset dpms force on

Are you getting proper hotplug connect/disconnect interrupts?  The driver does exactly the same thing on hotplug interrupts.  Assuming the display is active, on disconnect it calls dpms off, on connect it calls dpms on.  It also sends an event to userspace so it's possible that may be causing a conflict.  Take a look at radeon_connector_hotplug() in radeon_connectors.c in the kernel.

(In reply to comment #5)
> (In reply to comment #4)
> > forcing DPMS off and on will restore display.  (I have this shell script bound
> > to F12 and taping that key will restore the display.)
> > 
> >     xset dpms force off
> >     sleep 1
> >     xset dpms force on

This works for me as well.

> Are you getting proper hotplug connect/disconnect interrupts?  The driver does
> exactly the same thing on hotplug interrupts.  Assuming the display is active,
> on disconnect it calls dpms off, on connect it calls dpms on.  It also sends an
> event to userspace so it's possible that may be causing a conflict.  Take a
> look at radeon_connector_hotplug() in radeon_connectors.c in the kernel.

I see it calling drm_helper_connector_dpms(connector, DRM_MODE_DPMS_ON) from radeon_connector_hotplug when I plug in the cable, meaning HPD sense said there is something connected.

How to investigate this potential conflict with userspace?

Because, as I originally wrote, without X running monitor comes back fine.

(In reply to comment #6)
> How to investigate this potential conflict with userspace?
> 
> Because, as I originally wrote, without X running monitor comes back fine.

It's probably missing locking in the radeon kernel modesetting code.  The ddx registers an event handler in the xserver and then the desktop environment does something with the event.  See drmmode_uevent_init() and drmmode_handle_uevents() in drmmode_display.c in xf86-video-ati.

(In reply to comment #7)
> (In reply to comment #6)
> > How to investigate this potential conflict with userspace?
> > 
> > Because, as I originally wrote, without X running monitor comes back fine.
> 
> It's probably missing locking in the radeon kernel modesetting code.  The ddx
> registers an event handler in the xserver and then the desktop environment does
> something with the event.  See drmmode_uevent_init() and
> drmmode_handle_uevents() in drmmode_display.c in xf86-video-ati.

Brief look doesn't show me any locks there, I'll dig in.

If relevant, we have the same symptoms with and without a "desktop environment". Meaning same thing happens with pure X, and also with our software running which does explicit output probing when nothing is connected.

Problem is (seems to me) xrandr reports monitor connected when in that state.

Also if relevant we do get two RandR events (RRScreenChangeNotify and RRNotify_OutputChange) when re-plugging the monitor.

Unless there is no intersection between RandR and DPMS... ?

(In reply to comment #8)
> 
> Brief look doesn't show me any locks there, I'll dig in.

The locking (or lack there of) would be on the kernel side.

> 
> If relevant, we have the same symptoms with and without a "desktop
> environment". Meaning same thing happens with pure X, and also with our
> software running which does explicit output probing when nothing is connected.
> 
> Problem is (seems to me) xrandr reports monitor connected when in that state.
> 
> Also if relevant we do get two RandR events (RRScreenChangeNotify and
> RRNotify_OutputChange) when re-plugging the monitor.
> 
> Unless there is no intersection between RandR and DPMS... ?

We don't change the dpms state in the hotplug handler we just use the dpms code paths to properly tear down and bring up the display when an enabled monitor is connected or disconnected.

Unfortunately it's been a while since I looked at this so I don't remember how events are handled once X gets them.

(In reply to comment #9)
> (In reply to comment #8)
> > 
> > Brief look doesn't show me any locks there, I'll dig in.
> 
> The locking (or lack there of) would be on the kernel side.
> 
> > 
> > If relevant, we have the same symptoms with and without a "desktop
> > environment". Meaning same thing happens with pure X, and also with our
> > software running which does explicit output probing when nothing is connected.
> > 
> > Problem is (seems to me) xrandr reports monitor connected when in that state.
> > 
> > Also if relevant we do get two RandR events (RRScreenChangeNotify and
> > RRNotify_OutputChange) when re-plugging the monitor.
> > 
> > Unless there is no intersection between RandR and DPMS... ?
> 
> We don't change the dpms state in the hotplug handler we just use the dpms code
> paths to properly tear down and bring up the display when an enabled monitor is
> connected or disconnected.

Isn't that the problem? You are referring to radeon_connector_hotplug where it puts old dpms state into the connector.

On disconnect DPMS gets set to off, and then connector->dpms restored to ON.

Subsequent hotplug then doesn't bring up the display becausedrm_helper_connector_dpms bails out early due to current mode and target mode being the same.

Manually calling xset dpms force off and then on works because "off" this time really sets connector->dpms to OFF which allows following "on" command to do all things it needs to turn it on.

So my question is why this saved_state business in radeon_connector_hotplug?

Created attachment 60177 [details] [review]
possible fix

(In reply to comment #10)
> 
> So my question is why this saved_state business in radeon_connector_hotplug?

We don't want to change the DPMS state or the logic won't work for hotplug.  If this is the first time the monitor is plugged in, there is no mode set so we don't want to turn the display on as it won't work, we just want to send the event to userspace.  If the user has configured the display already and then replugs it or powers it off manually, then we want to power it back up in the hotplug handler as that is what they expect.

Created attachment 60178 [details]
Log showing non-working and working events

Better in terms of what gets called but unfortunately still a black screen without xset dance. Attached are two logs in one file. First sections is debug from plugging in the monitor only. Second sections is after xset dpms force off and on (but only the "on" bit). Looks like interesting things are happening in both cases, but only second one results with video output.

Run through ssh "udevadm monitor" when pluging/unpluging screen you should see event there. If you don't it's kernel issue, if you do it might be your ddx was not build with the uevent code enabled (which would be a distribution issue). You can try building your ddx yourself and make sure you have libudev-devel

(In reply to comment #13)
> Run through ssh "udevadm monitor" when pluging/unpluging screen you should see
> event there. If you don't it's kernel issue, if you do it might be your ddx was
> not build with the uevent code enabled (which would be a distribution issue).
> You can try building your ddx yourself and make sure you have libudev-devel

That is not the problem because I see X RandR events on plug events (DDX built with libudev support) and this is only a problem on DisplayPort.

In fact, with the patch monitor is no longer in power save mode after cable re-plug (whereas without the patch it would be), but in some strange state where the screen is black and it seems to be thoroughly confused to the extend it can't even show the OSD. At this point if I run "xset dpms force off" I properly goes into powersave and OSD works again.

I suspect DP initialization done from radeon_connector_hotplug is somehow incomplete or buggy.

Created attachment 60250 [details] [review]
possible fix

Does this patch work any better?

Still leaves the monitor in that weird state (black screen but not powersave, can't get to OSD menu) after re-plug.

"xset dpms force off" can put it into proper power save.

"xset dpms force on" then makes it work.

Is this still an issue with a newer kernel?

(In reply to comment #18)
> Is this still an issue with a newer kernel?

I haven't seen this problem in years.  The bug went away with a newer gnome desktop.  I assume there was a way for a user app to take responsibility for the power save state and also to drop the ball.

Created attachment 111880 [details]
Logs from a reproduction of the bug using recent software

I'm seeing the same issue with Xorg 1.16.2.901, Linux 3.16.0, and a Radeon HD 7750.  I've attached DRM logs that contrast the behavior when the monitor is power-cycled in X (there's no signal when the monitor is powered back on) to the behavior when the monitor is power-cycled in kernel framebuffer VT (the signal returns when the monitor is powered back on), but am not sure what to make of them.

Thanks!

After some digging, the only differences I've been able to find between the re-plug behavior under X (where the encoder sends no signal although the driver thinks DPMS is ON), and the re-plug behavior under an fbdev (where the signal returns after re-plug, as expected) are the following:

  1. When the monitor is re-plugged and radeon_connector_hotplug is called, connector->dpms is OFF in the fbdev case, but it's ON in the X case.  This means that radeon_connector_hotplug returns immediately when the monitor is re-plugged under fbdev, and that the code in radeon_connector_hotplug is not what's turning the encoder back on.

  2. In the fbdev case, there are redundant calls to radeon_atom_encoder_dpms.  When unplugging, it's called six times with on=false, and when re-plugging, it's called thrice, with on=false, on=true, and on=true.  In the X case, it's called only once per unplug/re-plug, with on=false and on=true, respectively.

  3. In the fbdev case, drm_crtc_helper_set_config is called on re-plug, and it calls some other functions, including radeon_encoder_set_active_device and drm_crtc_helper_set_mode.  (I realize that this may be a red herring, but figure I should include it so that expert eyes may judge.)  drm_crtc_helper_set_config isn't called at all in the X case.

  4. Forcing DPMS off with xset results in one call to radeon_atom_encoder_dpms.  Forcing DPMS on with xset results in one call to radeon_atom_encoder_dpms and one (I think?) call to drm_crtc_helper_set_config.

(I'm not counting calls to encoders and connectors not connected to my monitor, even though fbdev likes to traverse them all anytime something changes.)

It seems that drm_crtc_helper_set_config is doing something with the encoder that radeon_connector_hotplug is not doing.  This is my first time digging into video code, so I have no idea what that might be.  I'm going to take a break from working on this for now, but will come back to it if no one else beats me to it.  :)

I have the problem each time I turn off my monitor and then later turn it back on. The desktop does not come back.

(In reply to Wolfgang Rupprecht from comment #4)
>     xset dpms force off
>     sleep 1
>     xset dpms force on

This also gets the display back for me.

The monitor is a Samsung U24E850 (24 inch, 3840x2160)

The OS is Ubuntu 15.04 with 4.1.1 kernel installed and olibaf xork packages.

here is the relevant package information:

linux-image-4.1.1-040101-generic              4.1.1-040101.201506291635
xserver-xorg-video-radeon                     1:7.5.99+git1507100730.b6d871~gd~v
xserver-xorg-core                             2:1.17.1-0ubuntu3

# xrandr 
Screen 0: minimum 320 x 200, current 3840 x 2160, maximum 16384 x 16384
DisplayPort-0 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 521mm x 293mm
   3840x2160      60.0*+
   2560x1440      60.0  
   1920x1080      60.0     59.9  
   1680x1050      60.0  
   1600x900       59.9  
   1280x1024      60.0  
   1440x900       59.9  
   1280x800       59.8  
   1280x720       59.9  
   1024x768       60.0  
   800x600        60.3     56.2  
   640x480        60.0     59.9  
HDMI-0 disconnected (normal left inverted right x axis y axis)
DVI-0 disconnected (normal left inverted right x axis y axis)
DVI-1 disconnected (normal left inverted right x axis y axis)

I am also seeing this problem on Debian Sid with a new Radeon R9 390 card and two Samsung monitors connected with DisplayPort. The third monitor on DVI works just fine.

Here's the card:

  06:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Hawaii PRO [Radeon R9 290] (rev 80)

  Kernel is version 4.4.0 (amd64)
  X.org is version 7.7
  Radeon driver is version 7.6.1

Restarting X.org does *not* turn the monitors/displays on. They are in a really weird state: not flashing as to indicate power-saving, but completely blank/dark, and I can't even call up the OSD menu.

The only way to get these displays to work is to disconnect the DP cable, turn them off and on, and then connect the DP cable again.

Here is abridged xrandr output:

Screen 0: minimum 320 x 200, current 5888 x 1152, maximum 16384 x 16384
DisplayPort-0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 477mm x 268mm
   1920x1080     60.00*+  59.94  
   […]
DisplayPort-1 connected 1920x1080+3968+0 (normal left inverted right x axis y axis) 477mm x 268mm
   1920x1080     60.00*+  59.94  
   […]
DisplayPort-2 disconnected (normal left inverted right x axis y axis)
HDMI-0 disconnected (normal left inverted right x axis y axis)
DVI-0 connected primary 2048x1152+1920+0 (normal left inverted right x axis y axis) 510mm x 287mm
   1920x1080     60.00 +  50.00    59.94  
   2048x1152     59.91*+
   […]

I have the problem each time I turn off my monitor and then later turn it back on. The desktop does not come back.

The monitor is a samsung Samsung S34J55W.

# xrandr
Screen 0: minimum 320 x 200, current 3440 x 1440, maximum 16384 x 16384
DisplayPort-0 connected primary 3440x1440+0+0 (normal left inverted right x axis y axis) 797mm x 333mm
   3440x1440     59.97*+  74.98  
   2560x1440     59.95  
   2560x1080     60.00    59.94  
   1920x1080     60.00    50.00    59.94  
   1680x1050     59.95  
   1600x900      60.00  
   1280x1024     75.02    60.02  
   1440x900      59.89  
   1280x800      59.81  
   1152x864      75.00  
   1280x720      60.00    50.00    59.94  
   1024x768      75.03    70.07    60.00  
   832x624       74.55  
   800x600       72.19    75.00    60.32    56.25  
   720x576       50.00  
   720x480       60.00    59.94  
   640x480       75.00    72.81    66.67    60.00    59.94  
   720x400       70.08  
DisplayPort-1 disconnected (normal left inverted right x axis y axis)
HDMI-0 disconnected (normal left inverted right x axis y axis)
DVI-0 disconnected (normal left inverted right x axis y axis)

# inxi -Fx
System:    Host: luca-pc Kernel: 4.19.16-1-MANJARO x86_64 bits: 64 compiler: gcc v: 8.2.1 Desktop: KDE Plasma 5.14.5 
           Distro: Manjaro Linux 
Machine:   Type: Desktop Mobo: ASRock model: Z370 Extreme4 serial: <filter> UEFI: American Megatrends v: P1.80 
           date: 03/20/2018 
CPU:       Topology: 6-Core model: Intel Core i7-8700K bits: 64 type: MT MCP arch: Kaby Lake rev: A L2 cache: 12.0 MiB 
           flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 88728 
           Speed: 800 MHz min/max: 800/4700 MHz Core speeds (MHz): 1: 799 2: 800 3: 800 4: 800 5: 801 6: 800 7: 801 8: 800 
           9: 800 10: 800 11: 800 12: 800 
Graphics:  Device-1: Advanced Micro Devices [AMD/ATI] Pitcairn XT [Radeon HD 7870 GHz Edition] vendor: Gigabyte driver: radeon 
           v: kernel bus ID: 01:00.0 
           Display: x11 server: X.Org 1.20.3 driver: ati,radeon unloaded: modesetting resolution: 3440x1440~60Hz 
           OpenGL: renderer: AMD PITCAIRN (DRM 2.50.0 4.19.16-1-MANJARO LLVM 7.0.1) v: 4.5 Mesa 18.3.2 direct render: Yes 
Audio:     Device-1: Intel 200 Series PCH HD Audio vendor: ASRock driver: snd_hda_intel v: kernel bus ID: 00:1f.3 
           Device-2: AMD Cape Verde/Pitcairn HDMI Audio [Radeon HD 7700/7800 Series] vendor: Gigabyte driver: snd_hda_intel 
           v: kernel bus ID: 01:00.1 
           Device-3: Logitech Webcam C210 type: USB driver: snd-usb-audio,uvcvideo bus ID: 1-8:3 
           Sound Server: ALSA v: k4.19.16-1-MANJARO 
Network:   Device-1: Intel Ethernet I219-V vendor: ASRock driver: e1000e v: 3.2.6-k port: f000 bus ID: 00:1f.6 
           IF: enp0s31f6 state: up speed: 100 Mbps duplex: half mac: <filter> 
Drives:    Local Storage: total: 1.14 TiB used: 408.99 GiB (35.1%) 
           ID-1: /dev/nvme0n1 vendor: Samsung model: SSD 960 EVO 250GB size: 232.89 GiB 
           ID-2: /dev/nvme1n1 vendor: Samsung model: SSD 960 EVO 500GB size: 465.76 GiB 
           ID-3: /dev/sda vendor: Samsung model: HD103SJ size: 931.51 GiB 
Partition: ID-1: / size: 193.99 GiB used: 85.41 GiB (44.0%) fs: ext4 dev: /dev/nvme0n1p2 
           ID-2: swap-1 size: 34.49 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/nvme0n1p3 
Sensors:   System Temperatures: cpu: 30.0 C mobo: 30.0 C gpu: radeon temp: 37 C 
           Fan Speeds (RPM): fan-1: 580 fan-2: 825 fan-3: 0 fan-4: 562 fan-5: 577 
           Voltages: 12v: N/A 5v: N/A 3.3v: 3.28 vbat: 3.18 
Info:      Processes: 259 Uptime: 26m Memory: 31.35 GiB used: 2.24 GiB (7.1%) Init: systemd Compilers: gcc: 8.2.1 clang: 7.0.1 
           Shell: fish v: 3.0.0 inxi: 3.0.30

Same problem here.

I'm using latest Linux Kernel (5.0.7) on Arch Linux, with Nvidia drivers 418.56-7, Xorg 1.20.4.

Hardware:
- GPU: NVIDIA GK106 [GeForce GTX 660]
- Mobo: Asus Z87-PRO
- Display: 2x Acer BE270U (DP with daisy chain), 1x DELL 2209WA (DVI)

The xrandr output is:

Screen 0: minimum 8 x 8, current 6170 x 1680, maximum 16384 x 16384
DVI-I-0 disconnected primary (normal left inverted right x axis y axis)
DP-1.8 connected 2560x1440+1050+0 (normal left inverted right x axis y axis) 597mm x 336mm
   2560x1440     74.92*+  59.95  
   1920x1080     60.00    59.94    50.00  
   1680x1050     59.95  
   1440x900      59.89  
   1280x1024     75.02    60.02  
   1280x960      60.00  
   1280x720      60.00    59.94    50.00  
   1024x768      75.03    70.07    60.00  
   800x600       75.00    72.19    60.32    56.25  
   720x576       50.00  
   720x480       59.94  
   640x480       75.00    72.81    59.94    59.93  
DP-1.1.8 connected 2560x1440+3610+0 (normal left inverted right x axis y axis) 597mm x 336mm
   2560x1440     74.92*+  59.95  
   1920x1080     60.00    59.94    50.00  
   1680x1050     59.95  
   1440x900      59.89  
   1280x1024     75.02    60.02  
   1280x960      60.00  
   1280x720      60.00    59.94    50.00  
   1024x768      75.03    70.07    60.00  
   800x600       75.00    72.19    60.32    56.25  
   720x576       50.00  
   720x480       59.94  
   640x480       75.00    72.81    59.94    59.93  
DVI-I-1 connected 1050x1680+0+0 left (normal left inverted right x axis y axis) 474mm x 296mm
   1680x1050     59.95*+
   1280x1024     75.02    60.02  
   1152x864      75.00  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   640x480       75.00    59.94  
HDMI-0 disconnected (normal left inverted right x axis y axis)
DP-0 disconnected (normal left inverted right x axis y axis)
DVI-D-0 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)

-- 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/251.