GNOME Bugzilla – Bug 740377
Mutter starts with a black background disrupting transition into gnome-shell
Last modified: 2021-07-05 13:45:35 UTC
Mutter starts a new user session with a black screen before the desktop appears. Though this is not a mode change "flicker", the appearance of a black screen while starting the user's desktop is not aesthetically pleasing. based on an IRC conversation: 1) reference earlier commit: https://git.gnome.org/browse/mutter/commit/src?id=ec8ed1dbb04ce8169c0a38ddf066d5565117c587 2) A proper fix may have to take future changes, intel driver bugs (intel SNA) and CSD window behaviour (when the root window is not black) into consideration. I can confirm that reverting the commit mentioned above removes the black screen.
Created attachment 291037 [details] [review] background: set root background from ui not core In a future commit we're going to set the root background to noise texture, so this commit moves background setting out of core to ui where we can use cairo etc.
Created attachment 291038 [details] [review] ui: add meta_gdk_pixbuf_put_to_pixmap next to existing meta_gdk_pixbuf_get_from_pixmap In a future commit we're going to set the noise texture on the root window. In order to do this, we need a function to turn a pixbuf into a pixmap. This commit adds that function.
Created attachment 291039 [details] [review] Add gresource boilerplate In a future commit we're going to set the noise texture on the root window. This means we'll need to ship the noise texture in-tree, and either ship it in a new directory called /usr/share/mutter or build it into the binary. This commit lays the infrastructure in place for the latter option, by adding the Makefile goo needed to add resources to the binary.
Created attachment 291040 [details] [review] ui: set root background to noise texture By setting the root background to black we create flicker at login time (when the login screen exits, we briefly show the root window before the user session starts). By showing the noise texture instead we get rid of this flicker and provide consistency with the login screen.
a few thoughts for future improvements... 1) we could probably load the noise texture asynchronously, and prevent blocking startup on this. 2) it would be good if we could somehow share the pixbuf with gnome-shell since gnome-shell uses the same texture (although gnome-shell uses an alpha version of it). 3) i'm not 100% sold on this going in ui.c since it's X specific and ui.c is used by wayland too, but there's precedent already that should get fixed at the same time probably, and the only place where there's a wayland/x11 split (the backends) doesn't use gdk/cairo/etc
Can you add a Meta.set_root_window_pixbuf we use from gnome-shell?
Currently I can change the gdm background by replacing the noise texture or modifying the css in the gnome-shell theme. So if it becomes a compiled-in resource for mutter, will the theme and mutter resource go out of sync? It will be just as bad as the blackness in this scenario. I hope there will still be a method better than recompiling to keep grub, plymouth, gdm, mutter and desktop wallpaper in sync.
Jasper, Yea, doing this from gnome-shell probably makes more sense. Not sure what the best API would look like, but we could set it on the root window when SystemBackground is first instantiated. It's tempting to add the feature to Meta.Background directly, like say... --- a/js/ui/background.js +++ b/js/ui/background.js @@ -466,5 +466,6 @@ const SystemBackground = new Lang.Class({ if (_systemBackground == null) { - _systemBackground = new Meta.Background({ meta_screen: global.screen }); + _systemBackground = new Meta.Background({ meta_screen: global.screen, + sync_to_root_window: true }); but it may not be a great fit, just because implementing it at that level would balloon the implementation of MetaBackground with a bunch of code that's not used (unless we left sync_to_root_window broken for the unused cases). Meta.set_root_window_pixbuf is ugly but it might be the best way to go. Alternatively, we could cut mutter out of the loop entirely and just add the function to shell-global or shell-util or something. Not sure... Regardless, if we're going to thread this through gnome-shell we should revert the mutter patch that caused the flicker now, for a quick win.
Gokul, there's a discussion about making the login screen background configurable on bug 738260
Do we really want things set up so that going from GDM to any desktop other than GNOME will end up with a flash of the GNOME root weave? It seems to me that in greeter mode, we really *do* want background None, and the problem with frozen images of windows doesn't apply there at all. And we don't need BackgroundNone in a normal session - as soon as you have windows, if you want to prevent a confusing flash, you have to keep the COW up. So maybe hardcoding the root weave as the background is a dead end and we just need a hook for the greeter session to set the background to None?
There's two conflicting issues: 1) When doing debugging or development, background none is really confusing and frustrating as you see a trail of stale window contents. 2) We want to preserve root window contents at transition times. Then the third unfortunate issue: SNA has a bug where it will show a random old framebuffer instead of the proper root window, causing it to show the Plymouth splash screen or a stale lock screen instead of your session. Getting bugs fixed in SNA is impossible, so either we work around it or we just tell people to stop using SNA.
Hi, > Do we really want things set up so that going from GDM to any desktop other > than GNOME will end up with a flash of the GNOME root weave? Well, I wouldn't characterize the noise texture as the "GNOME root weave". I'd characterize it as the "system background". i.e., what the system shows when it's not showing anything else. And yea, I think we should show it in transitions, but no there isn't a flash... the whole point is to prevent flashes. the login screen fades to the noise texture before logging the user in. Right now there's a flash because of the black root, or if you revert the black root change there's a flash in some cases because of some driver bug (or something). > It seems to me that in greeter mode, we really *do* want background None, and > the problem with frozen images of windows doesn't apply there at all. I don't think it matters. the end result is visually the same either way. The only difference is what happens in exceptional cases where things don't fade out right or whatever. > And we don't need BackgroundNone in a normal session - as soon as you have > windows, if you want to prevent a confusing flash, you have to keep the COW up. right, which we do since bug 733026 > So maybe hardcoding the root weave as the background is a dead end and we just > need a hook for the greeter session to set the background to None? Again it's not a root weave :-) and it's visually identical to setting Background None except in exceptional cases. In the exceptional cases, though, it gives visually better results. I think the original patch set is probably a dead-end because it's not "right" for non-gnome-shell users of mutter, but getting something into gnome-shell seems right to me.
oh i also wanted to say, that if we decide background None is the right way to go, I don't think we need any hook. We start the X server with -background None already, which makes the root window backpixmap none as a side-effect, so we don't have to perform any explicit action. Furthermore, since we keep the COW mapped since bug 733026 i don't think it matters what the root background is in the user session, so leaving it background None is fine (and incidentally, we definitely have no need for the commit mentioned in comment 0 now so I'll revert it)
Created attachment 291122 [details] [review] Revert "screen: Set a black background for testing purposes" This reverts commit ec8ed1dbb04ce8169c0a38ddf066d5565117c587. 1) It turns out to add a momentary flicker from the transition between the login screen and user session 2) It actually isn't needed anymore since bug 733026
Review of attachment 291122 [details] [review]: (already reached agreement yesterday on irc that we could revert this so marking a-c-n)
pushed as commit 7ecde19a...
Can we expect this fix in 3.14 branch as well? [ ref: https://git.gnome.org/browse/mutter/commit/?id=7ecde19aeebd84515862a8719ff6ec6e42099ca8 ] Should this bug be closed? I also don't know who should do that.
(In reply to comment #17) > Can we expect this fix in 3.14 branch as well? sure. 2e7b9e0..6d3e642 gnome-3-14 -> gnome-3-14 > Should this bug be closed? I also don't know who should do that. Well, unless Owen has a strong objection to setting the pixmap explicitly (after reading comment 12), I think we should keep the bug open until we land a patch to that end, since it will make things more robust in the face of driver bugs and potential shell bugs etc.
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.