[Bug 100289] 'flip queue failed in radeon_scanout_flip: Invalid argument' error and small frame buffer allocated on turning off and on new monitor
https://bugs.freedesktop.org/show_bug.cgi?id=100289
Bug ID: 100289 Summary: 'flip queue failed in radeon_scanout_flip: Invalid argument' error and small frame buffer allocated on turning off and on new monitor Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel@lists.freedesktop.org Reporter: OmegaPhil@startmail.com
Created attachment 130326 --> https://bugs.freedesktop.org/attachment.cgi?id=130326&action=edit Xorg log
I have just bought a 3rd monitor, successfully hooked up via Display Port to the R9 290X (Tahiti XT) card and configured fine as 3 non-mirrored outputs in XFCE4.
I found that when I turned it off for ~10 seconds or more, after turning it back on all screens would go black and appear to reinialise. XFCE4 gets confused and clones the primary monitor output to the new 3rd screen, fiddling in the XFCE4 Display program fixes this (after the problem happens it seems to put the primary and new monitor on top of each other...).
Looking into Xorg.0.log, when I turn the monitor off for less than 10 seconds, I just get the following event:
===============================================================================
[ 512.737] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid argument
===============================================================================
Being off for 10 seconds or more results in:
===============================================================================
[ 1891.671] (II) RADEON(0): Allocate new frame buffer 3840x1200 stride 3840 [ 1891.677] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Device or resource busy [ 1891.678] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Device or resource busy
===============================================================================
It now makes sense why monitor output appears to be mirrored (only 2 unique outputs) - 3840 is 1920*2. When I fix the configuration with XFCE4, the correct frame buffer is set up:
===============================================================================
[ 2001.120] (II) RADEON(0): Allocate new frame buffer 5760x1200 stride 5760
===============================================================================
I have attached the X log.
I'm currently running Devuan Testing (based off Debian Testing) uname -a: Linux omega1 4.9.0-2-amd64 #1 SMP Debian 4.9.13-1 (2017-02-27) x86_64 GNU/Linux X: 1.19.2-1 radeon: 7.8.0
Thanks for any help.
https://bugs.freedesktop.org/show_bug.cgi?id=100289
Michel Dänzer michel@daenzer.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #130326|text/x-log |text/plain mime type| |
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #1 from Michel Dänzer michel@daenzer.net --- Please attach the corresponding dmesg output.
Does this still happen with xf86-video-ati 7.9.0?
(In reply to OmegaPhil from comment #0)
I found that when I turned it off for ~10 seconds or more, after turning it back on all screens would go black and appear to reinialise. XFCE4 gets confused and clones the primary monitor output to the new 3rd screen, fiddling in the XFCE4 Display program fixes this (after the problem happens it seems to put the primary and new monitor on top of each other...).
FWIW, this could be an XFCE issue, unless xrandr reports incorrect information about the connected monitors after this happens. Xorg only informs clients when something might have changed about the connected monitors, it doesn't perform any configuration changes by itself.
https://bugs.freedesktop.org/show_bug.cgi?id=100289
OmegaPhil@startmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |OmegaPhil@startmail.com
--- Comment #2 from OmegaPhil@startmail.com --- I have just built and installed from the debian-unstable branch off git (https://anonscm.debian.org/cgit/pkg-xorg/driver/xserver-xorg-video-ati.git/) which is directly tracking upstream - confirmed 7.9 is loaded, the problem is still present.
Hmm, so XFCE4 Display could be responsible for blacking out the other monitors momentarily too?
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #3 from Michel Dänzer michel@daenzer.net --- (In reply to OmegaPhil from comment #2)
confirmed 7.9 is loaded, the problem is still present.
Does radeon_scanout_flip still spit out both "Invalid argument" and "Device or resource busy" errors?
Hmm, so XFCE4 Display could be responsible for blacking out the other monitors momentarily too?
Yes, that could be a side effect of XFCE changing the virtual desktop resolution.
All of this could be triggered by the DisplayPort connection appearing disconnected while the monitor is off, which I understand can happen at least with some monitors.
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #4 from OmegaPhil@startmail.com --- Just 'Invalid argument' currently.
I just did 10 tests turning the monitor off for just over 30 seconds, and on turning it back on, the display layout did not break (but I got the usual flip queue messages):
==================================================
tail -F /var/log/Xorg.0.log | grep -iE 'flip|allocate'
[181332.656] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid argument [181356.321] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid argument [181356.742] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid argument [181357.947] (II) RADEON(0): Allocate new frame buffer 3840x1200 stride 3840 [181387.340] (II) RADEON(0): Allocate new frame buffer 5760x1200 stride 5760 [201695.702] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid argument [201696.734] (II) RADEON(0): Allocate new frame buffer 3840x1200 stride 3840 [201722.513] (II) RADEON(0): Allocate new frame buffer 5760x1200 stride 5760 [220260.080] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid argument [253009.764] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid argument [253022.375] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid argument [253034.800] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid argument [253060.151] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid argument [253109.552] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid argument [253109.561] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid argument [253153.533] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid argument [253203.721] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid argument [253204.176] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid argument [253251.989] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid argument [253296.426] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid argument [253359.934] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid argument [253360.370] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid argument [253413.594] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid argument [253508.625] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid argument [253508.630] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid argument [253509.047] (WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid argument
==================================================
This shows a few 'normal' failures from yesterday earlier on. When I came back from work and turned it on (so hours off), nothing broke... so it looks like something has changed or there is an unknown trigger.
I can sit on this until it happens again.
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #5 from OmegaPhil@startmail.com --- Ah, happened again after leaving it off for ~2 hours...
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #6 from OmegaPhil@startmail.com --- Ah sorry I was supposed to xrandr it when it broke - will happen again tomorrow I'm sure ;)
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #7 from OmegaPhil@startmail.com --- Just turned the monitors on in sequence left to right after dinner (new monitor is last), and the problem occurred:
============================================================================
$ xrandr -q
Screen 0: minimum 320 x 200, current 3840 x 1200, maximum 16384 x 16384 DisplayPort-0 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm 1920x1200 59.95*+ 1920x1080 60.00 50.00 59.94 30.00 25.00 24.00 29.97 23.98 1920x1080i 60.00 50.00 59.94 1600x1200 60.00 1280x1024 75.02 60.02 1152x864 75.00 1280x720 60.00 50.00 59.94 1024x768 75.03 60.00 800x600 75.00 60.32 720x576 50.00 720x576i 50.00 720x480 60.00 59.94 720x480i 60.00 59.94 640x480 75.00 60.00 59.94 720x400 70.08 HDMI-0 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm 1920x1200 59.95*+ 1920x1080 60.00 1600x1200 60.00 1680x1050 59.88 1280x1024 60.02 1440x900 59.90 1280x960 60.00 1024x768 60.00 800x600 60.32 640x480 59.94 DVI-0 disconnected (normal left inverted right x axis y axis) DVI-1 connected 1920x1200+1920+0 (normal left inverted right x axis y axis) 518mm x 324mm 1920x1200 59.95*+ 1920x1080 60.00 50.00 59.94 1600x1200 60.00 1680x1050 59.88 1280x1024 60.02 1440x900 59.90 1280x960 60.00 1280x800 59.91 1280x720 60.00 50.00 59.94 1024x768 60.00 800x600 60.32 56.25 720x576 50.00 720x480 60.00 59.94 640x480 60.00 59.94
============================================================================
So xrandr agrees that DisplayPort-0 and HDMI-0 are on top of each other at least.
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #8 from OmegaPhil@startmail.com --- For anyone else having this issue, looking through the xrandr output allows you to make a workaround, for me:
===============================================
xrandr --output DisplayPort-0 --right-of DVI-1
===============================================
is enough to get the correct layout (just one window seems to be consistently moved to the secondary monitor on top of this, probably as its maximised).
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #9 from OmegaPhil@startmail.com --- As nothings happened on this ticket for a few months, I've reached the task again. I can confirm DisplayPort-0 remains connected according to xrandr when its off, prior to the problem happening.
I'm now running Xorg with '-logverbose 255', but nothing more is logged when the problem occurs.
A new failure mode has emerged - sometimes the middle Samsung monitor goes off, and requires disabling and reenabling via the XFCE4 Display program to get it back on again (haven't tried with xrandr etc).
I'm a bit disappointed nothing more is logged by X, I'm going to see what I can find out in XFCE4's tooling.
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #10 from Julien Isorce julien.isorce@gmail.com --- It could be that drm.debug=0x01 will tell you if the error comes from one of the two "case:" here https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/drm_plane.c?h... . If it is the case it should appear in dmesg.
Also worth a try with https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/mesa with contains an up to date version of xf86-video-ati.
The error message is different but I wonder if the patch attached to https://bugs.freedesktop.org/show_bug.cgi?id=99769 would help here too.
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #11 from OmegaPhil@startmail.com --- Wow, thats one hell of a lot of output :) I'll keep running with 'drm.debug=0x01' until I get the problem next, thanks.
I'm on Devuan Testing rather than Ubuntu (RE the Padoka PPA) - looking at https://packages.qa.debian.org/m/mesa.html , I can see that 17.1.3-2 is coming to unstable shortly - is that still too old?
If yes, I'll look into building all the stuff myself (I'll look around for some docs and probably base it off packages I can see on the Padoka PPA I'm guessing.
Separately, https://bugs.freedesktop.org/show_bug.cgi?id=99769 is a great link - I have recently (in recent months) enabled TearFree, so if some related failure is the culprit that is at least some progress. I really like TearFree (without it the top of the primary monitor tears with fullscreen videos), but am perfectly happy to disable it to see if the issue goes away (TearFree is more than worth the current failure state mind).
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #12 from OmegaPhil@startmail.com --- I have reached this again, and can confirm that even with a kernel boot parameter of 'drm.debug=0x01', when I get '(WW) RADEON(0): flip queue failed in radeon_scanout_flip: Invalid argument' in Xorg.log, there is no mention of 'flip target' in the drm output.
I'm going to test with TearFree off to show that its definitely to blame.
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #13 from OmegaPhil@startmail.com --- Right, have just had my first example of the failure without TearFree and with no associated warning in Xorg.0.log - I'm going to see if I can poke at the problem from the XFCE4 side (I want to demonstrate a program being told to change the monitor layout at the very least, then go backwards from there).
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #14 from OmegaPhil@startmail.com --- After messing around with this on and off for months, I have found that the radeon_scanout_flip error is irrelevant - when the third monitor is turned off and on, sometimes DisplayPort-0 is reported as Disconnected and then Connected - through monitoring the root window (xev -root), I can finally get into a useful X events stream:
======================================================================
RRScreenChangeNotify event, serial 114, synthetic NO, window 0x4bc, root 0x4bc, timestamp 332828415, config_timestamp 386328254 size_index 65535, subpixel_order SubPixelHorizontalRGB rotation RR_Rotate_0 width 5760, height 1200, mwidth 1526, mheight 318
RRNotify event, serial 114, synthetic NO, window 0x4bc, subtype XRROutputChangeNotifyEvent output DisplayPort-0, crtc 79, mode 1920x1200 (1920x1200) rotation RR_Rotate_0 connection RR_Disconnected, subpixel_order SubPixelHorizontalRGB
RRScreenChangeNotify event, serial 115, synthetic NO, window 0x4bc, root 0x4bc, timestamp 332828415, config_timestamp 386328254 size_index 65535, subpixel_order SubPixelHorizontalRGB rotation RR_Rotate_0 width 5760, height 1200, mwidth 1526, mheight 318
RRNotify event, serial 115, synthetic NO, window 0x4bc, subtype XRRCrtcChangeNotifyEvent crtc 79, mode None, rotation RR_Rotate_0 x 0, y 0, width 0, height 0
RRNotify event, serial 115, synthetic NO, window 0x4bc, subtype XRROutputChangeNotifyEvent output DisplayPort-0, crtc None, mode None rotation RR_Rotate_0 connection RR_Disconnected, subpixel_order SubPixelHorizontalRGB
ConfigureNotify event, serial 115, synthetic NO, window 0x4bc, event 0x4bc, window 0x4bc, (0,0), width 5760, height 1200, border_width 0, above 0x0, override NO
RRScreenChangeNotify event, serial 117, synthetic NO, window 0x4bc, root 0x4bc, timestamp 386328636, config_timestamp 386328813 size_index 65535, subpixel_order SubPixelHorizontalRGB rotation RR_Rotate_0 width 5760, height 1200, mwidth 1526, mheight 318
RRNotify event, serial 117, synthetic NO, window 0x4bc, subtype XRROutputChangeNotifyEvent output DisplayPort-0, crtc None, mode None rotation RR_Rotate_0 connection RR_Connected, subpixel_order SubPixelHorizontalRGB
RRScreenChangeNotify event, serial 117, synthetic NO, window 0x4bc, root 0x4bc, timestamp 386328636, config_timestamp 386328813 size_index 65535, subpixel_order SubPixelHorizontalRGB rotation RR_Rotate_0 width 3840, height 1200, mwidth 1016, mheight 318
ConfigureNotify event, serial 117, synthetic NO, window 0x4bc, event 0x4bc, window 0x4bc, (0,0), width 3840, height 1200, border_width 0, above 0x0, override NO
...
RRScreenChangeNotify event, serial 125, synthetic NO, window 0x4bc, root 0x4bc, timestamp 386328636, config_timestamp 386328813 size_index 65535, subpixel_order SubPixelHorizontalRGB rotation RR_Rotate_0 width 3840, height 1200, mwidth 1016, mheight 318
RRNotify event, serial 125, synthetic NO, window 0x4bc, subtype XRRCrtcChangeNotifyEvent crtc 79, mode 1920x1200, rotation RR_Rotate_0 x 0, y 0, width 1920, height 1200
RRNotify event, serial 125, synthetic NO, window 0x4bc, subtype XRROutputChangeNotifyEvent output DisplayPort-0, crtc 79, mode 1920x1200 (1920x1200) rotation RR_Rotate_0 connection RR_Connected, subpixel_order SubPixelHorizontalRGB
ConfigureNotify event, serial 125, synthetic NO, window 0x4bc, event 0x4bc, window 0x4bc, (0,0), width 3840, height 1200, border_width 0, above 0x0, override NO
======================================================================
In the middle of that mess, there is a RRScreenChangeNotify event with width 3840, which signifies the invalid desktop state that I get as the result of the problem - I've managed to smoke it out to xfsettingsd (part of the xfce4-settings package) - it responds to the disconnection by disabling the CRTC, and then when it reappears, it enables it without a clue of what the monitor is, despite it being described in the xfconf settings - and therefore not putting it in the right place again.
xfsettingsd's version of the events:
=========================================================
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged. xfce4-settings(displays): RRScreenChangeNotify event received. xfce4-settings(displays): Refreshing RandR cache. xfce4-settings(displays): Detected CRTC 80. xfce4-settings(displays): Detected CRTC 79. xfce4-settings(displays): Detected CRTC 81. xfce4-settings(displays): Detected CRTC 82. xfce4-settings(displays): Detected CRTC 83. xfce4-settings(displays): Detected CRTC 84. xfce4-settings(displays): Detected output 85 DisplayPort-0. xfce4-settings(displays): Detected output 86 HDMI-0. xfce4-settings(displays): Detected output 88 DVI-1. xfce4-settings(displays): Noutput: before = 3, after = 3. xfce4-settings(displays): RRScreenChangeNotify event received. xfce4-settings(displays): Refreshing RandR cache. xfce4-settings(displays): Detected CRTC 80. xfce4-settings(displays): Detected CRTC 79. xfce4-settings(displays): Detected CRTC 81. xfce4-settings(displays): Detected CRTC 82. xfce4-settings(displays): Detected CRTC 83. xfce4-settings(displays): Detected CRTC 84. xfce4-settings(displays): Detected output 85 DisplayPort-0. xfce4-settings(displays): Detected output 86 HDMI-0. xfce4-settings(displays): Detected output 88 DVI-1. xfce4-settings(displays): Noutput: before = 3, after = 3. xfce4-settings(displays): RRScreenChangeNotify event received. xfce4-settings(displays): Refreshing RandR cache. xfce4-settings(displays): Detected CRTC 80. xfce4-settings(displays): Detected CRTC 79. xfce4-settings(displays): Detected CRTC 81. xfce4-settings(displays): Detected CRTC 82. xfce4-settings(displays): Detected CRTC 83. xfce4-settings(displays): Detected CRTC 84. xfce4-settings(displays): Detected output 86 HDMI-0. xfce4-settings(displays): Detected output 88 DVI-1. xfce4-settings(displays): Noutput: before = 3, after = 2. xfce4-settings(displays): Output disconnected: DisplayPort-0 xfce4-settings(displays): Disabling CRTC 79. xfce4-settings(displays): Normalized CRTC 80: size=1920x1200, pos=0x0. xfce4-settings(displays): Normalized CRTC 81: size=1920x1200, pos=1920x0. xfce4-settings(displays): min_h = 200, min_w = 320, max_h = 16384, max_w = 16384, prev_h = 1200, prev_w = 5760, prev_hmm = 318, prev_wmm = 1524, h = 1200, w = 3840, hmm = 318, wmm = 1016. xfce4-settings(displays): Applying desktop dimensions: 3840x1200 (px), 1016x318 (mm). xfce4-settings(displays): Configuring CRTC 80. xfce4-settings(displays): Configuring CRTC 79. xfce4-settings(displays): Configuring CRTC 81. xfce4-settings(displays): Configuring CRTC 82. xfce4-settings(displays): Configuring CRTC 83. xfce4-settings(displays): Configuring CRTC 84. xfce4-settings(displays): RRScreenChangeNotify event received. xfce4-settings(displays): Refreshing RandR cache. xfce4-settings(displays): Detected CRTC 80. xfce4-settings(displays): Detected CRTC 79. xfce4-settings(displays): Detected CRTC 81. xfce4-settings(displays): Detected CRTC 82. xfce4-settings(displays): Detected CRTC 83. xfce4-settings(displays): Detected CRTC 84. xfce4-settings(displays): Detected output 85 DisplayPort-0. xfce4-settings(displays): Detected output 86 HDMI-0. xfce4-settings(displays): Detected output 88 DVI-1. xfce4-settings(displays): Noutput: before = 2, after = 3. xfce4-settings(displays): New output connected: DisplayPort-0 xfce4-settings(displays): enabling crtc for DisplayPort-0 xfce4-settings(displays): CRTC 79 assigned to DisplayPort-0. xfce4-settings(displays): CRTC 79, output list[0] -> 85. xfce4-settings(displays): Normalized CRTC 80: size=1920x1200, pos=0x0. xfce4-settings(displays): Normalized CRTC 79: size=1920x1200, pos=0x0. xfce4-settings(displays): Normalized CRTC 81: size=1920x1200, pos=1920x0. xfce4-settings(displays): min_h = 200, min_w = 320, max_h = 16384, max_w = 16384, prev_h = 1200, prev_w = 5760, prev_hmm = 318, prev_wmm = 1524, h = 1200, w = 3840, hmm = 318, wmm = 1016. xfce4-settings(displays): Applying desktop dimensions: 3840x1200 (px), 1016x318 (mm). xfce4-settings(displays): Configuring CRTC 80. xfce4-settings(displays): Configuring CRTC 79. xfce4-settings(displays): Applying changes to CRTC 79. xfce4-settings(displays): Configuring CRTC 81. xfce4-settings(displays): Configuring CRTC 82. xfce4-settings(displays): Configuring CRTC 83. xfce4-settings(displays): Configuring CRTC 84. xfce4-settings(displays): RRScreenChangeNotify event received. xfce4-settings(displays): Refreshing RandR cache. xfce4-settings(displays): Detected CRTC 80. xfce4-settings(displays): Detected CRTC 79. xfce4-settings(displays): Detected CRTC 81. xfce4-settings(displays): Detected CRTC 82. xfce4-settings(displays): Detected CRTC 83. xfce4-settings(displays): Detected CRTC 84. xfce4-settings(displays): Detected output 85 DisplayPort-0. xfce4-settings(displays): Detected output 86 HDMI-0. xfce4-settings(displays): Detected output 88 DVI-1. xfce4-settings(displays): Noutput: before = 3, after = 3. xfce4-settings(displays): RRScreenChangeNotify event received. xfce4-settings(displays): Refreshing RandR cache. xfce4-settings(displays): Detected CRTC 80. xfce4-settings(displays): Detected CRTC 79. xfce4-settings(displays): Detected CRTC 81. xfce4-settings(displays): Detected CRTC 82. xfce4-settings(displays): Detected CRTC 83. xfce4-settings(displays): Detected CRTC 84. xfce4-settings(displays): Detected output 85 DisplayPort-0. xfce4-settings(displays): Detected output 86 HDMI-0. xfce4-settings(displays): Detected output 88 DVI-1. xfce4-settings(displays): Noutput: before = 3, after = 3. xfce4-settings(displays): RRScreenChangeNotify event received. xfce4-settings(displays): Refreshing RandR cache. xfce4-settings(displays): Detected CRTC 80. xfce4-settings(displays): Detected CRTC 79. xfce4-settings(displays): Detected CRTC 81. xfce4-settings(displays): Detected CRTC 82. xfce4-settings(displays): Detected CRTC 83. xfce4-settings(displays): Detected CRTC 84. xfce4-settings(displays): Detected output 85 DisplayPort-0. xfce4-settings(displays): Detected output 86 HDMI-0. xfce4-settings(displays): Detected output 88 DVI-1. xfce4-settings(displays): Noutput: before = 3, after = 3.
=========================================================
I'm assuming the important part from the X perspective is when xfsettingsd/displays.c:xfce_displays_helper_screen_on_event realises the display is Disconnected, and runs xfce_displays_helper_disable_crtc which calls XRRSetCrtcConfig with RRCrtc->mode of None/NULL.
If the daemon is killed, no reconfiguration occurs and the desktop keeps its correct configuration - presumably at the X level its just treated like a monitor powering off and on - so I guess the next step is for me to understand what is causing the Disconnect event to be fired through the stack, since the monitor is definitely not disconnected in reality.
Kudos to Michel for the guess earlier.
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #15 from OmegaPhil@startmail.com --- After being able to identify xfsettingsd as a potential cause (ignoring whether or not the monitor was actually Disconnected/Connected), I had a look at its bug tracker - and https://bugzilla.xfce.org/show_bug.cgi?id=14096 looks extremely suspicious - after applying the patch and turning on/off the monitor 10 times in a row (waiting 10 seconds inbetween), I haven't had a single desktop reconfiguration (the patch makes complete sense too WRT this problem), so I'm going to sit on this for a week to make sure its actually solved.
There seem to be a number of other people complaining of this issue over there too...
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #16 from Michel Dänzer michel@daenzer.net --- (In reply to OmegaPhil from comment #15)
I'm going to sit on this for a week to make sure its actually solved.
A month has passed, is there a verdict yet?
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #17 from OmegaPhil@startmail.com --- The patch was not enough, and my comments on that bug have been ignored - the key bit is:
========================================================================
I've tracked part of the problem down to xfsettingsd/displays.c:xfce_displays_helper_screen_on_event, L462 xfce_displays_helper_disable_crtc call - when this call is commented out, the monitor is always configured fine (and looking at xfsettingsd's debug output, in both the success and failure case there are plenty of events happening where all monitors are connected at the end to allow for proper configuration).
========================================================================
Commenting this out and I have had no further issues. The current state is good enough for me - you could counter and say that there should be no disconnect event in the first place, but I don't plan to look into anything further currently.
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #18 from Michel Dänzer michel@daenzer.net --- (In reply to OmegaPhil from comment #17)
The current state is good enough for me - you could counter and say that there should be no disconnect event in the first place, [...]
AFAIK that's up to the monitor (settings?), or possibly even a general issue with DisplayPort.
https://bugs.freedesktop.org/show_bug.cgi?id=100289
Martin Peres martin.peres@free.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |MOVED
--- Comment #19 from Martin Peres martin.peres@free.fr --- -- 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/786.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org