Implement the tablet-v2 tablet tool's implicit grab semantics for
buttons and tip.
This avoids losing focus (to other [sub]surfaces) when a button is held,
or the tip is down.
This should help when the device is used close to a surface's border and
would otherwise have to be very precise.
Implement the basic logic for tablet-v2 tablet_pad's grabs. And plug in
the default grab.
Features like "holding" the focus should be implemented via grabs, like
they are for pointer and keyboard.
The previous naming was based on the input-device capability names from
libinput.
With code that uses the libinput_tablet_tool and mapping into tablet-v2,
this is confusing, so the name is changed to follow the names used in
the protocol.
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>
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.
==32557==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x000000425f96 bp 0x7fff8ac19de0 sp 0x7fff8ac19d20 T0)
==32557==The signal is caused by a READ memory access.
==32557==Hint: address points to the zero page.
#0 0x425f95 in roots_seat_set_focus ../rootston/seat.c:737
#1 0x40bcd6 in roots_cursor_press_button ../rootston/cursor.c:272
#2 0x40c1f7 in roots_cursor_handle_button ../rootston/cursor.c:298
#3 0x42179b in handle_cursor_button ../rootston/seat.c:58
#4 0x7f1651062367 in wlr_signal_emit_safe ../util/signal.c:29
#5 0x7f165101b532 in handle_pointer_button ../types/wlr_cursor.c:344
#6 0x7f1651062367 in wlr_signal_emit_safe ../util/signal.c:29
#7 0x7f1650ff633b in handle_pointer_button ../backend/libinput/pointer.c:85
#8 0x7f1650ff5291 in wlr_libinput_event ../backend/libinput/events.c:215
#9 0x7f1650ff3990 in wlr_libinput_readable ../backend/libinput/backend.c:35
#10 0x7f1650d88c11 in wl_event_loop_dispatch (/lib64/libwayland-server.so.0+0x9c11)
#11 0x7f1650d87449 in wl_display_run (/lib64/libwayland-server.so.0+0x8449)
#12 0x418e90 in main ../rootston/main.c:81
#13 0x7f164ff7ef29 in __libc_start_main (/lib64/libc.so.6+0x20f29)
#14 0x405829 in _start (/home/shared/wayland/wlroots/build/rootston/rootston+0x405829)
introduced by #680
Check whether the newly focused view is the same as the one currently
fullscreen on that output, or override redirect and don't unfullscreen
in these cases.
The output fullscreen surfaces are drawn in front of everything, without
consideration for view z-order.
If a view is brought to front, unset any fullscreen view that would
cover this view to make sure the view is visible.
This adds `wlr_xwayland_surface_is_unamanged`, to allow compositors more
fine grained control over XWayland focus.
A surface that is unmanaged should not receive focus, while other
windows that are just override redirect may want it (dmenu).
The way unamanged is determined is taken from wlc.
In case wlroots is not being compiled with XWayland support, we will not
have an xwayland surface in our roots view. While we make sure to pay
attention to that in some places, we are not being consistent and try to
access the xwayland surface in other places. Obviously, this leads to a
compiler error due to the field not being present.
Fix the issue by sprinkling in a few additional ifdefs where required.
Markus Ongyerth
emersion
Tony Crisci
Genki Sky
Dorota Czaplejewicz
Drew DeVault
Dominique Martinet
Vincent Vanlaer
Patrick Steinhardt