wl_fixed_t is a 32-bit data type, but our doubles are 64-bit. This meant
that two doubles that would map to the same wl_fixed_t could compare
unequal, and send a duplicate motion event.
Refs swaywm/sway#4632.
The protocol allows compositors to not send any keymap to Wayland
clients. Handle a keymap-less keyboard correctly by sending
WL_KEYBOARD_KEYMAP_FORMAT_NO_KEYMAP instead of erroring out in the
mmap call.
The wl_touch.frame event is used to group multiple touch events
together. Instead of sending it immediately after each touch event,
rely on the backend to send it (and on the compositor to relay it).
This is a breaking change because compositors now need to manually
send touch frame events instead of relying on wlr_seat to do it.
This is necessary for some grabs, which currently have no way of knowing
when the pointer/keyboard focus has left a surface. For example, without
this, a drag-and-drop grab can erroneously drop into a window that the
cursor is no longer over.
This is the plumbing needed to properly fix swaywm/sway#5220. The
existing fix, swaywm/sway#5222, relies on every grab's `enter()` hook
allowing a `NULL` surface. This is not guaranteed by the API and, in
fact, is not the case for the xdg-shell popup grab and results in a
crash when the cursor leaves a surface and does not immediately enter
another one while a popup is open (#2161).
This fix also adds an assertion to wlr_seat_pointer_notify_enter() that
ensures it's never called with a `NULL` surface. This will make Sway
crash much more until it fixes its usage of the API, so we should land
this at the same time as a fix in Sway (which I haven't posted yet).
We should throw a protocol error if the relevant capability has never
existed when get_(pointer|keyboard|touch) is called. Otherwise, it
should succeed, even if the capability is not currently present.
This follows the spec, and avoids possible races with the client when
capabilities are lost.
Closes: https://github.com/swaywm/wlroots/issues/2227
Check for a NULL keyboard_state.keyboard value in
seat_client_create_keyboard() before trying to use it, as is done in
other functions like seat_client_send_repeat_info(). Prevents a segfault
in certain situations on keyboard removal, as seen in the sway issue.
Closes: https://github.com/swaywm/sway/issues/5205
Closes: https://github.com/swaywm/wlroots/issues/2073
Having 1.16 results in the following error when running the compositor:
2019-04-27 17:30:50 - [wayland] wl_global_create: implemented version for 'wl_seat' higher than interface version (7 > 6)
2019-04-27 17:30:50 - [sway/input/seat.c:428] seat_create:could not allocate seat
We require wayland-server >= 1.17 for wl_seat version 7.
Fixes: a671fc51d2 ("Advertise wl_seat version 7")
Fixes: a656e486f4 ("seat: fallback to v6 if libwayland 1.17 isn't available")
Since e26217c51e3a5e1d7dfc95a8a76299e056497981, touchpoints can outlive
surfaces. This works fine as long as the client stays around, but fails
horribly otherwise; therefore we have to make sure that touchpoints don't
outlive their clients.
Fixes#1788
The documentation for wayland-server.h says:
> Use of this header file is discouraged. Prefer including
> wayland-server-core.h instead, which does not include the server protocol
> header and as such only defines the library PI, excluding the deprecated API
> below.
Replacing wayland-server.h with wayland-server-core.h allows us to drop the
WL_HIDE_DEPRECATED declaration.
When the surface is destroyed clear it's reference but wait for the up
event to destroy the touch point via wlr_seat_touch_notify_up().
If the surface is destroyed before the up event we end up with
incomplete sequences sent to the client like
[915821.276] wl_touch@3.down(146, 2475027, wl_surface@38, 0, 236.000000, 515.000000)
[915821.608] wl_touch@3.frame()
[915821.637] wl_touch@3.motion(2475027, 0, 236.000000, 515.000000)
[915821.779] wl_touch@3.frame()
so there's never an up event. While it should be something like
[2461229.051] wl_touch@3.down(81, 3236959, wl_surface@34, 0, 218.000000, 478.000000)
[2461229.435] wl_touch@3.frame()
[2461229.484] wl_touch@3.motion(3236959, 0, 218.000000, 478.000000)
[2461229.636] wl_touch@3.frame()
[2461277.520] wl_touch@3.up(82, 3237007, 0)
[2461277.681] wl_touch@3.frame()
this confuses toolkits intepreting the next down event incorrectly. So
don't destroy the touch point too early.
This change tracks, for each wlr_seat_client, the most recent serial
numbers which were sent to the client. When the client makes a
selection request, wlroots now verifies that the serial number
associated with the selection request was actually provided to that
specific client. This ensures that the client that was most
recently interacted with always has priority for its copy selection
requests, and that no other clients can incorrectly use a larger serial
value and "steal" the role of having the copy selection.
Also, the code used to determine when a given selection is superseded
by a newer request uses < instead of <= to allow clients to make
multiple selection requests with the same serial number and have the
last one hold.
To limit memory use, a ring buffer is used to store runs of sequential
serial numbers, and all serial numbers earlier than the start of the
ring buffer are assumed to be valid. Faking very old serials is
unlikely to be disruptive.
Assuming all clients are correctly written, the only additional
constraint which this patch should impose is that serial numbers
are now bound to seats: clients may not receive a serial number
from an input event on one seat and then use that to request
copy-selection on another seat.
In addition to `button_count`, we keep track of the current buttons
pressed just as in `wlr_keyboard`.
Add `set_add` and `set_remove` to assist with this. These functions can
only be used with values greater than 0 (such as the button/key masks
for keyboards and pointers).
Partially addresses:
- https://github.com/swaywm/wlroots/issues/1716
- https://github.com/swaywm/wlroots/issues/1593
The grab serial can be used to start a pointer grab. A button pressed event
should be used for this purpose.
Thus, we should only save the grab serial if it's the first button pressed
event we send. This commit makes it so the serial is not saved if a button is
released while another button is still pressed.
Frame events group logically connected pointer events. It makes sense to make
the backend responsible for sending frame events, since once the events are
split (ie. once the frame events are stripped) it's not easy to figure out
which events belongs to which frame again.
This is also how Weston handles frame events.
Fixes https://github.com/swaywm/wlroots/issues/1468
