pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Firefox and the broken about:login, a temporary workaround

On 13/04/2020 15:13, wrote:
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

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.

Haven't tried modesetting as apart from what look like cache coherency issues the intel driver is reliable for me on:

i915drmkms0 at pci0 dev 2 function 0: vendor 8086 product 0412 (rev. 0x06)

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.

I think you are right about this. I see occasional messages of the form:

kern error: [drm:(/work/netbsd/9-stable/src/sys/external/bsd/drm2
/dist/drm/i915/intel_sprite.c:132)intel_pipe_update_start] *ERROR* Potential atomic update failure on pipe A: -35

Looking at this code the comments suggest that the code is expecting a memory barrier but I don't see how the NetBSD implementation provides one.


Home | Main Index | Thread Index | Old Index