The compositor acts as a relay between applications using the text-input protocol and input methods using the input-method protocol.
This change implements the basic but useful support for input-method, leaving out grabs as well as popups.
Originally I asumed tilt_x and tilt_y are very unlikely to change
independent, I was proven wrong.
And while investigating Krita not using the Erasor tool, I found a bug,
which is unrelated though.
* Rename the constraint_create signal to new_constraint for
consistency
* Move the constraint_destroy signal to the constraint itself
* Use rotate_child_position instead of duplicating logic
* Fix inert constraint resource handling
* Style fixes
sx, sy used to store the buffer offset of the drag surface which was
then be added (by rootston) to the drag icon position.
Buffer offsets are handled already in surface_intersect_output
(output.c) so they were added twice for dnd surfaces.
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.
153f37bdf5 (#1145) removed the
wlr_xwayland_is_unamanged function while fixing OR, because it was
belieived that it's supposed to work around the broken OR handling.
This was a misunderstanding. is_unmanaged is (while sort of a hack)
intended to work around inherent differences between "real" X sessions
and our Xwayland/wayland situation.
The main reason it exists is to support applications like rofi and dzen,
while not handing focus to other OR windows (which should *not* be
required).
Traditionally, these applications just grabbed input from X and didn't
need to be focused by any logic in the WM. Which of course doesn't work
in wayland compositors. So we have to give them focus in some way.
Giving *every* OR window focus, breaks other applications that don't
expect focus to change.
A testcase that was pointed out to me where wlr_xwayland_is_unamanged was
breaking things is https://github.com/swaywm/sway/issues/2128 (syncplay,
gitk, gitgui)
Supposedly it broke using keyboard to navigate the menus.
I can't reproduce this with this patch. The popups can be navigated as
long as the parent has focus.
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 override_redirect flag can change on configure notify and
on map notify. This adds an event to know when it changes.
This removes wlr_xwayland_surface_is_unmanaged which was wrongly
using the window type to decide whether the view should be
unmanaged.
A similar patch was proposed to Weston, but has never been
merged upstream [1].
[1]: https://patchwork.freedesktop.org/patch/211161/
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.
