Improve "login greeter -> desktop" transition in Xubuntu

[Thaddaeus Tintenfisch]

If the built-in compositor is enabled, xfwm4 will draw a plain grey background over the lightdm greeter background on session login. As soon as xfdesktop starts the initial background image gets restored. This transition should be improved to eliminate the visual flicker during the session login.

$ xfwm4 --version
This is xfwm4 version 4.10.1 (revision 3918e6b) for Xfce 4.10

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount)]

Here is one possible solution:

xfwm4 needs to be build with MONITOR_ROOT_PIXMAP defined [1]. The built-in compositor will now try to clone the current root background on launch and fall back to the default plain grey background if it fails.
LightDM GTK+ Greeter already makes sure that the background picture will remain even after the greeter quits, but it does not set the necessary property for the root window [2].

I am not aware of any drawbacks. However, some testing needs to be done.

[1] http://git.xfce.org/xfce/xfwm4/tree/src/compositor.c#n806
[2] http://git.xfce.org/xfce/xfwm4/tree/src/compositor.c#n840

[Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount)]

If xfwm4 and xfdesktop start at the same time (within a small timeframe), xfdesktop will quit with following error:

The program 'xfdesktop' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
  (Details: serial 197 error_code 9 request_code 72 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

[Alistair Buxton (a-j-buxton)]

So after massive amounts of investigation this is what I came up with:

1. lightdm-gtk-greeter uses RetainPermanent pixmaps to set the background. What this means is that it opens a second connection to the X server, allocates the pixmap as RetainPermanent, pushes it into the root window, and then closes the connection. Usually when a client disconnects all resources get deallocated, but RetainPermanent prevents this, so the pixmap stays.

This is a widely used technique, but lightdm-gtk-greeter does not implement it in the standard way. usually when you do this you also set atoms pointing at the pixmap so that other programs can later change or deallocate those pixmaps - otherwise they just get leaked. lightdm-gtk-greeter does not do this. It should.

2. Xfwm4 starts up in compositing mode. All the composited windows are drawn into a buffer, then the buffer is drawn to the root window. This means that even if there's no windows on screen, the buffer will still draw over whatever pixmap is in the root window. At startup, Xfwm4 fills it's buffer with solid grey, so that's what you see. Xfwm4 has code to read out the root pixmap set using RetainPermanent, but again, it seems to be a none standard implementation which uses wrong atom names to get the pixmap addresses. This should also be fixed. Also this code is usually disabled as it is used in "monitoring" mode, when xfwm4 will constantly check if the root pixmap changed and copy the new one to it's composite buffer. We don't need to do that because xfdesktop handles our background. We only need to copy once, at startup, to fill the gap.

References:

http://mail.xfce.org/pipermail/xfce4-dev/2013-November/030529.html - my post on xfce-dev mailing list asking about the xfwm4 code.

https://github.com/mate-desktop/mate-desktop/pull/46 - a pull request fixing pretty much all the same problems in MATE.

https://mail.gnome.org/archives/wm-spec-list/2002-January/msg00001.html - a very old thread where the background atoms and how they should be used is discussed.

[Alistair Buxton (a-j-buxton)]

https://github.com/ali1234/xfwm4/commit/b7baa7aa60cdb80759e0872d0ab5a7cb59ec5c10

This patch combined with the xsetroot patch for lightdm (above) fixes the issue, but isn't ideal, as it doesn't address the leaking pixmaps and non-standard atom use. It's along the general lines of what we need to do though.

Specifically my patch enables the root pixmap copy only at startup, and not the rest of the monitoring code. The monitoring code is what makes xfdesktop crash, because when it uses RetainPermanent, but does not create the pixmap with a dummy X11 connection like it should.

[Alistair Buxton (a-j-buxton)]

A couple more URLs:

http://search.cpan.org/~kryde/X11-Protocol-Other-28/lib/X11/Protocol/XSetRoot.pm - The XSETROOT style, which xfwm4 seems to try to use.

http://www.eterm.org/docs/view.php?doc=ref#trans - the ESETROOT method, which xfdesktop appears to try to use.

[Alistair Buxton (a-j-buxton)]

I just linked a branch which contains half of the fix for this (the other half needs to be implemented in xfwm4). This also fixes the greeter from leaking X11 resources all over the place.

[Jackson Doak (noskcaj)]

Please add the PPA https://launchpad.net/~unit193/+archive/xfce and test that the xfwm4 half works.

[Launchpad Janitor (janitor)]

This bug was fixed in the package xfwm4 - 4.11.1-2ubuntu1

---------------
xfwm4 (4.11.1-2ubuntu1) trusty; urgency=medium

  * Drop all existing ubuntu changes, fixed in debian
  * Add -DMONITOR_ROOT_PIXMAP to CPPFLAGS for xubuntu seamless greeter
    to desktop transition. LP: #1232804
 -- Jackson Doak <email address hidden> Sat, 01 Mar 2014 19:27:21 +1100