Compare commits

...

2 Commits

Author SHA1 Message Date
Frank Praznik 4ec4e9739d
Merge 1119d0ea82 into 6771a6020d 2024-09-19 11:14:00 +03:00
Frank Praznik 1119d0ea82
wayland: Add support for the key repeat event (seat v10)
The internal key repeat mechanism already disables itself if the key repeat interval is 0, and SDL tracks and handles the flagging of repeated keys itself, so just map the 'repeated' event to 'pressed'.
2024-09-13 12:46:59 -04:00
3 changed files with 183 additions and 66 deletions

View File

@ -1663,6 +1663,16 @@ static void keyboard_handle_key(void *data, struct wl_keyboard *keyboard,
bool handled_by_ime = false;
const Uint64 timestamp_raw_ns = Wayland_GetKeyboardTimestampRaw(input, time);
if (state == WL_KEYBOARD_KEY_STATE_REPEATED) {
// If this key shouldn't be repeated, just return.
if (input->xkb.keymap && WAYLAND_xkb_keymap_key_repeats(input->xkb.keymap, key + 8)) {
return;
}
// SDL automatically handles key tracking and repeat status, so just map 'repeated' to 'pressed'.
state = WL_KEYBOARD_KEY_STATE_PRESSED;
}
Wayland_UpdateImplicitGrabSerial(input, serial);
if (state == WL_KEYBOARD_KEY_STATE_PRESSED) {

View File

@ -78,7 +78,9 @@
#define SDL_WL_COMPOSITOR_VERSION 4
#endif
#if SDL_WAYLAND_CHECK_VERSION(1, 22, 0)
#if SDL_WAYLAND_CHECK_VERSION(1, 24, 0)
#define SDL_WL_SEAT_VERSION 10
#elif SDL_WAYLAND_CHECK_VERSION(1, 22, 0)
#define SDL_WL_SEAT_VERSION 9
#elif SDL_WAYLAND_CHECK_VERSION(1, 21, 0)
#define SDL_WL_SEAT_VERSION 8

View File

@ -46,7 +46,7 @@
compositor after the callback is fired and as such the client must not
attempt to use it after that point.
The callback_data passed in the callback is the event serial.
The callback_data passed in the callback is undefined and should be ignored.
</description>
<arg name="callback" type="new_id" interface="wl_callback"
summary="callback object for the sync request"/>
@ -212,7 +212,7 @@
</request>
</interface>
<interface name="wl_shm_pool" version="1">
<interface name="wl_shm_pool" version="2">
<description summary="a shared memory pool">
The wl_shm_pool object encapsulates a piece of memory shared
between the compositor and client. Through the wl_shm_pool
@ -262,17 +262,17 @@
created, but using the new size. This request can only be
used to make the pool bigger.
This request only changes the amount of bytes that are mmapped
by the server and does not touch the file corresponding to the
file descriptor passed at creation time. It is the client's
responsibility to ensure that the file is at least as big as
the new pool size.
This request only changes the amount of bytes that are mmapped
by the server and does not touch the file corresponding to the
file descriptor passed at creation time. It is the client's
responsibility to ensure that the file is at least as big as
the new pool size.
</description>
<arg name="size" type="int" summary="new size of the pool, in bytes"/>
</request>
</interface>
<interface name="wl_shm" version="1">
<interface name="wl_shm" version="2">
<description summary="shared memory support">
A singleton global object that provides support for shared
memory.
@ -419,6 +419,21 @@
<entry name="xbgr16161616" value="0x38344258" summary="[63:0] x:B:G:R 16:16:16:16 little endian"/>
<entry name="argb16161616" value="0x38345241" summary="[63:0] A:R:G:B 16:16:16:16 little endian"/>
<entry name="abgr16161616" value="0x38344241" summary="[63:0] A:B:G:R 16:16:16:16 little endian"/>
<entry name="c1" value="0x20203143" summary="[7:0] C0:C1:C2:C3:C4:C5:C6:C7 1:1:1:1:1:1:1:1 eight pixels/byte"/>
<entry name="c2" value="0x20203243" summary="[7:0] C0:C1:C2:C3 2:2:2:2 four pixels/byte"/>
<entry name="c4" value="0x20203443" summary="[7:0] C0:C1 4:4 two pixels/byte"/>
<entry name="d1" value="0x20203144" summary="[7:0] D0:D1:D2:D3:D4:D5:D6:D7 1:1:1:1:1:1:1:1 eight pixels/byte"/>
<entry name="d2" value="0x20203244" summary="[7:0] D0:D1:D2:D3 2:2:2:2 four pixels/byte"/>
<entry name="d4" value="0x20203444" summary="[7:0] D0:D1 4:4 two pixels/byte"/>
<entry name="d8" value="0x20203844" summary="[7:0] D"/>
<entry name="r1" value="0x20203152" summary="[7:0] R0:R1:R2:R3:R4:R5:R6:R7 1:1:1:1:1:1:1:1 eight pixels/byte"/>
<entry name="r2" value="0x20203252" summary="[7:0] R0:R1:R2:R3 2:2:2:2 four pixels/byte"/>
<entry name="r4" value="0x20203452" summary="[7:0] R0:R1 4:4 two pixels/byte"/>
<entry name="r10" value="0x20303152" summary="[15:0] x:R 6:10 little endian"/>
<entry name="r12" value="0x20323152" summary="[15:0] x:R 4:12 little endian"/>
<entry name="avuy8888" value="0x59555641" summary="[31:0] A:Cr:Cb:Y 8:8:8:8 little endian"/>
<entry name="xvuy8888" value="0x59555658" summary="[31:0] X:Cr:Cb:Y 8:8:8:8 little endian"/>
<entry name="p030" value="0x30333050" summary="2x2 subsampled Cr:Cb plane 10 bits per channel packed"/>
</enum>
<request name="create_pool">
@ -442,6 +457,17 @@
</description>
<arg name="format" type="uint" enum="format" summary="buffer pixel format"/>
</event>
<!-- Version 2 additions -->
<request name="release" type="destructor" since="2">
<description summary="release the shm object">
Using this request a client can tell the server that it is not going to
use the shm object anymore.
Objects created via this interface remain unaffected.
</description>
</request>
</interface>
<interface name="wl_buffer" version="1">
@ -453,9 +479,11 @@
client provides and updates the contents is defined by the buffer factory
interface.
If the buffer uses a format that has an alpha channel, the alpha channel
is assumed to be premultiplied in the color channels unless otherwise
specified.
Color channels are assumed to be electrical rather than optical (in other
words, encoded with a transfer function) unless otherwise specified. If
the buffer uses a format that has an alpha channel, the alpha channel is
assumed to be premultiplied into the electrical color channel values
(after transfer function encoding) unless otherwise specified.
Note, because wl_buffer objects are created from multiple independent
factory interfaces, the wl_buffer interface is frozen at version 1.
@ -847,6 +875,7 @@
<enum name="error">
<entry name="role" value="0" summary="given wl_surface has another role"/>
<entry name="used_source" value="1" summary="source has already been used"/>
</enum>
<request name="start_drag">
@ -868,7 +897,7 @@
The icon surface is an optional (can be NULL) surface that
provides an icon to be moved around with the cursor. Initially,
the top-left corner of the icon surface is placed at the cursor
hotspot, but subsequent wl_surface.attach request can move the
hotspot, but subsequent wl_surface.offset requests can move the
relative position. Attach requests must be confirmed with
wl_surface.commit as usual. The icon surface is given the role of
a drag-and-drop icon. If the icon surface already has another role,
@ -876,6 +905,10 @@
The input region is ignored for wl_surfaces with the role of a
drag-and-drop icon.
The given source may not be used in any further set_selection or
start_drag requests. Attempting to reuse a previously-used source
may send a used_source error.
</description>
<arg name="source" type="object" interface="wl_data_source" allow-null="true" summary="data source for the eventual transfer"/>
<arg name="origin" type="object" interface="wl_surface" summary="surface where the drag originates"/>
@ -889,6 +922,10 @@
to the data from the source on behalf of the client.
To unset the selection, set the source to NULL.
The given source may not be used in any further set_selection or
start_drag requests. Attempting to reuse a previously-used source
may send a used_source error.
</description>
<arg name="source" type="object" interface="wl_data_source" allow-null="true" summary="data source for the selection"/>
<arg name="serial" type="uint" summary="serial number of the event that triggered this request"/>
@ -1411,7 +1448,7 @@
<entry name="invalid_size" value="2" summary="buffer size is invalid"/>
<entry name="invalid_offset" value="3" summary="buffer offset is invalid"/>
<entry name="defunct_role_object" value="4"
summary="surface was destroyed before its role object"/>
summary="surface was destroyed before its role object"/>
</enum>
<request name="destroy" type="destructor">
@ -1440,9 +1477,9 @@
When the bound wl_surface version is 5 or higher, passing any
non-zero x or y is a protocol violation, and will result in an
'invalid_offset' error being raised. The x and y arguments are ignored
and do not change the pending state. To achieve equivalent semantics,
use wl_surface.offset.
'invalid_offset' error being raised. The x and y arguments are ignored
and do not change the pending state. To achieve equivalent semantics,
use wl_surface.offset.
Surface contents are double-buffered state, see wl_surface.commit.
@ -1477,8 +1514,9 @@
mutates the underlying buffer storage, the surface contents become
undefined immediately.
If wl_surface.attach is sent with a NULL wl_buffer, the
following wl_surface.commit will remove the surface content.
If wl_surface.attach is sent with a NULL wl_buffer, or the pending
wl_buffer has been destroyed, the following wl_surface.commit will
remove the surface content.
</description>
<arg name="buffer" type="object" interface="wl_buffer" allow-null="true"
summary="buffer of surface contents"/>
@ -1618,16 +1656,18 @@
<description summary="commit pending surface state">
Surface state (input, opaque, and damage regions, attached buffers,
etc.) is double-buffered. Protocol requests modify the pending state,
as opposed to the current state in use by the compositor. A commit
request atomically applies all pending state, replacing the current
state. After commit, the new pending state is as documented for each
related request.
as opposed to the active state in use by the compositor.
On commit, a pending wl_buffer is applied first, and all other state
second. This means that all coordinates in double-buffered state are
relative to the new wl_buffer coming into use, except for
wl_surface.attach itself. If there is no pending wl_buffer, the
coordinates are relative to the current surface contents.
A commit request atomically creates a content update from the pending
state, even if the pending state has not been touched. The content
update is placed in a queue until it becomes active. After commit, the
new pending state is as documented for each related request.
When the content update is applied, the wl_buffer is applied before all
other state. This means that all coordinates in double-buffered state
are relative to the newly attached wl_buffers, except for
wl_surface.attach itself. If there is no newly attached wl_buffer, the
coordinates are relative to the previous content update.
All requests that need a commit to become effective are documented
to affect double-buffered state.
@ -1666,10 +1706,12 @@
<request name="set_buffer_transform" since="2">
<description summary="sets the buffer transformation">
This request sets an optional transformation on how the compositor
interprets the contents of the buffer attached to the surface. The
accepted values for the transform parameter are the values for
wl_output.transform.
This request sets the transformation that the client has already applied
to the content of the buffer. The accepted values for the transform
parameter are the values for wl_output.transform.
The compositor applies the inverse of this transformation whenever it
uses the buffer contents.
Buffer transform is double-buffered state, see wl_surface.commit.
@ -1725,11 +1767,11 @@
a buffer that is larger (by a factor of scale in each dimension)
than the desired surface size.
If scale is not positive the invalid_scale protocol error is
If scale is not greater than 0 the invalid_scale protocol error is
raised.
</description>
<arg name="scale" type="int"
summary="positive scale for interpreting buffer contents"/>
summary="scale for interpreting buffer contents"/>
</request>
<!-- Version 4 additions -->
@ -1802,10 +1844,15 @@
This event indicates the preferred buffer scale for this surface. It is
sent whenever the compositor's preference changes.
Before receiving this event the preferred buffer scale for this surface
is 1.
It is intended that scaling aware clients use this event to scale their
content and use wl_surface.set_buffer_scale to indicate the scale they
have rendered with. This allows clients to supply a higher detail
buffer.
The compositor shall emit a scale value greater than 0.
</description>
<arg name="factor" type="int" summary="preferred scaling factor"/>
</event>
@ -1815,16 +1862,19 @@
This event indicates the preferred buffer transform for this surface.
It is sent whenever the compositor's preference changes.
It is intended that transform aware clients use this event to apply the
transform to their content and use wl_surface.set_buffer_transform to
indicate the transform they have rendered with.
Before receiving this event the preferred buffer transform for this
surface is normal.
Applying this transformation to the surface buffer contents and using
wl_surface.set_buffer_transform might allow the compositor to use the
surface buffer more efficiently.
</description>
<arg name="transform" type="uint" enum="wl_output.transform"
summary="preferred transform"/>
</event>
</interface>
<interface name="wl_seat" version="9">
<interface name="wl_seat" version="10">
<description summary="group of input devices">
A seat is a group of keyboards, pointer and touch devices. This
object is published as a global during start up, or when such a
@ -1957,7 +2007,7 @@
</interface>
<interface name="wl_pointer" version="9">
<interface name="wl_pointer" version="10">
<description summary="pointer input device">
The wl_pointer interface represents one or more input devices,
such as mice, which control the pointer location and pointer_focus
@ -1992,9 +2042,9 @@
where (x, y) are the coordinates of the pointer location, in
surface-local coordinates.
On surface.attach requests to the pointer surface, hotspot_x
On wl_surface.offset requests to the pointer surface, hotspot_x
and hotspot_y are decremented by the x and y parameters
passed to the request. Attach must be confirmed by
passed to the request. The offset must be applied by
wl_surface.commit as usual.
The hotspot can also be updated by passing the currently set
@ -2248,7 +2298,7 @@
<arg name="axis" type="uint" enum="axis" summary="the axis stopped with this event"/>
</event>
<event name="axis_discrete" since="5">
<event name="axis_discrete" since="5" deprecated-since="8">
<description summary="axis click event">
Discrete step information for scroll and other axes.
@ -2370,10 +2420,20 @@
</event>
</interface>
<interface name="wl_keyboard" version="9">
<interface name="wl_keyboard" version="10">
<description summary="keyboard input device">
The wl_keyboard interface represents one or more keyboards
associated with a seat.
Each wl_keyboard has the following logical state:
- an active surface (possibly null),
- the keys currently logically down,
- the active modifiers,
- the active group.
By default, the active surface is null, the keys currently logically down
are empty, the active modifiers and the active group are 0.
</description>
<enum name="keymap_format">
@ -2408,10 +2468,15 @@
The compositor must send the wl_keyboard.modifiers event after this
event.
In the wl_keyboard logical state, this event sets the active surface to
the surface argument and the keys currently logically down to the keys
in the keys argument. The compositor must not send this event if the
wl_keyboard already had an active surface immediately before this event.
</description>
<arg name="serial" type="uint" summary="serial number of the enter event"/>
<arg name="surface" type="object" interface="wl_surface" summary="surface gaining keyboard focus"/>
<arg name="keys" type="array" summary="the currently pressed keys"/>
<arg name="keys" type="array" summary="the keys currently logically down"/>
</event>
<event name="leave">
@ -2422,8 +2487,10 @@
The leave notification is sent before the enter notification
for the new focus.
After this event client must assume that all keys, including modifiers,
are lifted and also it must stop key repeating if there's some going on.
In the wl_keyboard logical state, this event resets all values to their
defaults. The compositor must not send this event if the active surface
of the wl_keyboard was not equal to the surface argument immediately
before this event.
</description>
<arg name="serial" type="uint" summary="serial number of the leave event"/>
<arg name="surface" type="object" interface="wl_surface" summary="surface that lost keyboard focus"/>
@ -2432,9 +2499,18 @@
<enum name="key_state">
<description summary="physical key state">
Describes the physical state of a key that produced the key event.
Since version 10, the key can be in a "repeated" pseudo-state which
means the same as "pressed", but is used to signal repetition in the
key event.
The key may only enter the repeated state after entering the pressed
state and before entering the released state. This event may be
generated multiple times while the key is down.
</description>
<entry name="released" value="0" summary="key is not pressed"/>
<entry name="pressed" value="1" summary="key is pressed"/>
<entry name="repeated" value="2" summary="key was repeated" since="10"/>
</enum>
<event name="key">
@ -2448,6 +2524,20 @@
If this event produces a change in modifiers, then the resulting
wl_keyboard.modifiers event must be sent after this event.
In the wl_keyboard logical state, this event adds the key to the keys
currently logically down (if the state argument is pressed) or removes
the key from the keys currently logically down (if the state argument is
released). The compositor must not send this event if the wl_keyboard
did not have an active surface immediately before this event. The
compositor must not send this event if state is pressed (resp. released)
and the key was already logically down (resp. was not logically down)
immediately before this event.
Since version 10, compositors may send key events with the "repeated"
key state when a wl_keyboard.repeat_info event with a rate argument of
0 has been received. This allows the compositor to take over the
responsibility of key repetition.
</description>
<arg name="serial" type="uint" summary="serial number of the key event"/>
<arg name="time" type="uint" summary="timestamp with millisecond granularity"/>
@ -2459,6 +2549,17 @@
<description summary="modifier and group state">
Notifies clients that the modifier and/or group state has
changed, and it should update its local state.
The compositor may send this event without a surface of the client
having keyboard focus, for example to tie modifier information to
pointer focus instead. If a modifier event with pressed modifiers is sent
without a prior enter event, the client can assume the modifier state is
valid until it receives the next wl_keyboard.modifiers event. In order to
reset the modifier state again, the compositor can send a
wl_keyboard.modifiers event with no pressed modifiers.
In the wl_keyboard logical state, this event updates the modifiers and
group.
</description>
<arg name="serial" type="uint" summary="serial number of the modifiers event"/>
<arg name="mods_depressed" type="uint" summary="depressed modifiers"/>
@ -2497,7 +2598,7 @@
</event>
</interface>
<interface name="wl_touch" version="9">
<interface name="wl_touch" version="10">
<description summary="touchscreen input device">
The wl_touch interface represents a touchscreen
associated with a seat.
@ -2566,6 +2667,8 @@
currently active on this client's surface. The client is
responsible for finalizing the touch points, future touch points on
this surface may reuse the touch point ID.
No frame event is required after the cancel event.
</description>
</event>
@ -2665,10 +2768,9 @@
</enum>
<enum name="transform">
<description summary="transform from framebuffer to output">
This describes the transform that a compositor will apply to a
surface to compensate for the rotation or mirroring of an
output device.
<description summary="transformation applied to buffer contents">
This describes transformations that clients and compositors apply to
buffer contents.
The flipped values correspond to an initial flip around a
vertical axis followed by rotation.
@ -2700,6 +2802,10 @@
The geometry event will be followed by a done event (starting from
version 2).
Clients should use wl_surface.preferred_buffer_transform instead of the
transform advertised by this event to find the preferred buffer
transform to use for a surface.
Note: wl_output only advertises partial information about the output
position and identification. Some compositors, for instance those not
implementing a desktop-style output layout or those exposing virtual
@ -2722,7 +2828,7 @@
<arg name="model" type="string"
summary="textual description of the model"/>
<arg name="transform" type="int" enum="transform"
summary="transform that maps framebuffer to output"/>
summary="additional transformation applied to buffer contents during presentation"/>
</event>
<enum name="mode" bitfield="true">
@ -2795,8 +2901,9 @@
This event contains scaling geometry information
that is not in the geometry event. It may be sent after
binding the output object or if the output scale changes
later. If it is not sent, the client should assume a
scale of 1.
later. The compositor will emit a non-zero, positive
value for scale. If it is not sent, the client should
assume a scale of 1.
A scale larger than 1 means that the compositor will
automatically scale surface buffers by this amount
@ -2804,12 +2911,9 @@
displays where applications rendering at the native
resolution would be too small to be legible.
It is intended that scaling aware clients track the
current output of a surface, and if it is on a scaled
output it should use wl_surface.set_buffer_scale with
the scale of the output. That way the compositor can
avoid scaling the surface, and the client can supply
a higher detail image.
Clients should use wl_surface.preferred_buffer_scale
instead of this event to find the preferred buffer
scale to use for a surface.
The scale event will be followed by a done event.
</description>
@ -3035,6 +3139,11 @@
If the parent wl_surface object is destroyed, the sub-surface is
unmapped.
A sub-surface never has the keyboard focus of any seat.
The wl_surface.offset request is ignored: clients must use set_position
instead to move the sub-surface.
</description>
<request name="destroy" type="destructor">
@ -3060,9 +3169,7 @@
surface area. Negative values are allowed.
The scheduled coordinates will take effect whenever the state of the
parent surface is applied. When this happens depends on whether the
parent surface is in synchronized mode or not. See
wl_subsurface.set_sync and wl_subsurface.set_desync for details.
parent surface is applied.
If more than one set_position request is invoked by the client before
the commit of the parent surface, the position of a new request always
@ -3085,9 +3192,7 @@
The z-order is double-buffered. Requests are handled in order and
applied immediately to a pending state. The final pending state is
copied to the active state the next time the state of the parent
surface is applied. When this happens depends on whether the parent
surface is in synchronized mode or not. See wl_subsurface.set_sync and
wl_subsurface.set_desync for details.
surface is applied.
A new sub-surface is initially added as the top-most in the stack
of its siblings and parent.