Bug 1379959

Summary: [Wayland] Gnome-shell video output is blurry and flickering
Product: [Fedora] Fedora Reporter: Christian Stadelmann <fedora>
Component: gnome-shellAssignee: Owen Taylor <otaylor>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 26CC: fmuellner, ofourdan, otaylor
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-05-21 19:29:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1277927    
Attachments:
Description Flags
xrandr output on a gnome session
none
xrandr from a working (not blurry, flickering) wayland session none

Description Christian Stadelmann 2016-09-28 08:56:01 UTC
Created attachment 1205437 [details]
xrandr output on a gnome session

Description of problem:
Since upgrading to F25, both Gdm (with wayland) and GNOME session (with wayland) are blurry and have a flickering screen.

Version-Release number of selected component (if applicable):
xorg-x11-server-Xorg-1.18.4-5.fc25.x86_64
gnome-shell-3.22.0-1.fc25.x86_64
gnome-session-3.22.0-1.fc25.x86_64
gtk3-3.22.0-1.fc25.x86_64
mutter-3.22.0-1.fc25.x86_64
clutter-1.26.0-1.fc25.x86_64
libwayland-client-1.12.0-1.fc25.x86_64
mesa-*-12.0.3-1.fc25.x86_64
kernel-4.8.0-0.rc7.git0.1.fc25.x86_64

How reproducible:
I don't know.

Steps to Reproduce:
* boot to gdm (running with wayland backend) → gdm is blurry and flickering
* log in to gnome session (with wayland backend) → all video output is blurry and flickering
* log in to gnome X11 session → everything is fine
* switch to tty: everything is fine

Additional info:
This is a regression from F24, where the exact same hardware setup and software configuration worked fine on wayland.

This is on a desktop machine, so there is no ambient light sensor (bug #1282075).

This is probably not a duplicate of bug #1266484 (see its comments 61 and 62).

My guess is that gnome@wayland is unable to determine the correct monitor refresh rate.

The flickering and blurness I experience looks like when you had your monitor connected with an analog video (VGA) cable with bad quality. But this is monitor is only connected through a HDMI cable.

On Gnome session my monitor reports it is running at 1920x1080 px with 1080p @ 60Hz

The GPU is an Intel HD graphics from first Gen. Core i5 CPUs.

I'll add some screenshots from wayland session too.

Comment 1 Christian Stadelmann 2016-09-28 09:25:44 UTC
Created attachment 1205444 [details]
xrandr from a working (not blurry, flickering) wayland session

Ok, here is what makes this more weird:
On a fresh user profile on the same machine, this issue is not present on gnome/wayland sessions. Instead gnome-control-center doesn't let me set the resolution (defaults to 1920x1080i) to 1920x1080 (aka. 1920x1080p). But on this fresh user, there is no blur and no flickering. There also are just 2 frequencies to choose from: "60 Hz (NTSC)" and "50 Hz". When I opened gnome-control-center for the first time on F25 on this user, it also showed "60 Hz" but after switching to something else, the "60 Hz" entry is gone.


On an "old" user profile, this issue is present on gnome/wayland sessions. In this case xrandr is pretty short and obviously broken:
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
XWAYLAND0 connected 1920x1080+0+0 530mm x 300mm
   1920x1080     59.96*+
gnome-control-center lets me choose 1920x1080 (default, correct) and 1920x1080i (alternatively). Furthermore it shows 3 refresh rates: "60 Hz" (twice) and "50 Hz". No matter which of the "60 Hz" items I select, I cannot press the apply button.
If I choose 1920x1080i and press apply, the screen goes back to 1920x1080 (not i).
If I choose a smaller resolution (1600x900 or 1680x1050) and change my monitor settings not to scale the screen but to put a wide border around it, everything is fine, no blurs, no flickering.
I also disabled all gnome-shell-extensions to make sure they are not to blame, and they aren't. It's also not about animations, which can be enabled or disabled.

Comment 2 Christian Stadelmann 2016-09-28 09:32:10 UTC
On the "old" user profile:
When switching the resolution from 1680x1050 (or any other correctly working resolution) to 1920x1080, there is no logging from anything in journal. No kernel, no gnome-shell, nothing.

When running at 1680x1050, xrandr shows the screen resolution is still broken:
$ xrandr
Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 8192 x 8192
XWAYLAND0 connected 1680x1050+0+0 530mm x 300mm
   1680x1050     59.95*+

Comment 3 Christian Stadelmann 2016-09-28 09:36:41 UTC
(In reply to Christian Stadelmann from comment #1)
> Created attachment 1205444 [details]
> xrandr from a working (not blurry, flickering) wayland session
> 
> Ok, here is what makes this more weird:
> On a fresh user profile on the same machine, this issue is not present on
> gnome/wayland sessions. Instead gnome-control-center doesn't let me set the
> resolution (defaults to 1920x1080i) to 1920x1080 (aka. 1920x1080p). But on
> this fresh user, there is no blur and no flickering. There also are just 2
> frequencies to choose from: "60 Hz (NTSC)" and "50 Hz". When I opened
> gnome-control-center for the first time on F25 on this user, it also showed
> "60 Hz" but after switching to something else, the "60 Hz" entry is gone.

I was actually wrong on this. This was an X11 session. So please ignore everything I wrote above about the fresh user profile. Sorry for the noise.

Comment 4 Olivier Fourdan 2016-09-28 14:36:36 UTC
On Wayland, the wl_output sections from weston-info will give more accurate info than xrandr (which is an X tool, thus just emulated in Wayland).

Is it a new issue after upgrading to mutter 3.22? I wonder if this could have anything to do with bug 1374600 (which added some more common display resolutions even if not listed in the kms interface)

Comment 5 Christian Stadelmann 2016-09-28 14:49:45 UTC
(In reply to Olivier Fourdan from comment #4)
> On Wayland, the wl_output sections from weston-info will give more accurate
> info than xrandr (which is an X tool, thus just emulated in Wayland).

Cool, I didn't know that tool.


From 1680x1050px resolution (no blurs, no flicker):

interface: 'wl_drm', version: 2, name: 1
interface: 'wl_compositor', version: 3, name: 2
interface: 'wl_shm', version: 1, name: 3
        formats: XRGB8888 ARGB8888
interface: 'wl_output', version: 2, name: 4
        x: 0, y: 0, scale: 1,
        physical_width: 530 mm, physical_height: 300 mm,
        make: 'BNQ', model: 'BenQ RL2450H',
        subpixel_orientation: unknown, output_transform: normal,
        mode:
                width: 1680 px, height: 1050 px, refresh: 60.000 Hz,
                flags: current
interface: 'wl_data_device_manager', version: 3, name: 5
interface: 'gtk_primary_selection_device_manager', version: 1, name: 6
interface: 'zxdg_shell_v6', version: 1, name: 7
interface: 'wl_shell', version: 1, name: 8
interface: 'gtk_shell1', version: 1, name: 9
interface: 'wl_subcompositor', version: 1, name: 10
interface: 'zwp_pointer_gestures_v1', version: 1, name: 11
interface: 'zwp_tablet_manager_v2', version: 1, name: 12
interface: 'wl_seat', version: 5, name: 13
        name: seat0
        capabilities: pointer keyboard
        keyboard repeat rate: 33
        keyboard repeat delay: 500
interface: 'zwp_relative_pointer_manager_v1', version: 1, name: 14
interface: 'zwp_pointer_constraints_v1', version: 1, name: 15
interface: 'zxdg_exporter_v1', version: 1, name: 16
interface: 'zxdg_importer_v1', version: 1, name: 17

From 1920x1080 resolution (same monitor, but with blurs and flickers):
interface: 'wl_drm', version: 2, name: 1
interface: 'wl_compositor', version: 3, name: 2
interface: 'wl_shm', version: 1, name: 3
        formats: XRGB8888 ARGB8888
interface: 'wl_output', version: 2, name: 4
        x: 0, y: 0, scale: 1,
        physical_width: 530 mm, physical_height: 300 mm,
        make: 'BNQ', model: 'BenQ RL2450H',
        subpixel_orientation: unknown, output_transform: normal,
        mode:
                width: 1920 px, height: 1080 px, refresh: 60.000 Hz,
                flags: current
interface: 'wl_data_device_manager', version: 3, name: 5
interface: 'gtk_primary_selection_device_manager', version: 1, name: 6
interface: 'zxdg_shell_v6', version: 1, name: 7
interface: 'wl_shell', version: 1, name: 8
interface: 'gtk_shell1', version: 1, name: 9
interface: 'wl_subcompositor', version: 1, name: 10
interface: 'zwp_pointer_gestures_v1', version: 1, name: 11
interface: 'zwp_tablet_manager_v2', version: 1, name: 12
interface: 'wl_seat', version: 5, name: 13
        name: seat0
        capabilities: pointer keyboard
        keyboard repeat rate: 33
        keyboard repeat delay: 500
interface: 'zwp_relative_pointer_manager_v1', version: 1, name: 14
interface: 'zwp_pointer_constraints_v1', version: 1, name: 15
interface: 'zxdg_exporter_v1', version: 1, name: 16
interface: 'zxdg_importer_v1', version: 1, name: 17

So both just differ by line 11 specifying the resolution and refresh rate.

> Is it a new issue after upgrading to mutter 3.22? I wonder if this could
> have anything to do with bug 1374600 (which added some more common display
> resolutions even if not listed in the kms interface)

This happened after dnf system-upgrade from a fully updated F24 to F25. This included an update of mutter to 3.22. I'll try to downgrade mutter to 3.21.91 and 3.21.92 and report back. 3.21.92 should have the patch for this bug applied and thus show the same behavior. 3.21.91 should work fine because it doesn't have the patch.

Comment 6 Christian Stadelmann 2016-09-28 15:07:08 UTC
(In reply to Christian Stadelmann from comment #5)
> I'll try to downgrade mutter to 3.21.91 and 3.21.92 and report back. 3.21.92 should have the patch for this bug applied and thus show the same behavior. 3.21.91 should work fine because it doesn't have the patch.

Ok, I can't do that because those packages are not in repos any more and they have a hell lot of dependencies that need to be downgraded togehther with them.

Comment 7 Christian Stadelmann 2016-09-28 15:27:22 UTC
From commit https://git.gnome.org/browse/mutter/commit/?id=9a07607 referenced in the bug you mentioned, I found this:

+#define SYNC_TOLERANCE 0.01 /* 1 percent */

and I noticed that I have three different frequencies within 1% difference:
59.94 Hz (see first xrandr output, that's what my monitor runs with on a Gnome+X11 session), this is a NTSC screen refresh rate, 60Hz/1.001
59.95 Hz (see xrandr output on a Gnome+Wayland session), this is probably just a result of incorrectly rounding 60/1.001.
60.00 Hz (see weston-info output and gnome-control-center display), another common screen refresh rate.

So those actually are two different frequencies which must not be handled as one. So how about changing the SYNC_TOLERANCE to something way lower, e.g

+#define SYNC_TOLERANCE 0.0005 /* 0.05 percent */

Maybe I'm just unlucky to have a monitor which supports 60Hz/1.001 aka "59.94 Hz", but not 60Hz itself. Looks like a bug in my monitor if the xrandr output was correct.

Comment 8 Christian Stadelmann 2016-10-06 10:17:44 UTC
I added an upstream patch but I have troubles testing my own build. Can you please help me doing this?

https://bugzilla.gnome.org/show_bug.cgi?id=772504

Comment 9 Christian Stadelmann 2016-10-22 21:44:53 UTC
This bug seems partially fixed now after some recent update.

I can now choose the non-interleaved 1920x1080 resolution and it works fine.

The interleaved 1920x1080i resolution is still blurry.


Software versions:
xorg-x11-server-Xorg-1.19.0-0.2.20160929.fc25.x86_64
gnome-shell-3.22.1-1.fc25.x86_64
gtk3-3.22.1-2.fc25.x86_64
mutter-3.22.1-4.fc25.x86_64
clutter-1.26.0-1.fc25.x86_64
libwayland-client-1.12.0-1.fc25.x86_64
mesa-dri-drivers-12.0.3-2.fc25.x86_64
kernel-4.8.3-300.fc25.x86_64

Comment 10 Fedora End Of Life 2017-11-16 19:41:31 UTC
This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 11 Christian Stadelmann 2017-11-16 20:01:43 UTC
Still present.

Comment 12 Fedora End Of Life 2018-05-03 08:27:24 UTC
This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '26'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 13 Christian Stadelmann 2018-05-21 19:29:23 UTC
This issue has been fixed upstream and is not present on Fedora 28 any more.