"Set" the wallpaper during startup only sometimes
Since commit 4f5e0e7, i3 would take a screenshot and set that as the
background pixmap of the root window during startup. This is the easy
part of setting a proper X11 wallpaper.
The code in question was added because something either set the
background pixmap of the root window to NONE or the X11 server was
started with "-background none". This is apparently done by default by
e.g. gdm to avoid some flickering while the X11 server starts up.
This commit makes this code conditional: Only when no wallpaper is
detected is a screenshot taken.
Since I could not find any way to query the background of a window, a
more direct approach is taken to detect this situation: First, we find
some part of the root window that is not currently covered. Then we open
a white window there, close it again and grab a screenshot. If a
wallpaper is set, the X11 server will draw this wallpaper after the
window is closed and something else will be visible in the screenshot.
However, the wallpaper could have a white pixel at the tested position.
Thus, this procedure is repeated with a black window.
Only when this procedure produces two different pixel values is a
screenshot taken and set as the wallpaper.
Fixes: https://github.com/i3/i3/issues/4371
Fixes: https://github.com/i3/i3/issues/2869
Signed-off-by: Uli Schlachter <psychon@znc.in>
I was confused by the previous state of the docs since I imagined that
there is still a race possible. Thus, the images are updated to
explicitly include the IPC reply from i3 (since that is an important
synchronisation component). I also tried to clarify some of the text.
Fixes: https://github.com/i3/i3/issues/4365
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit makes libxcb prefetch some information that will be needed
later anyway. This avoids some round-trips to the X11 server since the
information is already present when needed.
Signed-off-by: Uli Schlachter <psychon@znc.in>
i3 actually manages to have two different cairo surfaces referring to
the same drawable. One comes from the code in draw_util. The second is
temporarily created while rendering text via draw_text(). No idea how
well cairo handles this case.
This commit instead changes the code to pass the already existing cairo
surface from the caller through.
This might or might not fix https://github.com/i3/i3/pull/4357. My
thinking here is that cairo now knows the actual size of the drawable
and thus does not clip the drawing to a smaller size.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Fix#4261
The previous method was modifying the same list it was iterating upon
causing an erronous iteration and thus not every workspace got assigned
back to were they should (only the first one).