On Mon, Apr 13, 2020 at 03:54:56PM +0200, Rhialto wrote:
from Xorg.0.log:
[ 27.951] (**) modeset(0): Option "AccelMethod" "XAA"
[ 28.367] (II) Initializing extension GLX
[ 28.391] (II) AIGLX: Screen 0 is not DRI2 capable
[ 35.846] (II) IGLX: Loaded and initialized swrast
[ 35.846] (II) GLX: Initialized DRISWRAST GL provider for screen 0
[ 35.846] (II) Initializing extension XFree86-VidModeExtension
[ 35.847] (II) Initializing extension XFree86-DGA
[ 35.848] (II) Initializing extension XFree86-DRI
[ 35.868] (II) Initializing extension DRI2
Note that I used to have XVideo support in the past, but no longer:
GL screensavers are also falling back to being slow (I usually test this
with the screensaver /usr/pkg/libexec/xscreensaver/carousel -fps which
is much slower (~20 fps) than it could be (~50 fps), with much higher
cpu usage).
vargaz:/var/log$ xvinfo
X-Video Extension version 2.2
screen #0
no adaptors present
Fortunately my other machine with Radeon graphics still has xv, and
mpv also works.
So, for clarification, xf86-video-modesetting is supposed to be much
better if glamor is enabled. With base xsrc we have some bug that we
haven't found yet, but I don't remember, it might work fine with pkgsrc
xorg.
Note that pkgsrc xorg has its own problem: x11/xf86-video-intel points
at the latest release, which is (???) outdated and doesn't work for
newer cards. NetBSD xsrc uses a git snapshot, and we should do the same
or even rip it out for modesetting if that one has glamor.
Certainly people have mentioned fewer graphical glitches with it, but I
feel like switching to modesetting is papering over the issue. My
current theory for why the graphical glitches happen is that memory
which is mapped write-combining doesn't get synced often enough, or
perhaps we made an error and it should have been mapped write-back.