After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 791879 - Visible screen flashing when opening lid
Visible screen flashing when opening lid
Status: RESOLVED OBSOLETE
Product: mutter
Classification: Core
Component: wayland
unspecified
Other Linux
: Normal normal
: ---
Assigned To: mutter-maint
mutter-maint
Depends on:
Blocks:
 
 
Reported: 2017-12-22 17:21 UTC by Carlos Garnacho
Modified: 2021-07-05 13:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
backends: Avoid reconfiguring outputs on lid open if there is only one (1.01 KB, patch)
2017-12-22 17:22 UTC, Carlos Garnacho
none Details | Review
backends: Compare gpu/crtc/output configurations before applying (11.87 KB, patch)
2018-01-21 19:45 UTC, Carlos Garnacho
none Details | Review

Description Carlos Garnacho 2017-12-22 17:21:50 UTC
For convenience, I have suspend on lid close disabled on this 2-in-1 laptop, so closing the lid is just meant to blank the screen.

However on Wayland the screen visibly turns on, shows the desktop briefly, goes black, and then shows the desktop again. It seems applying the monitor config again on lid open is the culprit of this flashing.

I think that makes sense when there's external outputs as we can end up shuffling the shell, but probably doesn't make as much sense when there's a single output, I'm attaching a patch that avoids reconfiguring the output in that case.
Comment 1 Carlos Garnacho 2017-12-22 17:22:19 UTC
Created attachment 365886 [details] [review]
backends: Avoid reconfiguring outputs on lid open if there is only one

On wayland it causes visible flashing to black as the output is first
turned on, and then reconfigured.
Comment 2 Jonas Ådahl 2017-12-25 06:24:00 UTC
Review of attachment 365886 [details] [review]:

I think that we should rather move "is_assignments_changed()" out of meta-monitor-manager-xrandr.c, so that all configuration changes that doesn't actually change the CRTC assignment wont blink, including scale and position changes.
Comment 3 Carlos Garnacho 2017-12-25 16:51:54 UTC
Oh, so the xrandr paths have code to compare configurations :). Yes, that sounds preferable to my special casing, I'll have a look.
Comment 4 Carlos Garnacho 2018-01-21 19:45:56 UTC
Created attachment 367179 [details] [review]
backends: Compare gpu/crtc/output configurations before applying

Move the configuration checks from the X11 backend into generic code, so
both backends may check the configuration did actually change before
reapplying. This spares us from visible screen flashing when reapplying
monitor configuration eg. after lid open.
Comment 5 Jonas Ådahl 2018-04-09 14:32:43 UTC
Care to turn this into a MR?
Comment 6 Carlos Garnacho 2018-04-09 17:47:38 UTC
I precisely went back to this patch during the weekend :). https://gitlab.gnome.org/GNOME/mutter/merge_requests/72
Comment 7 GNOME Infrastructure Team 2021-07-05 13:47:36 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/mutter/-/issues/

Thank you for your understanding and your help.