https://bugzilla.kernel.org/show_bug.cgi?id=71461
Bug ID: 71461 Summary: monitor doesn't get detected after boot Product: Drivers Version: 2.5 Kernel Version: 3.13.5 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri@kernel-bugs.osdl.org Reporter: tom.ty89@gmail.com Regression: No
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.
https://bugzilla.kernel.org/show_bug.cgi?id=71461
Tom Yan tom.ty89@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|monitor doesn't get |monitor doesn't get |detected after boot |detected after boot or | |disconnection
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #1 from Tom Yan tom.ty89@gmail.com --- The card has 4 connectors: 1 HDMI, 1 DisplayPort and 2 DVI
https://bugzilla.kernel.org/show_bug.cgi?id=71461
Alex Deucher alexdeucher@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alexdeucher@gmail.com
--- Comment #2 from Alex Deucher alexdeucher@gmail.com --- Please attach your xorg log and dmesg output in the working and non-working cases.
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #3 from Tom Yan tom.ty89@gmail.com --- Created attachment 127881 --> https://bugzilla.kernel.org/attachment.cgi?id=127881&action=edit dmesg (monitor off when boot, not work when turn on afterwards)
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #4 from Tom Yan tom.ty89@gmail.com --- Created attachment 127891 --> https://bugzilla.kernel.org/attachment.cgi?id=127891&action=edit dmesg (monitor on when boot, working before off)
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #5 from Tom Yan tom.ty89@gmail.com --- Created attachment 127901 --> https://bugzilla.kernel.org/attachment.cgi?id=127901&action=edit 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
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #6 from Tom Yan tom.ty89@gmail.com --- Created attachment 127911 --> https://bugzilla.kernel.org/attachment.cgi?id=127911&action=edit 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.
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #7 from Tom Yan tom.ty89@gmail.com --- 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.
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #8 from Tom Yan tom.ty89@gmail.com --- By "with HDMI" I mean only HDMI is connected.
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #9 from Tom Yan tom.ty89@gmail.com --- Created attachment 127921 --> https://bugzilla.kernel.org/attachment.cgi?id=127921&action=edit 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`
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #10 from Tom Yan tom.ty89@gmail.com --- Switching modes with xrandr can also bring back display.
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #11 from Tom Yan tom.ty89@gmail.com --- 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.
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #12 from Alex Deucher alexdeucher@gmail.com --- Does booting with radeon.runpm=0 on the kernel command line in grub help?
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #13 from Tom Yan tom.ty89@gmail.com --- 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)
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #14 from Tom Yan tom.ty89@gmail.com --- 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.
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #15 from Tom Yan tom.ty89@gmail.com --- (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
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #16 from Tom Yan tom.ty89@gmail.com --- 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.
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #17 from Tom Yan tom.ty89@gmail.com --- 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.
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #18 from Alex Deucher alexdeucher@gmail.com --- (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?
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #19 from Tom Yan tom.ty89@gmail.com --- (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.
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #20 from Tom Yan tom.ty89@gmail.com --- 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
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #21 from Alex Deucher alexdeucher@gmail.com --- (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.
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #22 from Tom Yan tom.ty89@gmail.com --- Do you have any case that the code would do something positive? Or ultimately, would you consider removing the code upstream?
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #23 from Tom Yan tom.ty89@gmail.com --- 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?
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #24 from Alex Deucher alexdeucher@gmail.com --- (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.
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #25 from Alex Deucher alexdeucher@gmail.com --- (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).
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #26 from Tom Yan tom.ty89@gmail.com --- (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
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #27 from Tom Yan tom.ty89@gmail.com --- (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.
https://bugzilla.kernel.org/show_bug.cgi?id=71461
Tom Yan tom.ty89@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Kernel Version|3.13.5 |3.13.8
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #28 from Tom Yan tom.ty89@gmail.com --- (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?
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #29 from Alex Deucher alexdeucher@gmail.com --- Created attachment 131821 --> https://bugzilla.kernel.org/attachment.cgi?id=131821&action=edit 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?
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #30 from Tom Yan tom.ty89@gmail.com --- Created attachment 131971 --> https://bugzilla.kernel.org/attachment.cgi?id=131971&action=edit vbios
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #31 from Tom Yan tom.ty89@gmail.com --- (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).
https://bugzilla.kernel.org/show_bug.cgi?id=71461
Tom Yan tom.ty89@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |OBSOLETE
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠bugzilla.kernel.org