GNOME Bugzilla – Bug 771815
Constant screen flickering with 3.21 and 3.22
Last modified: 2020-04-19 17:22:11 UTC
with and without After the upgrade to 3.21 (91 and 92) and later to 3.22 the screen is constantly flickering. I experience the issue on IvyBridge HD4000, but people are reporting that they experience it with Radeon and NVidia propriatery drivers as well. The issue affects gnome classic as well as X11 and wayland modes. The issue is present on both X11 and Wayland. But on X it is so severe that the desktop is basically useless. There is no problem with 3D acceleration and video playback. Playing video with MPV is fine has no flicker. On the Driver side I tried with DRI2, DRI3 and NoAccel. Also with SNA (with and without TearFree) and UXA accel. There was no change in regards to the flickering. More information can be found here: http://forums.debian.net/viewtopic.php?f=6&t=129676 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837786 https://youtu.be/l4kHJmXs9TM
Intel Haswell HD 4400. Same here, tested on debian testing AND GNOME_next-live-CD, so bug is definitely upstream.
(In reply to geha from comment #1) > Intel Haswell HD 4400. Same here, tested on debian testing AND > GNOME_next-live-CD, so bug is definitely upstream. Well i tried tumbleweed today and the flickering is gone...
(In reply to geha from comment #2) > (In reply to geha from comment #1) > > Intel Haswell HD 4400. Same here, tested on debian testing AND > > GNOME_next-live-CD, so bug is definitely upstream. > > Well i tried tumbleweed today and the flickering is gone... Interesting - as the GNOME_Next live CD basically IS a Tumbleweed install - but granted, slimmed down (the video driver selection is likely the cause then: G_Next live basically only comes with the modesetting driver, when you installed Tumbleweed, you likely got the 'native' intel driver). I just changed the meta package for the GNOME_Next live image to also include the -intel video driver - would be nice if you could retest the Live image once a new one is published - if this is then fine for you I'd say you have a good lead for Debian too
What do you mean by the "intel" driver ? If you mean xserver-xorg-video-intel, then why my wayland session is flickering as well (PS: I tried with and without it without any difference)? Also in the debian bug report several people complained about that issue with different video drivers including the proprietary nvidia ones. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837786
(In reply to Dominique Leuenberger from comment #3) > (In reply to geha from comment #2) > > (In reply to geha from comment #1) > > > Intel Haswell HD 4400. Same here, tested on debian testing AND > > > GNOME_next-live-CD, so bug is definitely upstream. > > > > Well i tried tumbleweed today and the flickering is gone... > > Interesting - as the GNOME_Next live CD basically IS a Tumbleweed install - > but granted, slimmed down (the video driver selection is likely the cause > then: G_Next live basically only comes with the modesetting driver, when you > installed Tumbleweed, you likely got the 'native' intel driver). I did not install tumbleweed but used the gnome-live-snapshot (20160921). The G_Next Build1.5 iso seems to be similar. Interesting though that one worked. Btw. i'm on debian/modesetting too, means no explicit intel ddx. > > I just changed the meta package for the GNOME_Next live image to also > include the -intel video driver - would be nice if you could retest the Live > image once a new one is published - if this is then fine for you I'd say you > have a good lead for Debian too
Just tried G_Next Build 1.9 -> screen flickers again.
The tumbleweed gnome-live-snapshot contains xf86-video-intel build around Sept 2nd, while the debian version is approx. 2 months old. Maybe the debian/intel ddx needs to be updated...thanks for the hint.
Does the issue start reproducing in 3.21.91? As in, did it work in 3.21.1 to 3.21.4 and 3.21.90? What version of gobject-introspection is installed on the system where the issue reproduces?
Hard to say as the first unstable version in debian testing was 3.21.91 and the version before that, 3.20, worked like a charm. If you know of live isos for these versions i'd gladly test them. gobject-introspection version: 1.49.1-2. xf86-video-intel or better the lack there of is not the culprit.
As far as I can see[0][1], there were more versions in debian experimental. Any way to test those? [0] https://lists.debian.org/debian-experimental-changes/2016/08/msg00222.html [1] https://lists.debian.org/debian-experimental-changes/2016/08/msg00223.html
(In reply to Jonas Ådahl from comment #10) > As far as I can see[0][1], there were more versions in debian experimental. > Any way to test those? > > [0] > https://lists.debian.org/debian-experimental-changes/2016/08/msg00222.html > [1] > https://lists.debian.org/debian-experimental-changes/2016/08/msg00223.html http://snapshot.debian.org/package/mutter/ http://snapshot.debian.org/package/mutter/3.21.90-1/
(In reply to Andreas Henriksson from comment #11) > (In reply to Jonas Ådahl from comment #10) > > As far as I can see[0][1], there were more versions in debian experimental. > > Any way to test those? > > > > [0] > > https://lists.debian.org/debian-experimental-changes/2016/08/msg00222.html > > [1] > > https://lists.debian.org/debian-experimental-changes/2016/08/msg00223.html > > http://snapshot.debian.org/package/mutter/ > http://snapshot.debian.org/package/mutter/3.21.90-1/ With 3.21.90-1 the flickering is not gone but much better...
Any way to try 3.21.3? FWIW, I've been trying to reproduce on a Debian system, running mutter/gnome-shell from jhbuild (3.22.0), but so far no flickering.
Interesting for me so far is that as stated above the GNOME_Next Build 1.9 which contains mutter 3.22.0-364.2 flickers, while the opensuse-tumbleweed-snapshot (20160921) has mutter 3.22.0-1 and does not.(tested via live-iso-usb) Also the GNOME_Next-iso hangs at boot on VirtualBox while the other one works fine.
(In reply to geha from comment #14) > Interesting for me so far is that as stated above the GNOME_Next Build 1.9 > which contains mutter 3.22.0-364.2 flickers, while the > opensuse-tumbleweed-snapshot (20160921) has mutter 3.22.0-1 and does > not.(tested via live-iso-usb) > Also the GNOME_Next-iso hangs at boot on VirtualBox while the other one > works fine. TW Live snapshot (0921) almost 100% runs an X-session for you - no wayland
Could someone attach a strace log of gnome-shell when it reproduces?
Rather big file, so sent via mail to you...
(In reply to geha from comment #17) > Rather big file, so sent via mail to you... Thanks. Though, it seems it doesn't have any of the open("/path/to/some/library/libthatlibrary.so") calls (which were the one I'm interested in). How did you get the strace? You could probably get it by putting XDG_SESSION_TYPE=x11 strace gnome-shell >& gnome-shell-strace.log in ~/.xinitrc, switching to a VT, then run "startx". It'll be a fairly broken gnome-shell session (various stuff won't work due to the lack of a complete gnome-session), but at least you should be able to try to reproduce the issue.
(In reply to Jonas Ådahl from comment #18) > (In reply to geha from comment #17) > > Rather big file, so sent via mail to you... > > Thanks. Though, it seems it doesn't have any of the > open("/path/to/some/library/libthatlibrary.so") calls (which were the one > I'm interested in). How did you get the strace? Well i'm no developer...started the desktop via gdm, then pgrep gnome-shell and strace -p # -o file.txt > You could probably get it by > putting > > XDG_SESSION_TYPE=x11 strace gnome-shell >& gnome-shell-strace.log Actually it works with "&>" , your command gives bad fd number error > > in ~/.xinitrc, switching to a VT, then run "startx". It'll be a fairly > broken gnome-shell session (various stuff won't work due to the lack of a > complete gnome-session), but at least you should be able to try to reproduce > the issue. Well i even get no X at all: Connection to x-server lost, no further warnings or errors...
Another one with startx /usr/bin/strace /usr/bin/gnome-shell &> file.txt sent... now with some .so calls as far as i can see. hope it helps.
(In reply to geha from comment #20) > Another one with > > startx /usr/bin/strace /usr/bin/gnome-shell &> file.txt > > sent... > > now with some .so calls as far as i can see. hope it helps. Thanks. Things look correct to me, gnome-shell loads libmutter-clutter.so etc and not libclutter.so as it should.
I just tried "GNOME_Next 1.9" on one two computers, one with an Intel GPU, the other with a Nvidia GPU, and I haven't been able to reproduce the issue. What I could see was a slight blurry-ness on the nvidia system when running Wayland on top of nouveau. Changing to using X11, the problem went away. Adding MUTTER_STAGE_VIEWS=0 to /etc/environment also made the problem go away on Wayland on top of nouveau. So, anyone who can reproduce this, does it reproduce both using Wayland and X11, or only X11? Does it reproduce on anything other than nouveau?
As i added MUTTER_STAGE_VIEWS=0 to /etc/environment i noticed the following: CLUTTER_PAINT=disable-clipped-redraws:disable-culling CLUTTER_VBLANK=True (entries already there) MUTTER_STAGE_VIEWS=0 did not help so i removed it. I tried # the first entry and noticed: yeah, the flicker is GONE under X11, but slightly present in GDM and Wayland. # both entries didn't help further. Any clues?
(In reply to geha from comment #23) > As i added MUTTER_STAGE_VIEWS=0 to /etc/environment i noticed the following: > > CLUTTER_PAINT=disable-clipped-redraws:disable-culling > CLUTTER_VBLANK=True > > (entries already there) > > MUTTER_STAGE_VIEWS=0 did not help so i removed it. I tried # the first entry > and noticed: yeah, the flicker is GONE under X11, but slightly present in > GDM and Wayland. > > # both entries didn't help further. > > Any clues? Could you describe "slightly present" and how you reproduce it? This is on an Intel GPU right?
Nothing todo to reproduce, just load GDM or GNOME under Wayland-Session. Intel Haswell HD 4400. It's more of a slight jittering (aka "zittern" in german, don't know if my english translation is appropriate in this context) than a flickering...
Just retested the live-image: It seems to be two different(?) issues: 1.) In GNOME_next build 1.9 theres no flickering but the jittering and the /etc/environment items are not present. 2.) On Debian before #ing the line it looked like this: https://ufile.io/47426 After that its more of a jittering as present in GNOME-next build 1.9, but much less than that.
> So, anyone who can reproduce this, does it reproduce both using Wayland and X11, or only X11? Does it reproduce on anything other than nouveau? Yes, it reproduces under X and Wayland. Under X it is so severe that the desktop is basically unusable. On Wayland the flickering is more tolerable but is still present. I'll try the proposed workarounds after work. > It's more of a slight jittering On my side it looks like a double buffering issue. One moment I see the GDM screen, the next I see my desktop. And it continues undefinitely unless the whole screen is repainted. Then it swaps between the desktop and some other applciation, or if I scroll some page in firefox - at one moment I see the top of the page and in thext - the bottom, then again the top ... etc. PS: I'll also try the live iso to check if it's the same issue there
> Does it reproduce on anything other than nouveau? I can test only with intel video but if you take a look at the debian bug report, then you;ll see people are complaining with NVIdia propriatery drivers as well. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837786
(In reply to geha from comment #25) > Nothing todo to reproduce, just load GDM or GNOME under Wayland-Session. > Intel Haswell HD 4400. It's more of a slight jittering (aka "zittern" in > german, don't know if my english translation is appropriate in this context) > than a flickering... Well i believe i found the culprit for the jittering: monitor-resolution in gnome-control-center doesn't let me apply 1920x1080 (16:9) but stays with 1920x1080i (16:9). In other DEs it works, hence no problems there. Regarding /etc/environment: Seems i got this "cruft" from older versions of debian since it seems not to be default anymore. thanks again for helping figuring me out how to get gnome running again.
@ Jonas Ådahl Thank you for pointing me to the /etc/environment. MUTTER_STAGE_VIEWS=0 indeed improved the situation a lot under X11 but flickering still remained. While adding this property I noticed that I had CLUTTER_PAINT=disable-clipped-redraws:disable-culling there and removing it seems to have fixed the issue. The funny part is that I've added this property years ago as a workaround for gnome tearing, and now the cure has turned to a poison. Thanks, Svetlin
(In reply to Svetlin Zarev from comment #30) > @ Jonas Ådahl > Thank you for pointing me to the /etc/environment. > MUTTER_STAGE_VIEWS=0 indeed improved the situation a lot under X11 but > flickering still remained. While adding this property I noticed that I had > CLUTTER_PAINT=disable-clipped-redraws:disable-culling there and removing it > seems to have fixed the issue. Changing MUTTER_STAGE_VIEWS only affects the Wayland session (X11 only supports what value "0" represents, while Wayland supports both but defaults to what value "1" represents. > > The funny part is that I've added this property years ago as a workaround > for gnome tearing, and now the cure has turned to a poison. Right. Reopening as disabling clipped redraws and culling shouldn't break rendering like it seems to be doing.
(In reply to Jonas Ådahl from comment #31) > (In reply to Svetlin Zarev from comment #30) > > @ Jonas Ådahl > > Thank you for pointing me to the /etc/environment. > > MUTTER_STAGE_VIEWS=0 indeed improved the situation a lot under X11 but > > flickering still remained. While adding this property I noticed that I had > > CLUTTER_PAINT=disable-clipped-redraws:disable-culling there and removing it > > seems to have fixed the issue. > > Changing MUTTER_STAGE_VIEWS only affects the Wayland session (X11 only > supports what value "0" represents, while Wayland supports both but defaults > to what value "1" represents. > > > > > The funny part is that I've added this property years ago as a workaround > > for gnome tearing, and now the cure has turned to a poison. > > Right. Reopening as disabling clipped redraws and culling shouldn't break > rendering like it seems to be doing. Unless this can be fixed in mutter, maybe it could just ignore disable-clipped-redraws:disable-culling?
I always enable the CLUTTER_PAINT hack when using DRI2 because this is the only way to get a real tear free experience. Without the hack, there is some tearing at the very top of the screen unless DRI3 is enabled. Usually hard to notice until you open a fullscreen app such as Firefox or VLC. Another way to visualize the tearing is to open Activities and drag a window thumbnail to the top of the screen. That's both on intel and radeonsi drivers. Please fix.
*** Bug 774882 has been marked as a duplicate of this bug. ***
This task has not been updated for more than 7 months. Is this still a problem in latest 3.24?
Is this still a problem in latest 3.34?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!