Bug 39683 - radeon "hd6770 flex" dpms fails to unblank one display sometimes
Summary: radeon "hd6770 flex" dpms fails to unblank one display sometimes
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
Depends on:
Reported: 2011-07-30 02:33 UTC by aaron
Modified: 2011-08-18 01:52 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

dmesg output (38.65 KB, text/plain)
2011-08-04 22:15 UTC, aaron
no flags Details
xorg.0.log (90.86 KB, text/plain)
2011-08-04 22:18 UTC, aaron
no flags Details

Description aaron 2011-07-30 02:33:16 UTC
when "dpms off" is triggered ( by timeout, xset ) both displays turn off but only one display turns back on, if i do `xset dpms force off` after then both displays turn back on as expected

the standby and suspend states also seem to behave in the same way but i only briefly checked

there seems to also be some timing factor as the second time seems to need to be triggered soon after the first for both displays to turn back on

the display affected is labeled as"DisplayPort-1" but is infact a dvi plug (note this a "flex" model, allowing 3 dvi displays out of the box so it may be a bit different to a standard one ...dunno)

the only interesting thing i could find in the logs:
[drm:radeon_dp_get_link_status] *ERROR* displayport link status failed
[drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed
(once - part way through the repeats of the following message)
[drm] force priority to high 
(repeated - about the amount i would expect if it was repeated once per failed attempt)
Comment 1 aaron 2011-07-30 04:37:05 UTC
so... my testing missed something stupid

the display that i assumed to be behaving correctly may be were the actual issue is - after the first "dpms off" both turn off as expected but the one that i assumed to be turning on correctly ( due to my lack of Patience...) seems to turn on without any input from my part almost immediately after turning off - the second (soon after) time all works correctly

... and reading my original bug report it almost sound like thats what i said :/
Comment 2 Alex Deucher 2011-07-30 11:09:21 UTC
When testing dpms, try something like this:
sleep 5; xset dpms force off
so that you avoid any late input events that might come in after turning that displays off that might make then come back.  Please also attach your xorg log and dmesg output.
Comment 3 aaron 2011-08-04 22:15:04 UTC
Created attachment 49937 [details]
dmesg output
Comment 4 aaron 2011-08-04 22:16:20 UTC
re-tested via ssh to to eliminate delayed events (and i now have 3 screens...)

xset dpms force off:
all displays turn off

then almost immediately DVI-0 and HDMI-0 turn back on but DisplayPort-1 stays off
xset q states "monitor is off"

then i press shift( cause an event):
xset q states "monitor is on"
DVI-0 and HDMI-0 stay on and DisplayPort-1 stays off

then "xset dpms force off" again
all 3 displays turn off
xset q states "monitor is off"

then i press shift( cause an event):
all 3 displays turn on
xset q states "monitor is on"

this is a repeatable loop
Comment 5 aaron 2011-08-04 22:18:44 UTC
Created attachment 49938 [details]
Comment 6 Alex Deucher 2011-08-05 06:35:04 UTC
Do the DVI/HDMI monitors have an option to probe all inputs at some regular interval?  If so, can you turn that off and see if it helps?
Comment 7 aaron 2011-08-06 03:45:40 UTC
i checked the settings and found nothing, so i decided to switch the displays around to see what happens...
original layout (1):
dvi -> 1
hdmi -> 2
dp -> 3

layout 2:
dvi -> 2
hdmi -> 1
dp -> 3
ran xset dpms force off via ssh
all 3 turned back on but "3" was distinctly after 1,2
(under setup 1 they all turn back on at about the same time the second time round)
xset -q says displays off
same result every time

layout 3:
dvi -> 3
hdmi -> 2
dp -> 1
same result as layout 1 but it starts  at a different point in the loop - xrandr says display on but display 3 is off immediately after starting X

it may have something to do with a race condition relating to the speeds the dislays "start" ( i probably have no idea what i am talking about...) as when setting up xorg.conf if i used "right-of" it complained about missing modes or something - it only worked as i expected it to when "left-of"'d from display 3 will investigate further in the next few days
Comment 8 aaron 2011-08-18 01:52:51 UTC
i updated mesa, ddx, kernel - drm-fixes

the issue is not reproducible in the same way
i am yet to find a consistent way to do it and it happens very rarely under normal use

i do find this error in dmesg odd as there is no "display port" plug in use:

[drm:radeon_dp_get_link_status] *ERROR* displayport link status failed
[drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed

i get that error in dmesg atleast one for every time it happens

unless anyone else experiences this ( or you want me to look into it further )
consider this "resolved enough" :)

thanks, aaron m

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.