Created attachment 126073 [details]
Screenshot showing the issue on Mumble and Audacious
After working around bug #94990 so that I can use kernel modesetting, I find that when I run a Qt application inside my regular desktop environment, Enlightenment E20 (0.20.5) in Xorg server 1.18.4, I get issues with screen updates, resulting in artifacts such as shown in the attached screenshot. It appears to have issues switching between the current state and a previously drawn state.
The issue does not appear in any non-Qt applications as far as I can tell. Note that in the attached screenshot, Mumble is a Qt4 app and Audacious is a Qt5 app (here running using the Winamp Classic interface). Only some Qt widgets appear to be affected; so far I've only encountered the issue with menus, graphical tab bars (such as the one Audacious uses in its preferences window), toolbars, and however Audacious renders the scrolling text in its Winamp Classic interface.
After talking with a nouveau dev on IRC (karolherbst), we determined that the issue does not appear when the PageFlip option is set to 0 in an xorg.conf.d file. (I will attach the configuration file I use to this bug.) I also managed to determine that the corruption does not appear when I use another window manager without a compositor, such as mwm. Interestingly, the corruption does not reappear if I use mwm together with compton, a standalone compositor.
This bug only started happening after updating to Xorg server version 1.18.4 from 1.17.4. I have not as yet tested any of the previous 1.18.x releases; if this is desired, please let me know.
Summary of system:
* Gentoo Linux, amd64, fully up-to-date, using x11 overlay
* NVidia GeForce GTX 970 (GM204)
* Kernel version 4.7.0 (with a modification to bypass bug #94990)
* Xorg server 1.18.4
* Mesa 12.0.1
* Enlightenment 0.20.5
* Qt versions installed: 4.8.6 and 5.6.1.
* Examples of Qt applications tested: Mumble (1.2.16), Audacious (3.7.1), VLC (2.2.4), Wireshark (2.0.5).
Created attachment 126074 [details]
xorg.conf.d file that fixes the issue
I wont recommend using/keeping the GM204 (GTX 970/980). It cant ever run with free software: https://www.theregister.co.uk/2015/04/15/nvidia_gtx_900_linux_driver_roadbloack/
Sell this crappy GM204 card away and go away from nvidia. Nvidia died with the 780ti card. Its the last end-user card that can be used normaly. Everything else is in some countries even a legal problem. Because the manufacturer (nvidia) blocks the users from beeing able to boot the software they want on THEIR hardware - happyly illegal in some countries. Hopefully some layer would sue the heck out of nvidia so that they would have to release the private signing key or close their doors.
Blocking the freedom of the users on such way should not be accepted by anyone.
(In reply to caguduzexi from comment #2)
> I wont recommend using/keeping the GM204 (GTX 970/980). It cant ever run
> with free software:
> Sell this crappy GM204 card away and go away from nvidia. Nvidia died with
> the 780ti card. Its the last end-user card that can be used normaly.
> Everything else is in some countries even a legal problem. Because the
> manufacturer (nvidia) blocks the users from beeing able to boot the software
> they want on THEIR hardware - happyly illegal in some countries. Hopefully
> some layer would sue the heck out of nvidia so that they would have to
> release the private signing key or close their doors.
> Blocking the freedom of the users on such way should not be accepted by
I'm afraid I will no longer be able to help test or debug this issue due to no longer having the required hardware. I apologise for the inconvenience!
-- 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-nouveau/issues/283.