wayland: Support axis relative direction

This allows clients to be aware of "natural scrolling" settings in the
compostior and adjust accordingly to optionally keep the same wheel and
trackpad behaviour accross platforms.

Testing using the "testmouse" example, behaviour in the demo is now the
same regardless of the compositor setting for scrolling.

NOTE: THIS IS NOT UPSTREAM PROTOCOL YET, DO NOT MERGE YET
This commit is contained in:
David Edmundson 2023-01-19 12:25:47 +00:00
parent 423a82cd4b
commit 3e9a40a933
3 changed files with 107 additions and 18 deletions

View file

@ -63,7 +63,9 @@
#include "../../events/SDL_keysym_to_scancode_c.h"
/* Clamp the wl_seat version on older versions of libwayland. */
#if SDL_WAYLAND_CHECK_VERSION(1, 21, 0)
#if 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
#else
#define SDL_WL_SEAT_VERSION 5
@ -828,11 +830,31 @@ static void pointer_handle_axis(void *data, struct wl_pointer *pointer,
}
}
static void pointer_handle_frame(void *data, struct wl_pointer *pointer)
static void
pointer_handle_axis_relative_direction(void *data, struct wl_pointer *pointer,
uint32_t axis, uint32_t axis_relative_direction)
{
struct SDL_WaylandInput *input = data;
if (axis != WL_POINTER_AXIS_VERTICAL_SCROLL) {
return;
}
switch (axis_relative_direction) {
case WL_POINTER_AXIS_RELATIVE_DIRECTION_IDENTICAL:
input->pointer_curr_axis_info.direction = SDL_MOUSEWHEEL_NORMAL;
break;
case WL_POINTER_AXIS_RELATIVE_DIRECTION_INVERTED:
input->pointer_curr_axis_info.direction = SDL_MOUSEWHEEL_FLIPPED;
break;
}
}
static void
pointer_handle_frame(void *data, struct wl_pointer *pointer)
{
struct SDL_WaylandInput *input = data;
SDL_WindowData *window = input->pointer_focus;
float x, y;
SDL_MouseWheelDirection direction = input->pointer_curr_axis_info.direction;
switch (input->pointer_curr_axis_info.x_axis_type) {
case AXIS_EVENT_CONTINUOUS:
@ -869,7 +891,7 @@ static void pointer_handle_frame(void *data, struct wl_pointer *pointer)
if (x != 0.0f || y != 0.0f) {
SDL_SendMouseWheel(input->pointer_curr_axis_info.timestamp_ns,
window->sdlwindow, 0, x, y, SDL_MOUSEWHEEL_NORMAL);
window->sdlwindow, 0, x, y, direction);
}
}
@ -911,7 +933,8 @@ static const struct wl_pointer_listener pointer_listener = {
pointer_handle_axis_source, /* Version 5 */
pointer_handle_axis_stop, /* Version 5 */
pointer_handle_axis_discrete, /* Version 5 */
pointer_handle_axis_value120 /* Version 8 */
pointer_handle_axis_value120, /* Version 8 */
pointer_handle_axis_relative_direction /* Version 9 */
};
static void touch_handler_down(void *data, struct wl_touch *touch, uint32_t serial,

View file

@ -21,9 +21,12 @@
#include "SDL_internal.h"
#ifndef SDL_waylandevents_h_
#define SDL_waylandevents_h_
#include "../../events/SDL_mouse_c.h"
#include "SDL_waylandvideo.h"
#include "SDL_waylandwindow.h"
#include "SDL_waylanddatamanager.h"
@ -145,6 +148,7 @@ struct SDL_WaylandInput
/* Event timestamp in nanoseconds */
Uint64 timestamp_ns;
SDL_MouseWheelDirection direction;
} pointer_curr_axis_info;
SDL_WaylandKeyboardRepeat keyboard_repeat;

View file

@ -1384,8 +1384,9 @@
that this request gives a role to a wl_surface. Often, this
request also creates a new protocol object that represents the
role and adds additional functionality to wl_surface. When a
client wants to destroy a wl_surface, they must destroy this 'role
object' before the wl_surface.
client wants to destroy a wl_surface, they must destroy this role
object before the wl_surface, otherwise a defunct_role_object error is
sent.
Destroying the role object does not remove the role from the
wl_surface, but it may stop the wl_surface from "playing the role".
@ -1405,6 +1406,8 @@
<entry name="invalid_transform" value="1" summary="buffer transform value is invalid"/>
<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"/>
</enum>
<request name="destroy" type="destructor">
@ -1788,7 +1791,7 @@
</request>
</interface>
<interface name="wl_seat" version="8">
<interface name="wl_seat" version="9">
<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
@ -1921,7 +1924,7 @@
</interface>
<interface name="wl_pointer" version="8">
<interface name="wl_pointer" version="9">
<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
@ -2278,9 +2281,64 @@
<arg name="axis" type="uint" enum="axis" summary="axis type"/>
<arg name="value120" type="int" summary="scroll distance as fraction of 120"/>
</event>
<enum name="axis_relative_direction">
<description summary="axis relative direction">
This specifies the direction of the physical motion that caused a
wl_pointer.axis event, relative to the wl_pointer.axis direction.
</description>
<entry name="identical" value="0"
summary="physical motion matches axis direction"/>
<entry name="inverted" value="1"
summary="physical motion is the inverse of the axis direction"/>
</enum>
<event name="axis_relative_direction" since="9">
<description summary="axis relative physical direction event">
Relative directional information of the entity causing the axis
motion.
For a wl_pointer.axis event, the wl_pointer.axis_relative_direction
event specifies the movement direction of the entity causing the
wl_pointer.axis event. For example:
- if a user's fingers on a touchpad move down and this
causes a wl_pointer.axis vertical_scroll down event, the physical
direction is 'identical'
- if a user's fingers on a touchpad move down and this causes a
wl_pointer.axis vertical_scroll up scroll up event ('natural
scrolling'), the physical direction is 'inverted'.
A client may use this information to adjust scroll motion of
components. Specifically, enabling natural scrolling causes the
content to change direction compared to traditional scrolling.
Some widgets like volume control sliders should usually match the
physical direction regardless of whether natural scrolling is
active. This event enables clients to match the scroll direction of
a widget to the physical direction.
This event does not occur on its own, it is coupled with a
wl_pointer.axis event that represents this axis value.
The protocol guarantees that each axis_relative_direction event is
always followed by exactly one axis event with the same
axis number within the same wl_pointer.frame. Note that the protocol
allows for other events to occur between the axis_relative_direction
and its coupled axis event.
The axis number is identical to the axis number in the associated
axis event.
The order of wl_pointer.axis_relative_direction,
wl_pointer.axis_discrete and wl_pointer.axis_source is not
guaranteed.
</description>
<arg name="axis" type="uint" enum="axis" summary="axis type"/>
<arg name="direction" type="uint" enum="axis_relative_direction"
summary="physical direction relative to axis motion"/>
</event>
</interface>
<interface name="wl_keyboard" version="8">
<interface name="wl_keyboard" version="9">
<description summary="keyboard input device">
The wl_keyboard interface represents one or more keyboards
associated with a seat.
@ -2407,7 +2465,7 @@
</event>
</interface>
<interface name="wl_touch" version="8">
<interface name="wl_touch" version="9">
<description summary="touchscreen input device">
The wl_touch interface represents a touchscreen
associated with a seat.
@ -2861,6 +2919,8 @@
<enum name="error">
<entry name="bad_surface" value="0"
summary="the to-be sub-surface is invalid"/>
<entry name="bad_parent" value="1"
summary="the to-be sub-surface parent is invalid"/>
</enum>
<request name="get_subsurface">
@ -2870,14 +2930,18 @@
plain wl_surface into a sub-surface.
The to-be sub-surface must not already have another role, and it
must not have an existing wl_subsurface object. Otherwise a protocol
error is raised.
must not have an existing wl_subsurface object. Otherwise the
bad_surface protocol error is raised.
Adding sub-surfaces to a parent is a double-buffered operation on the
parent (see wl_surface.commit). The effect of adding a sub-surface
becomes visible on the next time the state of the parent surface is
applied.
The parent surface must not be one of the child surface's descendants,
and the parent must be different from the child surface, otherwise the
bad_parent protocol error is raised.
This request modifies the behaviour of wl_surface.commit request on
the sub-surface, see the documentation on wl_subsurface interface.
</description>
@ -2932,12 +2996,10 @@
synchronized mode, and then assume that all its child and grand-child
sub-surfaces are synchronized, too, without explicitly setting them.
If the wl_surface associated with the wl_subsurface is destroyed, the
wl_subsurface object becomes inert. Note, that destroying either object
takes effect immediately. If you need to synchronize the removal
of a sub-surface to the parent surface update, unmap the sub-surface
first by attaching a NULL wl_buffer, update parent, and then destroy
the sub-surface.
Destroying a sub-surface takes effect immediately. If you need to
synchronize the removal of a sub-surface to the parent surface update,
unmap the sub-surface first by attaching a NULL wl_buffer, update parent,
and then destroy the sub-surface.
If the parent wl_surface object is destroyed, the sub-surface is
unmapped.