My card is Radeon HD5850. The result might varies between different boot. Either the screens would not be detected at all or they seem to be detected with a non-optimal resolution (in console, while gdm shows a broken screen) If a monitor is connected before boot, others can get detected correctly afterwards. If only one monitor is connected, turning it off can make the signal lost. Reboot or suspend/resume (after turning it on again) can bring the signal back. (Yet dpms would cause no problem at all) The only way to reproduce the problem if DVI is involved is to disconnect it physically, otherwise only powering off the monitor is required. My guess is DVI detects display with a different mechanism.
The card has 4 connectors: 1 HDMI, 1 DisplayPort and 2 DVI
Please attach your xorg log and dmesg output in the working and non-working cases.
Created attachment 127881 [details] dmesg (monitor off when boot, not work when turn on afterwards)
Created attachment 127891 [details] dmesg (monitor on when boot, working before off)
Created attachment 127901 [details] dmesg (monitor on when boot, turn off afterwards) `diff on_at_start off_afterwards` 858a859 > [ 49.713776] pci_pm_runtime_suspend(): > radeon_pmops_runtime_suspend+0x0/0xa0 [radeon] returns -22
Created attachment 127911 [details] Xorg.0.log Maybe it's because I have some misconcept about xorg log, it doesn't seem to vary between cases. Anyway this issue doesn't seem to be related to X a lot.
All the above outputs were captured when only DisplayPort is connected. Similar sympton were observed with HDMI. Also, sometimes toggling others connectors afterwards makes it work again. Like if HDMI is plugged in and out after DisplayPort/DVI is gone, all displays work again. And the two DVI seems to "interact" with HDMI and DisplayPort differently. But those cases are inconsistent, so I can't describe in details or capture logs.
By "with HDMI" I mean only HDMI is connected.
Created attachment 127921 [details] xorg log when not working Sorry I was doing stupid thing. Here is the xorg log captured after I turn the monitor off and on and `systemctl restart gdm`
Switching modes with xrandr can also bring back display.
One of my other machines with an HD6450 shows similar issue. I unplugged the DVI connector before boot up and I can't get any display when I connect it again afterwards.
Does booting with radeon.runpm=0 on the kernel command line in grub help?
Unfortunately, no. Yet it seems that now (with kernel 3.13.6) disconnecting HDMI and DVI doesn't shows a problem anymore. Only DisplayPort still got issue. (Though, if I don't have anything connected before boot, none of them would work afterwards)
The problem with DisplayPort seems to related to DPMS. All I need to do to get back the display is to make sure that there is a state change after the monitor is turned on again.
(In reply to Tom Yan from comment #14) > The problem with DisplayPort seems to related to DPMS. All I need to do to > get back the display is to make sure that there is a state change after the > monitor is turned on again. Just find that this part is a duplicate of this: https://bugs.freedesktop.org/show_bug.cgi?id=46711
I tried to remove the DisplayPort-specific code in radeon_connector_hotplug() of radeon_connector.c and everything seems to work like a charm. What is the code supposed to do actually? Though, btw, it seems that only turning off my DP monitor in X would make it "dead". Doing that in console (or switch to console before turning it on) does not. I am with kernel 3.13.8 now.
One thing to add, unplugging it physically in X still makes it blank. It happens no matter the code is removed or not. Also, HDMI doesn't work all time yet, seems that if the TV is powered off and it goes into DPMS after sometime (in console), the display still gone completely.
(In reply to Tom Yan from comment #16) > I tried to remove the DisplayPort-specific code in > radeon_connector_hotplug() of radeon_connector.c and everything seems to > work like a charm. What is the code supposed to do actually? > It's required to re-establish the DP link if you physically disconnect and reconnect an active display since DP requires link training while other digital links do not, otherwise you'd end up with a blank display after disconnecting and reconnecting a DP display. It sounds like may have a problem with the hpd interrupts on your board. > Though, btw, it seems that only turning off my DP monitor in X would make it > "dead". Doing that in console (or switch to console before turning it on) > does not. > How are you turning it off in X vs console? Are you physically powering the monitor off or triggering dpms (e.g., xset dpms force off)? (In reply to Tom Yan from comment #17) > One thing to add, unplugging it physically in X still makes it blank. It > happens no matter the code is removed or not. That code is required to re-establish the link. > > Also, HDMI doesn't work all time yet, seems that if the TV is powered off > and it goes into DPMS after sometime (in console), the display still gone > completely. Are you physically powering off the TV or do you mean dpms?
(In reply to Alex Deucher from comment #18) > It's required to re-establish the DP link if you physically disconnect and > reconnect an active display since DP requires link training while other > digital links do not, otherwise you'd end up with a blank display after > disconnecting and reconnecting a DP display. It sounds like may have a > problem with the hpd interrupts on your board. Unfortunately it doesn't work as intended but only cause some side effect, at least for my case. FYR my board is Sapphire HD5850 Toxic, and my monitor is EIZO EV2336W. > How are you turning it off in X vs console? Are you physically powering the > monitor off or triggering dpms (e.g., xset dpms force off)? All "turning it off" mean physically powering it off. I even tried unplugging the power today. > Are you physically powering off the TV or do you mean dpms? In the case that I found out the problem, I was nuking a disk in console, so I physically powered off the TV after I ran the command. When I turn on my TV again after a long time, I can't get back the display.
I did some more tests. Seems to me that the blank occured with dis/reconnection in X is also related to DPMS toggling. Any similar code in ddx driver I can try removing? Since in console everything is fine so far :P
(In reply to Tom Yan from comment #20) > I did some more tests. Seems to me that the blank occured with > dis/reconnection in X is also related to DPMS toggling. Any similar code in > ddx driver I can try removing? Since in console everything is fine so far :P With KMS, the kernel controls all modesetting. All the ddx does is call down into the kernel. There's no difference between the kernel and the ddx, it's all calling the same code.
Do you have any case that the code would do something positive? Or ultimately, would you consider removing the code upstream?
Btw, is it something not implemented yet or a bug, that it won't do the modesetting later if no device plugged before boot? Why does it have to go 1024x768? I mean, why does it require a device to initialize "dynamic" modesetting?
(In reply to Tom Yan from comment #22) > Do you have any case that the code would do something positive? Or > ultimately, would you consider removing the code upstream? It works for the vast majority of users and removing it would break unplug and replug of DP displays. Without that code you would have to manually disable and re-enable the display using xrandr every time you connect or disconnect a DP display. It would also break disconnect and reconnect of dp displays for the console. In your case we need to find out why it's not working properly for you. You mentioned that it works properly in the console but not in X. That sounds like maybe your desktop environment is trying to do something special which causes the problem. Does it work properly with a bare X server? E.g., just run Xorg without a desktop environment.
(In reply to Tom Yan from comment #23) > Btw, is it something not implemented yet or a bug, that it won't do the > modesetting later if no device plugged before boot? Why does it have to go > 1024x768? I mean, why does it require a device to initialize "dynamic" > modesetting? It's a bug that seems to be specific to your board. The vast majority of cards work fine (i.e., you can dynamically change monitors on the fly).
(In reply to Alex Deucher from comment #24) > It works for the vast majority of users and removing it would break unplug > and replug of DP displays. Without that code you would have to manually > disable and re-enable the display using xrandr every time you connect or > disconnect a DP display. It would also break disconnect and reconnect of dp > displays for the console. In my case removing it breaks nothing. So there's a chance my board has a non-standard dp? > In your case we need to find out why it's not working properly for you. You > mentioned that it works properly in the console but not in X. That sounds > like maybe your desktop environment is trying to do something special which > causes the problem. Does it work properly with a bare X server? E.g., just > run Xorg without a desktop environment. Indeed with or without the code it works the same in console. I am with GNOME and I may try a wm with startx later, but I doubt it has anything to do with the problem. Some have same experiences test it already: https://bugs.freedesktop.org/show_bug.cgi?id=46711
(In reply to Alex Deucher from comment #25) > (In reply to Tom Yan from comment #23) > > Btw, is it something not implemented yet or a bug, that it won't do the > > modesetting later if no device plugged before boot? Why does it have to go > > 1024x768? I mean, why does it require a device to initialize "dynamic" > > modesetting? > > It's a bug that seems to be specific to your board. The vast majority of > cards work fine (i.e., you can dynamically change monitors on the fly). I can dynamically change monitors, just that the prequisite is something has to be connected (and turned on unless it's DVI) before boot. I have two different cards sharing the same problem, though they are both from Sapphire. I'll see if I can test one from others.
(In reply to Alex Deucher from comment #24) > In your case we need to find out why it's not working properly for you. You > mentioned that it works properly in the console but not in X. That sounds > like maybe your desktop environment is trying to do something special which > causes the problem. Does it work properly with a bare X server? E.g., just > run Xorg without a desktop environment. I tried running i3 with startx, same thing happens. But I just find that since power off works without the code, I can therefore get back display after the reconnection by pressing the button before or afterwards. I guess I'll be removing the code myself on every update since it's still much more convenient. Is it possible to rebuild this module only?
Created attachment 131821 [details] reverse hpd polarity It sounds like your board by have the hpd pin polarity reversed (so plug events looks like unplug and vice versa). Please attach a copy of your vbios: (as root) (use lspci to get the bus id) cd /sys/bus/pci/devices/<pci bus id> echo 1 > rom cat rom > /tmp/vbios.rom echo 0 > rom Can you also try the attached patch which reverses the hpd polarity?
Created attachment 131971 [details] vbios
(In reply to Alex Deucher from comment #29) > Can you also try the attached patch which reverses the hpd polarity? Unfortunately the patch doesn't work (with or without the dp-specific code). Maybe you should try looking at code that does similar stuff as the dp-specific code. I mean, no matter there is a problem/lacking of code, it must be something that deals with X (or deals with it differently than with console, for whatever reason or whatever's nature).