Flickering and rendering issues; non-functional (Nouveau)

[piperfw]

Platform

Arch Linux (4.18.16-arch1-1-ARCH)

GPU, drivers, and screen setup

• NVidia GTX 670,
• xf86-video-nouveau and mesa (OpenGL)
• Two monitors configured side-by-side with xrandr

Environment

• i3-wm

Compton version

v3-rc2-18-gc0d7f9d

Compton configuration:

Default

Steps of reproduction

1. Start compton

Expected behaviour

composite manager runs and provides compositing

Current Behaviour

Severe rendering issues; rapid flickering; window frequently disappears (see video)

Other details

Link to video (Google Drive - download if stream doesn't work) of behaviour: compton_issue.mp4
The program vlc is running in the active window as an example.

[yshui]

What is your configuration?

[piperfw]

I am using the default configuration file, compton.conf, that comes with the arch linux package, and am running compton with either compton or compton -b (daemon) from a terminal.

I have tried --sw-opti and --unredir-if-possible, to no effect.

I should definitely add that a previous version of compton (2.0-2?) ran without issue on my system.

[yshui]

What happens when you start compton with compton --config /dev/null and compton --config /dev/null --backend glx ?

[piperfw]

The issue is not present when using compton --config /dev/null.

compton --config /dev/null --backend glx immediately blacks out the entire display, and then the flickering appears to return.

I can upload a copy of the config file I was using if that would be useful?

[yshui]

If that is the case, a workaround for now will be using the xrender backend.

Did this issue happen with earlier version of compton (v2 for example)? Are you familiar with git enough to do a bisect?

When you test earlier versions of compton, remember to use --backend glx --config /dev/null, which choose the glx backend, and uses an all default config.

[yshui]

Sorry for closing, didn't mean to.

[piperfw]

This issue has never occurred before with v2. I am not familiar with bisect, but can tell you the last good/first bad commit on the arch community repository (packages/compton View Changes): upgpkg: compton 2.0-2 (10 days ago) was fine, upgpkg: compton 3.0-1 (24 hours ago) was bad.

I can downgrade and test v2 with --backend glx --config /dev/null if this would be useful for you? I've always just used the default compton.conf file with previous versions (no issues).

[yshui]

Yes, that would be useful.

[piperfw]

v2.0 worked with --backend glx --config /dev/null no issues.

[hertzhaft]

I can confirm the same issue. Occurred first with last Arch Linux update, v. 3.0.1, created 2018-10-29. Returning to --backend xrender fixes the issue.
Linux version 4.18.16-arch1-1-ARCH
lspci -k | grep -A 2 -E "(VGA|3D)"
01:00.0 VGA compatible controller: NVIDIA Corporation GT218M [GeForce G210M] (rev a2)
Subsystem: Acer Incorporated [ALI] GT218M [GeForce G210M]
Kernel driver in use: nouveau

[yshui]

I have some guesses. Can you record a trace of compton use apitrace? Thanks.

[yshui]

And if you can, can you record a trace of compton v2 as well? So we can compare.

[yshui]

Got a lead from #34. What do your xorg.conf/xorg.conf.d look like?

[piperfw]

Aside from a keyboard config file (00-keyboard.conf), I believe that I am using the default configuration files supplied by arch, which I've attached for reference (10-quirks.conf , 40-libinput.conf - the only files in /usr/share/X11/xorg.conf.d/). I start the Xorg server using xinit.

00-keyboard.conf.txt
10-quirks.conf.txt
40-libinput.conf.txt

[yshui]

OK. Hmm, I don't see anything suspicious in those config...

Were you able to get a apitrace though?

[piperfw]

Let me know if these are what you want. I wasn't sure how to pass --config /dev/null --backend glx to compton when using apitrace. If this is important let me know how and I will re-do them.

comptonV2.trace
comptonV3.trace

[hiciu]

I'm having the same issue. It looks like this: https://a.uguu.se/6ldCwZGaMQyq.mkv.

i3, nouveau, nvidia gtx760, two monitors configured with xrandr. Doesn't happen with only 1 monitor.

At the same time xcompmgr works just fine. Starting git bisect now.

[yshui]

@hiciu The bad commit you find will probably be 28a2cc6.

Actually, your issue looks like something else...

[hiciu]

I might be doing something wrong, but compton built from source works just fine..? I have no issues with 46a6a39, db700f9, and other commits up until d7b5104.

I'm testing with:

make; and ./compton --config /dev/null --backend glx

edit: no issues with 28a2cc6 too.
edit 2: I'm using arch linux, maybe there are some patches applied in pkgbuild? Rebuilding that package right now.

[hiciu]

I just rebuild this package: https://www.archlinux.org/packages/community/x86_64/compton/ with makepkg and it works just fine, I have no issues... (removed, see comment history)

Please disregard that, it came back after a reboot. It's non-deterministic? It went away, for a while, after testing with xrandr / xcompmgr? I'm not sure what happened.

Doing git bisect again.

[hiciu]

OK, after second git bisect I have 967d9f3 as a last good commit and 7af815a as a first bad one. This time I rebooted and tested it again, to be sure.

[yshui]

@hiciu So you are saying the head of next works just fine? Or is v3 working just fine?

7af815a as a first bad one

That is really weird, since that commit changes nothing about what compton does, it just switched to xcb for event handling. If it really is the bad commit then something really weird is going on.

[hiciu]

@hiciu So you are saying the head of next works just fine? Or is v3 working just fine?

Sorry about the confusion. Head of next was working for a while - I'm not sure why / how - but the issue came back after a reboot. I posted that one comment when I though it was working, before a reboot.

Right now d7b5104 (current head of next) again works for me. But I'm 100% sure that if I reboot, it will break.

That is really weird, since that commit changes nothing about what compton does

Yeah, that and fact that the issue is not occurring right now - that's probably a nouveau bug.

I'm attaching a video of me running d7b5104 (current head) right now, with no issues: https://a.uguu.se/1lXXovcjzD8T.mkv. I'll attach another one, after a reboot, hopefully showing the same compilation with flickering.

[hiciu]

And here, after a reboot: https://a.uguu.se/YpbGJqFOTo5l.mkv

1. I'm running d7b5104 (current head) - there are rendering issues,
2. I'm switching to 967d9f3 - no issues,
3. I'm switching to 7af815a - there again are issues.

I can't explain why it behaves the way it does. At this point I'm pretty sure this has nothing to do with compton.

[yshui]

The way compton uses opengl has only very slightly changed. So if compton is using opengl wrong, it has being using opengl wrong all along. The fact it worked before, and works now with probably most of the drivers makes me think the way it uses opengl is fine.

OTOH, the communication pattern between X and compton has changed a bit, because we moved to xcb and eliminated the use of Xfixes. So, this could be that the timing of things changed, and that triggered a previously unexposed bug in the driver. Although I am not very confident of that.

I think right now, the best thing for me to do is to continue investigation. But at the same time we should also raise this issue to nouveau, and see if they have more insights.

[piperfw]

@yshui I just saw your comment and decided to try v3 after disconnecting my second monitor... No change - the rendering/flickering issue is still present with only one monitor connected, for me at least.

[yshui]

@piperfw OK, at least we ruled out one of the possibilities.

[yshui]

@piperfw BTW, was your screen flickering when you made the traces?

[piperfw]

@yshui For v3, most definitely. I can re-do to confirm if necessary.

[yshui]

@piperfw That is fine. Just to confirmed, you had terminal windows and browser open when you were recording. And they are flickering, is that right? Do you have to scroll the page in the browser to make it flicker, or did it flicker without you doing anything?

Also, how much time did you record in the traces?

[piperfw]

@yshui I believe I had terminal windows, a text editor and chromium open (I don't have firefox on my system). All were flickering severely. No scrolling, or interaction of any form for that matter, required.

For the v2 trace, I must have left it on for at least 30 secs-min. Then I saw how large the file was and ended up doing the v3 trace for probably less than 10 seconds.

It's possibly some rare glitch with my particular system/environment, seen as there haven't been many people coming here with the same issue? In which case you shouldn't worry about it too much, I don't mind just using v2 as it works perfectly :).

I'm signing off for the day but will check back here first thing tomorrow.

[yshui]

@piperfw Ah, also, when you disabled your second monitor, did you just disconnect it? Did you actually disable it with xrandr?

[piperfw]

@yshui I physically disconnected it only (my xrandr lists four outputs, two of which are usually connected).

[yshui]

@piperfw can you try disabling it too?

Also, what is the version of Mesa you and @hiciu use?

[piperfw]

@yshui Just tried disabling the second monitor (as well as disabling and disconnecting). The issue persists.

pacman -Qs mesa tells me

local/glu 9.0.0-5
    Mesa OpenGL Utility library
local/mesa 18.2.4-1
    An open-source implementation of the OpenGL specification
local/mesa-demos 8.4.0-1
    Mesa demos and tools incl. glxinfo + glxgears

[yshui]

@piperfw Thanks a lot for the information.

[piperfw]

@yshui You're welcome; just @me here if there's any other information that might be helpful.

[Exagone313]

I have a similar issue but it happens right after starting my i3 session, every ~300 ms (or every time I press a key in a text input) it switches back and forth between the first frame ever shown at session startup (black screen when starting from startx, or display manager's wallpaper) and the current real frame.

I'm not sure if I should create a new issue, I think the root cause it the same. I'm using a GTX 760 with nouveau on arch, with i3-gaps. I don't mind keeping the previous version that works fine.

EDIT: it seems that arch's maintainer updated compton 5 hours ago (to 7bdebbe), haven't tried it yet.

[yshui]

@Exagone313 Sounds like the same issue. 7bdebbe is not relevant to this issue. I'm still waiting for more info from nouveau developers.

[hiciu]

@hiciu Does this problem happen when you have only one monitor connected?

Well, for me it depends. In current setup I have two monitors: one connected via DP and one connected via DVI-D (not sure if that matters, DP-1 is configured as primary).

So, for me, there are 3 possible configurations:

1. both DVI-D-1 and DP-1 are active (xrandr --output DP-1 --primary --left-of DVI-D-1 --auto),
2. only DP-1 is active, DVI-D-1 is turned off,
3. only DVI-D-1 is active, DP-1 is off.

The issue happens in cases 1. and 2., I have no problems in case 3. (I'll confirm that after a reboot).

Also, when I switch between cases 1., 2. and 3. the issue goes away. Right now everything works - during writing this comment I was switching between scenarios 2. and 3. and now the bug is gone (I'm not yet sure which combination exactly hides the issue).

@piperfw, could you try disabling your other monitor?

Mesa versions:

local/glu 9.0.0-5
    Mesa OpenGL Utility library
local/lib32-glu 9.0.0-4
    Mesa OpenGL utility library (32 bits)
local/lib32-libtxc_dxtn 1.0.1-5
    S3 Texture Compression (S3TC) library for Mesa (32-bit)
local/lib32-mesa 18.2.4-1
    An open-source implementation of the OpenGL specification (32-bit)
local/libtxc_dxtn 1.0.1-6
    S3 Texture Compression (S3TC) library for Mesa
local/mesa 18.2.4-1
    An open-source implementation of the OpenGL specification
local/mesa-demos 8.4.0-1
    Mesa demos and tools incl. glxinfo + glxgears
local/mesa-vdpau 18.2.4-1
    Mesa VDPAU drivers

And my xrandr -q:

Screen 0: minimum 320 x 200, current 3840 x 1080, maximum 16384 x 16384
DVI-I-1 disconnected (normal left inverted right x axis y axis)
DVI-D-1 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 510mm x 287mm
   1920x1080     60.00*+
   1680x1050     59.88
   1280x1024     60.02
   1440x900      59.90
   1280x720      60.00
   1024x768      60.00
   800x600       60.32
   640x480       59.94
   720x400       70.08
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 528mm x 297mm
   1920x1080     60.00*+  59.94
   1680x1050     59.95
   1600x900      60.00
   1280x1024     60.02
   1280x800      59.81
   1280x720      60.00    59.94
   1024x768      60.00
   800x600       60.32
   720x480       60.00    59.94
   640x480       60.00    59.94
   720x400       70.08

[yshui]

@hiciu Now it sounds more and more like a driver bug.

BTW, my bug report to upstream is here: https://bugs.freedesktop.org/show_bug.cgi?id=108651. I guess we just have to wait. If you think I missed some information in my bug report, feel free to add to it.

[yshui]

@hiciu Can you try add Option "DRI" "3" to the Device section of your xorg.conf, see if that works?

[hiciu]

@yshui

Before changing to DRI 3:

hiciu@unknown ~> grep DRI /var/log/Xorg.0.log
[    23.504] (==) NOUVEAU(0): Allowed maximum DRI level 2.
[    23.724] (II) NOUVEAU(0): [DRI2] Setup complete
[    23.724] (II) NOUVEAU(0): [DRI2]   DRI driver: nouveau
[    23.724] (II) NOUVEAU(0): [DRI2]   VDPAU driver: nouveau
[    23.729] (II) Initializing extension DRI3
[    24.304] (II) GLX: Initialized DRI2 GL provider for screen 0
[    24.304] (II) Initializing extension XFree86-DRI
[    24.304] (II) Initializing extension DRI2

After:

hiciu@unknown ~> grep DRI /var/log/Xorg.0.log
[   925.222] (**) NOUVEAU(0): Option "DRI" "3"
[   925.222] (**) NOUVEAU(0): Allowed maximum DRI level 3.
[   925.340] (II) NOUVEAU(0): [DRI2] Setup complete
[   925.340] (II) NOUVEAU(0): [DRI2]   DRI driver: nouveau
[   925.340] (II) NOUVEAU(0): [DRI2]   VDPAU driver: nouveau
[   925.343] (II) Initializing extension DRI3
[   925.398] (II) GLX: Initialized DRI2 GL provider for screen 0
[   925.398] (II) Initializing extension XFree86-DRI
[   925.398] (II) Initializing extension DRI2

The issue is still present with Option "DRI" "3".

Also after some testing I've found that this combination of xrandr commands:

xrandr --output DP-1 --off; xrandr --output DP-1 --auto; xrandr --output DP-1 --primary --left-of DVI-D-1 --auto

fixes the issue for me until I restart my X server again.

[hiciu]

At the same time the issue is not present if I use Option "NoAccel" "true" or if I start compton with env LIBGL_ALWAYS_SOFTWARE=1 compton --config /dev/null --backend glx. (It's obviously a bit slow, but the issue is gone).

[yshui]

@hiciu Looks like your nouveau just doesn't have DRI3.

I think we might have found the root cause of this problem (see #47), and there is known workaround, I will implementing it ASAP

[yshui]

@piperfw @hiciu Can you test the dri2-hack branch, see if it fixes your problem?

[hiciu]

I'm getting an error during compilation here:

hiciu@unknown ~/s/2/1/c/compton (dri2-hack)> git rev-parse HEAD
3aa490a12e1c51440428b620fdc665708403f8ec
hiciu@unknown ~/s/2/1/c/compton (dri2-hack)> make clean; make
mkdir -p .deps
cc -std=c11 -D_GNU_SOURCE -Wall -Wextra -Wno-unused-parameter -Wnonnull -DCONFIG_XINERAMA -DCONFIG_LIBCONFIG -DCONFIG_REGEX_PCRE -DCONFIG_REGEX_PCRE_JIT -DCONFIG_VSYNC_DRM -DCONFIG_OPENGL -DCONFIG_DBUS -DCONFIG_XSYNC -DCOMPTON_VERSION="\"git-v4-rc1-10-g3aa490a-2018-11-10\""    -I/usr/include/libdrm  -I/usr/include/pixman-1 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include  -c src/compton.c -o compton.o
cc -std=c11 -D_GNU_SOURCE -Wall -Wextra -Wno-unused-parameter -Wnonnull -DCONFIG_XINERAMA -DCONFIG_LIBCONFIG -DCONFIG_REGEX_PCRE -DCONFIG_REGEX_PCRE_JIT -DCONFIG_VSYNC_DRM -DCONFIG_OPENGL -DCONFIG_DBUS -DCONFIG_XSYNC -DCOMPTON_VERSION="\"git-v4-rc1-10-g3aa490a-2018-11-10\""    -I/usr/include/libdrm  -I/usr/include/pixman-1 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include  -c src/config.c -o config.o
cc -std=c11 -D_GNU_SOURCE -Wall -Wextra -Wno-unused-parameter -Wnonnull -DCONFIG_XINERAMA -DCONFIG_LIBCONFIG -DCONFIG_REGEX_PCRE -DCONFIG_REGEX_PCRE_JIT -DCONFIG_VSYNC_DRM -DCONFIG_OPENGL -DCONFIG_DBUS -DCONFIG_XSYNC -DCOMPTON_VERSION="\"git-v4-rc1-10-g3aa490a-2018-11-10\""    -I/usr/include/libdrm  -I/usr/include/pixman-1 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include  -c src/win.c -o win.o
cc -std=c11 -D_GNU_SOURCE -Wall -Wextra -Wno-unused-parameter -Wnonnull -DCONFIG_XINERAMA -DCONFIG_LIBCONFIG -DCONFIG_REGEX_PCRE -DCONFIG_REGEX_PCRE_JIT -DCONFIG_VSYNC_DRM -DCONFIG_OPENGL -DCONFIG_DBUS -DCONFIG_XSYNC -DCOMPTON_VERSION="\"git-v4-rc1-10-g3aa490a-2018-11-10\""    -I/usr/include/libdrm  -I/usr/include/pixman-1 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include  -c src/x.c -o x.o
cc -std=c11 -D_GNU_SOURCE -Wall -Wextra -Wno-unused-parameter -Wnonnull -DCONFIG_XINERAMA -DCONFIG_LIBCONFIG -DCONFIG_REGEX_PCRE -DCONFIG_REGEX_PCRE_JIT -DCONFIG_VSYNC_DRM -DCONFIG_OPENGL -DCONFIG_DBUS -DCONFIG_XSYNC -DCOMPTON_VERSION="\"git-v4-rc1-10-g3aa490a-2018-11-10\""    -I/usr/include/libdrm  -I/usr/include/pixman-1 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include  -c src/config_libconfig.c -o config_libconfig.o
cc -std=c11 -D_GNU_SOURCE -Wall -Wextra -Wno-unused-parameter -Wnonnull -DCONFIG_XINERAMA -DCONFIG_LIBCONFIG -DCONFIG_REGEX_PCRE -DCONFIG_REGEX_PCRE_JIT -DCONFIG_VSYNC_DRM -DCONFIG_OPENGL -DCONFIG_DBUS -DCONFIG_XSYNC -DCOMPTON_VERSION="\"git-v4-rc1-10-g3aa490a-2018-11-10\""    -I/usr/include/libdrm  -I/usr/include/pixman-1 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include  -c src/opengl.c -o opengl.o
cc -std=c11 -D_GNU_SOURCE -Wall -Wextra -Wno-unused-parameter -Wnonnull -DCONFIG_XINERAMA -DCONFIG_LIBCONFIG -DCONFIG_REGEX_PCRE -DCONFIG_REGEX_PCRE_JIT -DCONFIG_VSYNC_DRM -DCONFIG_OPENGL -DCONFIG_DBUS -DCONFIG_XSYNC -DCOMPTON_VERSION="\"git-v4-rc1-10-g3aa490a-2018-11-10\""    -I/usr/include/libdrm  -I/usr/include/pixman-1 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include  -c src/dbus.c -o dbus.o
cc -std=c11 -D_GNU_SOURCE -Wall -Wextra -Wno-unused-parameter -Wnonnull -DCONFIG_XINERAMA -DCONFIG_LIBCONFIG -DCONFIG_REGEX_PCRE -DCONFIG_REGEX_PCRE_JIT -DCONFIG_VSYNC_DRM -DCONFIG_OPENGL -DCONFIG_DBUS -DCONFIG_XSYNC -DCOMPTON_VERSION="\"git-v4-rc1-10-g3aa490a-2018-11-10\""    -I/usr/include/libdrm  -I/usr/include/pixman-1 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include  -c src/c2.c -o c2.o
cc -std=c11 -D_GNU_SOURCE -Wall -Wextra -Wno-unused-parameter -Wnonnull -DCONFIG_XINERAMA -DCONFIG_LIBCONFIG -DCONFIG_REGEX_PCRE -DCONFIG_REGEX_PCRE_JIT -DCONFIG_VSYNC_DRM -DCONFIG_OPENGL -DCONFIG_DBUS -DCONFIG_XSYNC -DCOMPTON_VERSION="\"git-v4-rc1-10-g3aa490a-2018-11-10\""  -Wl,-O1 -Wl,--as-needed -o compton compton.o config.o win.o x.o config_libconfig.o opengl.o dbus.o c2.o -lGL -lm -lrt -lev -lpcre -lX11-xcb -lX11 -lxcb-render-util -lxcb-render -lxcb-damage -lxcb-randr -lxcb-composite -lxcb-shape -lxcb-image -lxcb -lxcb-shm -lxcb-xfixes -lXext -lpixman-1 -lxcb-xinerama -lconfig -ldbus-1
/usr/sbin/ld: compton.o: in function `session_init':
compton.c:(.text+0xcfcc): undefined reference to `xcb_present_id'
/usr/sbin/ld: compton.c:(.text+0xd449): undefined reference to `xcb_present_id'
/usr/sbin/ld: compton.c:(.text+0xd614): undefined reference to `print_diagnostics'
collect2: error: ld returned 1 exit status
make: *** [Makefile:150: compton] Error 1

[hiciu]

I got it to build with meson. It works! It's gone with 3aa490a.

I've also checked previous commit to make sure and the issue is still present on 45a260b - so 3aa490a fixed it.

Thank you!

[piperfw]

I've just built and tested 47377df on dri2-hack.

The problem is still present for me with compton --config /dev/null --backend glx, but not when
compton --config /dev/null alone is used (as before).

[yshui]

@piperfw you are on the wrong commit, head of dri2-hack is bcab5d1

[piperfw]

Oops! @yshui pulled the correct commit now and the bug appears to have gone! Will run for a while now to check.