Bug 46711 - Monitor not turning on after DisplayPort re-plug in Xorg
Summary: Monitor not turning on after DisplayPort re-plug in Xorg
Status: NEW
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-28 02:22 UTC by Tvrtko Ursulin
Modified: 2016-03-24 10:41 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Kernel DRM debug log showing successful replug without, and failing with Xorg running. (394.67 KB, application/x-bzip2)
2012-02-28 02:22 UTC, Tvrtko Ursulin
no flags Details
possible fix (1.73 KB, patch)
2012-04-17 08:45 UTC, Alex Deucher
no flags Details | Splinter Review
Log showing non-working and working events (47.52 KB, text/x-log)
2012-04-17 09:09 UTC, Tvrtko Ursulin
no flags Details
possible fix (1.90 KB, patch)
2012-04-18 07:07 UTC, Alex Deucher
no flags Details | Splinter Review
Logs from a reproduction of the bug using recent software (31.05 KB, application/octet-stream)
2015-01-07 01:40 UTC, Branen Salmon
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tvrtko Ursulin 2012-02-28 02:22:57 UTC
Created attachment 57747 [details]
Kernel DRM debug log showing successful replug without, and failing with Xorg running.

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.

Stopping Xorg and monitor comes back up displaying the console.

Re-pluging the display cable with no Xorg running is fine.

Attached kernel DRM debug log. Log itself which ends after cable re-plug when Xorg is running. Which is when the display goes into power save. Before that in the same log you can find Xorg starting up and before that a successful cable re-
plug when X was not running.

All this is with kernel.org 3.3.0-rc4 kernel. Xorg packages are:

xorg-x11-server-Xorg-1.11.3-1.fc16.x86_64
xorg-x11-drv-ati-6.14.3-8.20120209gite20284409.fc16.x86_64
Comment 1 Michel Dänzer 2012-02-28 03:58:57 UTC
> 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.
Comment 2 Tvrtko Ursulin 2012-02-28 04:10:53 UTC
# 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)
Comment 3 Tvrtko Ursulin 2012-02-28 07:59:46 UTC
Monitor is Dell 2408WFP in case it matters.
Comment 4 Wolfgang Rupprecht 2012-04-13 14:48:22 UTC
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
Comment 5 Alex Deucher 2012-04-13 15:28:25 UTC
(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.
Comment 6 Tvrtko Ursulin 2012-04-16 08:00:52 UTC
(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.
Comment 7 Alex Deucher 2012-04-16 08:25:12 UTC
(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.
Comment 8 Tvrtko Ursulin 2012-04-16 08:54:47 UTC
(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... ?
Comment 9 Alex Deucher 2012-04-16 09:07:59 UTC
(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.
Comment 10 Tvrtko Ursulin 2012-04-17 08:23:56 UTC
(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?
Comment 11 Alex Deucher 2012-04-17 08:45:04 UTC
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.
Comment 12 Tvrtko Ursulin 2012-04-17 09:09:15 UTC
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.
Comment 13 Jerome Glisse 2012-04-17 09:37:38 UTC
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
Comment 14 Tvrtko Ursulin 2012-04-18 00:59:41 UTC
(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.
Comment 15 Tvrtko Ursulin 2012-04-18 01:16:19 UTC
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.
Comment 16 Alex Deucher 2012-04-18 07:07:25 UTC
Created attachment 60250 [details] [review]
possible fix

Does this patch work any better?
Comment 17 Tvrtko Ursulin 2012-04-20 03:07:55 UTC
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.
Comment 18 Alex Deucher 2014-04-09 18:05:55 UTC
Is this still an issue with a newer kernel?
Comment 19 Wolfgang Rupprecht 2014-04-09 22:05:04 UTC
(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.
Comment 20 Branen Salmon 2015-01-07 01:40:40 UTC
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!
Comment 21 Branen Salmon 2015-01-11 02:29:02 UTC
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.  :)
Comment 22 Marcus 2015-07-20 21:41:10 UTC
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)
Comment 23 martin f. krafft 2016-03-24 10:41:02 UTC
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*+
   […]


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.