Bug 111687 - white screen with ShadowPrimary / glamor / xfwm4 with vsync on
Summary: white screen with ShadowPrimary / glamor / xfwm4 with vsync on
Status: NEW
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: not set not set
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-14 18:29 UTC by Dq8CokMHloQZw
Modified: 2019-09-16 16:56 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
turn on/off xfwm4's vsync without restarting X or xfwm4 (1.48 KB, application/x-shellscript)
2019-09-14 18:29 UTC, Dq8CokMHloQZw
no flags Details
Xorg.0.log with ShadowPrimary on aka whitescreen (70.17 KB, text/plain)
2019-09-16 16:22 UTC, Dq8CokMHloQZw
no flags Details
Xorg.0.log with ShadowPrimary off aka "fixed" (153.73 KB, text/plain)
2019-09-16 16:23 UTC, Dq8CokMHloQZw
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dq8CokMHloQZw 2019-09-14 18:29:53 UTC
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
Comment 1 Dq8CokMHloQZw 2019-09-14 18:42:28 UTC
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
Comment 2 Michel Dänzer 2019-09-16 14:48:32 UTC
Please (always) attach the corresponding full Xorg log file captured after reproducing the problem.

Does it also happen with Option "ShadowPrimary" not enabled?
Comment 3 Dq8CokMHloQZw 2019-09-16 16:22:30 UTC
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.
Comment 4 Dq8CokMHloQZw 2019-09-16 16:23:03 UTC
Created attachment 145379 [details]
Xorg.0.log with ShadowPrimary off   aka "fixed"


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.