It's possible that a non-default keyboard grab exists when we are trying
to change focus. For example, say there is an XDG popup when we click on
a different window. This popup's keyboard grab will swallow any
keyboard_notify_enter(), meaning the newly-clicked window won't receive
keyboard input.
So, we cancel any existing grabs in roots_seat_set_focus(). Before this
fix, a window would have been set as active but not receive keyboard
entry.
Fixes#233.
Signed-off-by: Genki Sky <sky@genki.is>
The user-visible issue is that newly-mapped xdg-shell* windows would
sometimes start with their top-left-corner, rather than their center, in
the center of the screen. This is because get_size() would
conservatively fall back on (width, height) == (0, 0) if both
set_window_geometry() had not been called, and it found
view->wlr_surface to be NULL.
But, view->wlr_surface is only set to non-NULL in view_map(). We call
get_size() before this. Fortunately, the wlr_surface in question is
accessible via view->xdg_shell{,_v6}->surface, so always fall back on
that. We can assert its presence instead of further falling back on
(width, height) == (0, 0).
Signed-off-by: Genki Sky <sky@genki.is>
Compositors now have more control over how the backend creates its
renderer. Currently all backends create an EGL/GLES2 renderer, so
the necessary attributes for creating the context are passed to a
user-provided callback function. It is responsible for initializing
provided wlr_egl and to return a renderer. On fail, return 0.
Fixes#987
Before this change, a view would lose focus after clicking something that's not keyboard-interactive. This would lead to edge cases with layer-shell windows like input methods, which are pointer-only-interactive, but are not intended to change the state of any focus.
After clicking on something non-interactive, the current view was getting deactivated, but still received keyboard events. roots_seat_set_focus now changes both together in this case.
Makes the xwayland startup process two phased.
The first phase just initialises the X11 sockets.
The second phase starts the Xwayland server itself.
When starting xwayland lazily the second phase will be postponed until
a client has connected to the X11 socket.
Changes in behaviour:
The DISPLAY environment is now set immediately after the X11 sockets
are created.
When the Xwayland server is killed or crashes, the sockets will not be
recreated, but reused.
Fixes#849: Start up Xwayland lazily
On the X11 backend the cursor position might be outside the output
window so no output is returned leading to the assert to trigger. Use
sane fallback instead of crashing.
