Bug 111618 - [Bisected]. [Regression]. Wayland. Chromium. Opening on full-screen mode videos lead to flickering white/black squads
Summary: [Bisected]. [Regression]. Wayland. Chromium. Opening on full-screen mode vide...
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: Other All
: not set not set
Assignee: Intel 3D Bugs Mailing List
QA Contact: Intel 3D Bugs Mailing List
Depends on:
Reported: 2019-09-09 14:09 UTC by Denis
Modified: 2019-09-25 20:35 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

video_with_bug (6.05 MB, video/mp4)
2019-09-09 14:09 UTC, Denis

Description Denis 2019-09-09 14:09:32 UTC
Created attachment 145309 [details]

Hello. During using Chromium on wayland I faced with an issue - huge white/black squads flickering over the screen, in case if I opened video into full-screen mode.

OS: Manjaro
Linux den-pc 5.2.11-1-MANJARO
Xorg-server 1.20.5-2 (Xwayland and all related packs the same version)
Chromium (chromium)  76.0.3809.132-1 (tested and on downgraded version)
Mesa versions - git-master, 19.1.5 (system) etc...

1. Login into wayland session
2. Launch chromium
3. Open chromium into full-screen mode (it is important, because in other way bug can't be reproduced)
4. Launch any youtube video
5. Open video in a full-screen mode
Result: picture starts flickering with white-black squads. Video attached.

I searched for same/similar issues and could find only these, quite old and resolved mostly:

Second thing - is that running with "--disable-gpu-driver-bug-workarounds" - resolves issue.

Bisection lead me to:

069fdd5f9facbd72fb6a289696c7b74e3237e70f is the first bad commit
commit 069fdd5f9facbd72fb6a289696c7b74e3237e70f
Author: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Date:   Fri Jul 7 02:54:26 2017 -0400

    egl/x11: Support DRI3 v1.1

Issue doesn't exist on Xorg session. Possibly (as in found tickets) it may be related to regression in Xwayland, but I am not sure in this.
Comment 1 Lionel Landwerlin 2019-09-09 14:19:49 UTC
That is usually a desynchronization between the compositor and the client (chromium) of state of the compression of the surface.

One is rendering compressed, the other reading uncompressed. We recently pointed mutter/gnome-shell to avoid reading the texture of a shared surface from the CPU (glReadPixels, etc...) because it would trigger that.

We should probably fix the driver, but this is somewhat of a rewrite of how we deal with aux surfaces.
Comment 2 GitLab Migration User 2019-09-25 20:35:37 UTC
-- 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/mesa/mesa/issues/1833.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.