Recent gnome-flashback clears the background on login

[Alkis Georgopoulos]

When logging in from lightdm or any other DM, in previous gnome-session-flashback versions we were seeing the lightdm background and then immediately the session background, now a solid gray background appears for 0.5 - 5 seconds (depending on the client speed) between those two.

I.e. there's some new code that "clears the screen" that needs to be removed.

I mentioned this issue in the gnome-flashback mailing list and Alberts asked me:

> On 23/12/2015 07:37 μμ, Alberts Muktupāvels wrote:
>
> Does it happens only with compositing manager enabled?

I replied:

> On 23/12/2015 07:45 μμ, Alkis Georgopoulos wrote:
>
> In gnome-flashback-metacity, it lasts for half a second, and it's a
> solid gray #808080 (I managed to get a screenshot of it).
>
> In gnome-flashback-compiz, it lasts for 0.1 second so at first I was
> thinking it didn't happen there. It's solid white there though, not gray.

[Alkis Georgopoulos (alkisg)]

Here's one method to reproduce it and get a shell at exactly the point where the gray background is drawn:

sudo echo '#!/bin/sh

xterm
exec /usr/bin/gnome-panel "$@"' > /usr/local/bin/gnome-panel

sudo chmod +x /usr/local/bin/gnome-panel

Once that wrapper is created, try to login. You'll get an xterm at a gray background.
If you exit the xterm, the login process continues and the gray background is replaced with the user's wallpaper.

[Alkis Georgopoulos (alkisg)]

I think that gray background is caused by metacity.
If at that point I kill metacity, I get the lightdm wallpaper back.
If I run metacity again at that point, I get the user wallpaper properly drawn (that's a different wallpaper than the one used by lightdm).

Maybe a race condition between metacity and whatever service provides the user wallpaper setting?

[Alkis Georgopoulos (alkisg)]

Two more tests.

1) I created an /usr/share/xsessions/xterm session that just ran xterm.
At that xterm, I ran metacity. It cleared the wallpaper. I don't think it should have cleared it at that point.
I killed metacity and the wallpaper was restored.

2) I created a /usr/local/bin/metacity wrapper, with the following contents:

#!/bin/sh
exec metacity --no-composite "$@"

With this wrapper the problem was completely solved, i.e. the background was never cleared during the login process.

So maybe the problem is that metacity by default does compositing, and that it initializes its "wallpaper" with a gray color instead of reading the root window contents?

[Alberts Muktupāvels (muktupavels)]

https://git.gnome.org/browse/metacity/tree/src/compositor/compositor-xrender.c#n803

It does read root window content...

[Alberts Muktupāvels (muktupavels)]

Can you post output of xprop -root when you see grey background?

[Alkis Georgopoulos (alkisg)]

Hi Alberts, sure, here it is:

_NET_WORKAREA(CARDINAL) = 0, 0, 1024, 768, 0, 0, 1024, 768, 0, 0, 1024, 768, 0, 0, 1024, 768
_NET_CLIENT_LIST_STACKING(WINDOW): window id #
_NET_CLIENT_LIST(WINDOW): window id #
_NET_DESKTOP_NAMES(UTF8_STRING) = "Χώρος εργασίας 1", "Χώρος εργασίας 2", "Χώρος εργασίας 3", "Χώρος εργασίας 4"
_NET_NUMBER_OF_DESKTOPS(CARDINAL) = 4
_NET_CURRENT_DESKTOP(CARDINAL) = 0
_NET_DESKTOP_GEOMETRY(CARDINAL) = 1024, 768
_NET_DESKTOP_VIEWPORT(CARDINAL) = 0, 0
_NET_SUPPORTING_WM_CHECK(WINDOW): window id # 0xe00002
_NET_SUPPORTED(ATOM) = _NET_WM_NAME, _NET_CLOSE_WINDOW, _NET_WM_STATE, _NET_WM_STATE_SHADED, _NET_WM_STATE_MAXIMIZED_HORZ, _NET_WM_STATE_MAXIMIZED_VERT, _NET_WM_DESKTOP, _NET_NUMBER_OF_DESKTOPS, _NET_CURRENT_DESKTOP, _NET_WM_WINDOW_TYPE, _NET_WM_WINDOW_TYPE_DESKTOP, _NET_WM_WINDOW_TYPE_DOCK, _NET_WM_WINDOW_TYPE_TOOLBAR, _NET_WM_WINDOW_TYPE_MENU, _NET_WM_WINDOW_TYPE_DIALOG, _NET_WM_WINDOW_TYPE_NORMAL, _NET_WM_STATE_MODAL, _NET_CLIENT_LIST, _NET_CLIENT_LIST_STACKING, _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_SKIP_PAGER, _NET_WM_ICON_NAME, _NET_WM_ICON, _NET_WM_ICON_GEOMETRY, _NET_WM_MOVERESIZE, _NET_ACTIVE_WINDOW, _NET_WM_STRUT, _NET_WM_STATE_HIDDEN, _NET_WM_WINDOW_TYPE_UTILITY, _NET_WM_WINDOW_TYPE_SPLASH, _NET_WM_STATE_FULLSCREEN, _NET_WM_PING, _NET_WM_PID, _NET_WORKAREA, _NET_SHOWING_DESKTOP, _NET_DESKTOP_LAYOUT, _NET_DESKTOP_NAMES, _NET_WM_ALLOWED_ACTIONS, _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_STICK, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE, _NET_WM_STATE_ABOVE, _NET_WM_STATE_BELOW, _NET_STARTUP_ID, _NET_WM_STRUT_PARTIAL, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MINIMIZE, _NET_FRAME_EXTENTS, _NET_REQUEST_FRAME_EXTENTS, _NET_WM_USER_TIME, _NET_WM_STATE_DEMANDS_ATTENTION, _NET_MOVERESIZE_WINDOW, _NET_DESKTOP_GEOMETRY, _NET_DESKTOP_VIEWPORT, _NET_WM_USER_TIME_WINDOW, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW, _NET_WM_STATE_STICKY, _NET_WM_FULLSCREEN_MONITORS, _NET_WM_STATE_FOCUSED, _NET_RESTACK_WINDOW, _GTK_FRAME_EXTENTS
WM_ICON_SIZE(CARDINAL):
  minimum icon size: 32 by 32
  maximum icon size: 32 by 32
  incremental size change: 0 by 0
PULSE_COOKIE(STRING) = "f8f69c88d0848a4eaf4595686282aad2d066c8c709b8f6341be6568ea8a33fb3495fd925bb0f758f54951cd80ecfa20e5082a4b149e81f3655e9f4c64379720757d65df65128de60a513abd65f11e2da7f97d810162c76c20bb173278901332a02f680877c483dc6b54fb8aba9453a70b9274d17a259f530e498a331dcefe03b16f3c377c754f9b934ea6a5c8592982a125916d2b3d12edd4b0c4bae0a35aa529bbbbaf0ba0200c2f9b52ceeed912c904d6aeaaed518816357cc8c413d31532780be160512e525c9cf98a7d151be48345fd2ec0450f8d4eed8713aa4f1e9dd848710c12982309ecd6e2a9ebda2e59c2fff5153e2993706355e33700f3c8ae2b7"
PULSE_SERVER(STRING) = "{7e05a8fd78f74981ac2aaa2886d508ab}unix:/run/user/1000/pulse/native"
PULSE_SESSION_ID(STRING) = "c2"
PULSE_ID(STRING) = "1000@7e05a8fd78f74981ac2aaa2886d508ab/1586"
AT_SPI_BUS(STRING) = "unix:abstract=/tmp/dbus-LO4EVFhAJ0,guid=b3c52547ba53094c6bc3003d570103c1"
RESOURCE_MANAGER(STRING) = "*customization:\t-color\nXcursor.size:\t24\nXcursor.theme:\tDMZ-White\nXft.antialias:\t1\nXft.dpi:\t96\nXft.hinting:\t1\nXft.hintstyle:\th...

[Alberts Muktupāvels (muktupavels)]

That is because there is no root pixmap set... GNOME-Flashback sets it, but it is started after metacity. Right now I am not sure if this is bug with our session or display manager.

- Can you test with lightdm-gtk-greeter?
- What background you have - image or solid color?

[Alkis Georgopoulos (alkisg)]

Testing with lightdm-gtk-greeter, I do get the expected xprops:
ESETROOT_PMAP_ID(PIXMAP): pixmap id # 0xe00001
_XROOTPMAP_ID(PIXMAP): pixmap id # 0xe00001

And it works fine, i.e. no grey background there.

I'm testing with the default background, i.e.
$ gsettings get org.gnome.desktop.background picture-uri
'file:///usr/share/backgrounds/warty-final-ubuntu.png'

Metacity is drawing a solid grey #808080.

The code about the xprops landed in lightdm-gtk-greeter in:
http://bazaar.launchpad.net/~lightdm-gtk-greeter-team/lightdm-gtk-greeter/trunk/revision/151

Lightdm doesn't have such code. I don't know if it's obligatory to have code for those xprops or not.

Thank you Alberts!

[Alkis Georgopoulos (alkisg)]

I was able to reproduce it:
*) In flashback 12.04, by setting /apps/metacity/general/compositing_manager=true. The default was false, that's why we never saw the problem there.
*) In flashback 14.04, by setting org.gnome.metacity compositing-manager=true. The default was false, that's why we never saw the problem there.
*) In mate 16.04, by installing unity-greeter. The default is lightdm-gtk-greeter, that's why the problem doesn't appear there normally.

I was not able to reproduce it with compiz no matter how much I tried. I even tried killing `nautilus -n` and resetting the xprops, and while at that point `metacity --replace` was drawing a grey background, `compiz --replace` was drawing the background just fine.

So, maybe we can just set compositing-manager=false as it was in the past,
or we could check how compiz does it when those xprops aren't present...

[Dmitry Shachnev (mitya57)]

From all points of view, having the gray screen for one second is a minor issue, and it's definitely doesn't make sense to disable compositing manager just to get it fixed…

[Alberts Muktupāvels (muktupavels)]

Did not you say that this is also problem in compiz? Anyway thanks to code in compiz seems I have fix for grey background...

[Alberts Muktupāvels (muktupavels)]

This is patch that I plan to push to master and gnome-3-18 branches. Can you test it before I do it?

[Alkis Georgopoulos (alkisg)]

@Dmitry, I don't know why compositing-manager was changed from false to true, so I didn't know if it was important to revert it or not. I thought that people that want a compositing manager use compiz, but since metacity is implementing it with xrender instead of opengl, maybe it will work fine with older clients as well.
In the past I tested with xcompmgr and it did have some issues so we avoided using it as the default; using more RAM which was important with low-RAM clients, breaking vsync with full screen apps etc. Now that I know that metacity will be using compositing in 16.04, I'll test with and without it and if I find any notable issues with it I'll mention it in some other bug report.

@Alberts,
> Did not you say that this is also problem in compiz?
I did mention that I saw a white background for 0.1 seconds, sorry for that. Maybe it was caused by some bug in the blending effect between the lightdm/user background, dunno... The gnome-panel wrapper trick was a nice breakpoint that cleared things up.

About the patch, I tested it and it works fine here:
apt source metacity
apt build-dep metacity
patch compositor-xrender.c < 0001-compositor-try-to-user-root-window-background.patch
debuild -b -tc
dpkg -i libmetacity*.deb metacity*.deb metacity-common*.deb
-> create gnome-panel wrapper
service lightdm restart

Thank you very much guys, you're great! :)

[Alberts Muktupāvels (muktupavels)]

Thanks for testing - fixed upstream! :)

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "compositor: try to use root window background" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]