Bug 111687

Summary:

white screen with ShadowPrimary / glamor / xfwm4 with vsync on

Product:

xorg

Reporter:

Dq8CokMHloQZw <howaboutsynergy>

Component:

Driver/Radeon

Assignee:

xf86-video-ati maintainers <xorg-driver-ati>

Status:

RESOLVED MOVED

QA Contact:

Xorg Project Team <xorg-team>

Severity:

not set

Priority:

not set

CC:

howaboutsynergy

Version:

git

Hardware:

x86-64 (AMD64)

OS:

Linux (All)

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
turn on/off xfwm4's vsync without restarting X or xfwm4	none
Xorg.0.log with ShadowPrimary on aka whitescreen	none
Xorg.0.log with ShadowPrimary off aka "fixed"	none

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"

Comment 5 Martin Peres 2019-11-19 08:02:30 UTC

-- 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.