On Thu, 31 Oct 2019 13:47:06 +0000
"Patrick Harper" <paianni@fastmail.com> wrote:
> I haven't tried those settings yet (in my case GNOME Shell and
> Xfdashboard cause the display to corrupt and seize up except the
> cursor) but ShadowPrimary is a glamor option that should be
> irrelevant if EXA is used.
Thanks, my mistake, ShadowPrimary is a glamor-only option; this is
clear from the radeon (4) man page; I believe I toggled this prior to
switching to EXA in the hope that it would fix the corruption seen when
I had previously toggled "SWcursor" in order to fix the mouse cursor
vanishing when over certain widgets; this didn't help in my case
(radeon/aruba/xfce).
If anyone wants to try the changes I suggested, they can surely leave
out the ShadowPrimary option.
Toggling SwapbuffersWait and EnablePageFlip (to "off") was an attempt
to eliminate some remaining 'rarely' flicker seen; it *seemed* to help,
but I haven't spent a lot of time investigating, my goal was to get the
machine usable again.
The idea behind "EnablePageFlip" to "off" is that it seemed to look
like graphic content was being rendered for some windows/widgets on one
backbuffer but not on the other (again, I'm only speculating, as I
don't know what's really going on under the hood), so that the content
'flickers' when page flipping is happening. This *could* be the result
of a render operation succeeding for one back-buffer and failing for
another; I don't really know.
The idea behind "SwapbuffersWait" to "off" falls in the random guess
category. I think one would expect to maybe see some tearing
for GL applications if this option wasn't working correctly; but, I
could also see how a fault here could lead to flickering (depending on
the implementation), but is probably unlikely. I think changing this
option may also have no effect.
P.S. / Aside:
For anyone experiencing graphics issues after installing 6.6,
it might be a good idea to ensure that, if needed:
machdep.allowaperture is set to the correct value (see: man xf86) for
your system (and please be aware of the security implications of
changing this value).
regards,
Jeff
No comments:
Post a Comment