Created attachment 145364 [details] turn on/off xfwm4's vsync without restarting X or xfwm4 If I use Option "AccelMethod" "Glamor" in /etc/X11/xorg.conf.d/93_dri.conf So it looks like this: Section "Device" Identifier "Device0" Driver "radeon" BusID "PCI:0:1:0" Option "DRI" "3" Option "DRI3" "1" Option "AccelMethod" "Glamor" #was EXA Option "EXAVSync" "on" Option "RenderAccel" "on" Option "ColorTiling" "on" Option "ColorTiling2D" "on" Option "EXAPixmaps" "on" Option "AccelDFS" "on" Option "SwapbuffersWait" "true" Option "EnablePageFlip" "on" Option "SWcursor" "off" Option "MigrationHeuristic" "greedy" Option "Backlight" "radeon_bl" Option "ShadowPrimary" "on" Option "TearFree" "on" EndSection Section "DRI" Group "video" Mode 0666 EndSection then the X screen is white and I can't see what I'm doing behind it... but if I turn off vsync(blindly) by running `vsync off` in a terminal, to turn off vsync in xfwm4 while X is running, then everything becomes visible and I'm writing this whole thing here now. If I turn vsync on by `vsync glx` or `vsync xpresent` or `vsync auto` then I get white screen again! To turn on/off xfwm4's vsync I use the `vsync` script which can be found here: https://gist.github.com/howaboutsynergy/c2d9d3f6f60497f5c95f445a326cfec8 (I'm attaching it just in case the url goes away) xfwm4 4.14.0+12+g99352a08-1 xfconf 4.14.1-1 pygtk 2.24.0-8 xf86-video-ati 1:19.0.1.r7.gc7ed12cb-1
When using the debug patch from here: https://bugs.freedesktop.org/show_bug.cgi?id=74096#c7 the output for 11111 and 222222 is correct in this case with AccelMethod Glamor instead of EXA (it's EXA on the bug where the patch is linked and 1111 doesn't appear there, hence why it coredumps there) .... [ 12410.692] (II) RADEON(0): Front buffer size: 4224K [ 12410.692] (II) RADEON(0): VRAM usage limit set to 225165K [ 12410.692] (II) RADEON(0): SYNC extension fences enabled [ 12410.692] (II) RADEON(0): Present extension enabled [ 12410.692] (**) RADEON(0): DRI3 enabled [ 12410.692] (==) RADEON(0): Backing store enabled [ 12410.692] (II) RADEON(0): Direct rendering enabled [ 12410.728] (WW) RADEON(0): 111111111111this should happen first [ 12410.728] (II) RADEON(0): Use GLAMOR acceleration. [ 12410.728] (II) RADEON(0): Acceleration enabled [ 12410.728] (==) RADEON(0): DPMS enabled [ 12410.728] (==) RADEON(0): Silken mouse disabled ... [ 12410.896] (**) Option "xkb_model" "pc105" [ 12410.896] (**) Option "xkb_layout" "us" [ 12410.896] (**) Option "xkb_variant" "basic" [ 12410.896] (**) Option "xkb_options" "terminate:ctrl_alt_bksp,numpad:microsoft " [ 12411.508] (WW) RADEON(0): 22222222 this should happen second [ 12411.508] (WW) RADEON(0): 22222222 this should happen second [ 12412.604] (II) RADEON(0): EDID vendor "LGD", prod id 732 [ 12412.604] (II) RADEON(0): Printing DDC gathered Modelines: [ 12412.604] (II) RADEON(0): Modeline "1366x768"x0.0 70.00 1366 1402 1450 1492 768 771 776 782 -hsync -vsync (46.9 kHz eP) [ 12412.693] (WW) RADEON(0): 22222222 this should happen second [ 12412.693] (WW) RADEON(0): 22222222 this should happen second [ 12412.700] (WW) RADEON(0): 22222222 this should happen second [ 12412.700] (WW) RADEON(0): 22222222 this should happen second [ 12412.896] (WW) RADEON(0): 22222222 this should happen second [ 12412.896] (WW) RADEON(0): 22222222 this should happen second [ 12412.902] (WW) RADEON(0): 22222222 this should happen second
Please (always) attach the corresponding full Xorg log file captured after reproducing the problem. Does it also happen with Option "ShadowPrimary" not enabled?
Created attachment 145378 [details] Xorg.0.log with ShadowPrimary on aka whitescreen My bad, for some reason I assumed it wasn't necessary to attach full Xorg.0.log especially since it was kinda big and it'd need a reboot to get the slimmest one instead. Indeed, it doesn't happen with ShadowPrimary off.
Created attachment 145379 [details] Xorg.0.log with ShadowPrimary off aka "fixed"
-- 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/xorg/driver/xf86-video-ati/issues/185.
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.