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