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: dmesg: [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)
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 :/
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.
Created attachment 49937 [details] dmesg output
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
Created attachment 49938 [details] xorg.0.log
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?
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
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.