xcb_flush() flushes xcb's output buffer. Thus, after this call, all
previous requests are surely written to the connection with the X11
server.
xcb_aux_sync() synchronises with the X11 server. It makes sure all
previous requests were sent to the X11 server and already processed. It
does this via free(xcb_get_input_focus_reply(xcb_get_input_focus())): It
sends a request and waits for its reply. It is guaranteed that the X11
server processes requests in-order.
This means that the sequence xcb_flush(); xcb_aux_sync() first writes
whatever is in the output buffer and then does another write for the
four bytes of the GetInputFocus request from xcb_aux_sync().
Put differently: xcb_flush(); xcb_aux_sync() doesn't do anything more
than just xcb_aux_sync(). In fact, it has slightly more overhead for the
same result.
Thus, this commit drops all calls to xcb_flush() immediately after
xcb_aux_sync().
Signed-off-by: Uli Schlachter <psychon@znc.in>
"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).
