steven/beansprout-custom
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Update river wayland protocols

Browse source
This commit is contained in:
Ben Buhse 2026-03-15 17:32:53 -05:00
commit 799963ae42
No known key found for this signature in database
GPG key ID: 7916ACFCD38FD0B4
5 changed files with 32 additions and 42 deletions
Download patch file Download diff file Expand all files Collapse all files

10
protocol/river-input-management-v1.xml
View file

@ -23,18 +23,13 @@
IN THE SOFTWARE.
</copyright>
<description summary="configure input devices">
<description summary="manage seats and input devices">
This protocol supports creating/destroying seats, assigning input devices to
seats, and configuring input devices (e.g. setting keyboard repeat rate).
The key words "must", "must not", "required", "shall", "shall not",
"should", "should not", "recommended", "may", and "optional" in this
document are to be interpreted as described in IETF RFC 2119.
Warning! The protocol described in this file is currently in the testing
phase. Backward compatible changes may be added together with the
corresponding interface version bump. Backward incompatible changes can only
be done by creating a new major version of the extension.
</description>
<interface name="river_input_manager_v1" version="1">
@ -201,8 +196,7 @@
For example, a factor of 0.5 will make scrolling twice as slow while a
factor of 3.0 will make scrolling 3 times as fast.
Negative values for either rate or delay are illegal. A rate of zero
will disable any repeating (regardless of the value of delay).
Setting a scroll factor less than 0 is a protocol error.
</description>
<arg name="factor" type="fixed"/>
</request>

27
protocol/river-layer-shell-v1.xml
View file

@ -23,18 +23,13 @@
IN THE SOFTWARE.
</copyright>
<description summary="layer shell support for river">
<description summary="optional layer shell support">
This protocol allows the river-window-management-v1 window manager to
support the wlr-layer-shell-v1 protocol.
support the wlr-layer-shell-unstable-v1 protocol.
The key words "must", "must not", "required", "shall", "shall not",
"should", "should not", "recommended", "may", and "optional" in this
document are to be interpreted as described in IETF RFC 2119.
Warning! The protocol described in this file is currently in the testing
phase. Backward compatible changes may be added together with the
corresponding interface version bump. Backward incompatible changes can only
be done by creating a new major version of the extension.
</description>
<interface name="river_layer_shell_v1" version="1">
@ -108,10 +103,10 @@
This event will be followed by a manage_start event after all other new
state has been sent by the server.
</description>
<arg name="x" type="int"/>
<arg name="y" type="int"/>
<arg name="width" type="int"/>
<arg name="height" type="int"/>
<arg name="x" type="int" summary="global x coordinate"/>
<arg name="y" type="int" summary="global y coordinate"/>
<arg name="width" type="int" summary="area width"/>
<arg name="height" type="int" summary="area height"/>
</event>
<request name="set_default">
@ -147,7 +142,7 @@
</request>
<event name="focus_exclusive">
<description summary="">
<description summary="layer shell surface has exclusive focus">
A layer shell surface will be given exclusive keyboard focus at the end
of the manage sequence in which this event is sent. The window manager
may want to update window decorations or similar to indicate that no
@ -162,7 +157,7 @@
</event>
<event name="focus_non_exclusive">
<description summary="">
<description summary="layer shell surface wants non-exclusive focus">
A layer shell surface will be given non-exclusive keyboard focus at the
end of the manage sequence in which this event is sent. The window
manager may want to update window decorations or similar to indicate
@ -173,13 +168,17 @@
focus during the same manage sequence in which this event is sent, the
layer surface will not be focused.
If the layer surface with non-exclusive focus is closed or the window
manager chooses to move focus away from the layer surface, a focus_none
event will be sent in the next manage sequence.
This event will be followed by a manage_start event after all other new
state has been sent by the server.
</description>
</event>
<event name="focus_none">
<description summary="">
<description summary="no layer shell surface has focus">
No layer shell surface will have keyboard focus at the end of the manage
sequence in which this event is sent. The window manager may want to
return focus to whichever window last had focus, for example.

13
protocol/river-libinput-config-v1.xml
View file

@ -28,6 +28,10 @@
documentation should be referred to for detailed information on libinput's
behavior.
Note that the compositor will not be able to expose libinput devices through
this protocol when it does not have access to the hardware, for example when
running nested in another Wayland compositor or X11 session.
This protocol is designed so that (hopefully) any backwards compatible
change to libinput's API can be matched with a backwards compatible change
to this protocol.
@ -41,11 +45,6 @@
The key words "must", "must not", "required", "shall", "shall not",
"should", "should not", "recommended", "may", and "optional" in this
document are to be interpreted as described in IETF RFC 2119.
Warning! The protocol described in this file is currently in the testing
phase. Backward compatible changes may be added together with the
corresponding interface version bump. Backward incompatible changes can only
be done by creating a new major version of the extension.
</description>
<interface name="river_libinput_config_v1" version="1">
@ -540,7 +539,7 @@
<event name="click_method_support">
<description summary="supported click methods">
The click methods suppported by the device.
The click methods supported by the device.
</description>
<arg name="methods" type="uint" enum="click_methods"/>
</event>
@ -648,7 +647,7 @@
<event name="scroll_method_support">
<description summary="supported scroll methods">
The scroll methods suppported by the device.
The scroll methods supported by the device.
</description>
<arg name="methods" type="uint" enum="scroll_methods"/>
</event>

17
protocol/river-window-management-v1.xml
View file

@ -42,14 +42,14 @@
There are two disjoint categories of state managed by this protocol:
Window management state influences the communication between the server
and individual window clients (e.g. xdg_toplevels). Window management
Window management state influences the communication between the
compositor and individual windows (e.g. xdg_toplevels). Window management
state includes window dimensions, fullscreen state, keyboard focus,
keyboard bindings, and more.
Rendering state only affects the rendered output of the compositor and
does not influence communication between the server and individual window
clients. Rendering state includes the position and rendering order of
does not influence communication between the compositor and individual
windows. Rendering state includes the position and rendering order of
windows, shell surfaces, decoration surfaces, borders, and more.
Window management state may only be modified by the window manager as part
@ -661,7 +661,7 @@
</request>
<request name="get_decoration_above">
<description summary="create a decoration surface above the window">
<description summary="create a decoration above the window in z-order">
Create a decoration surface and assign the river_decoration_v1 role to
the surface. The created decoration is placed above the window in
rendering order, see the description of river_decoration_v1.
@ -676,7 +676,7 @@
</request>
<request name="get_decoration_below">
<description summary="create a decoration surface below the window">
<description summary="create a decoration below the window in z-order">
Create a decoration surface and assign the river_decoration_v1 role to
the surface. The created decoration is placed below the window in
rendering order, see the description of river_decoration_v1.
@ -864,7 +864,10 @@
<event name="fullscreen_requested">
<description summary="the window requested to be fullscreen">
The xdg-shell protocol for example allows windows to request that they
be made fullscreen and allows them to provide an output preference.
be made fullscreen and allows them to provide an optional output hint.
If the output argument is null, the window has no preference and the
window manager should choose an output.
The window manager is free to honor this request using
river_window_v1.fullscreen or ignore it.

7
protocol/river-xkb-bindings-v1.xml
View file

@ -23,7 +23,7 @@
IN THE SOFTWARE.
</copyright>
<description summary="define xkbcommon-based key bindings">
<description summary="xkbcommon-based key bindings">
This protocol allows the river-window-management-v1 window manager to
define key bindings in terms of xkbcommon keysyms and other configurable
properties.
@ -31,11 +31,6 @@
The key words "must", "must not", "required", "shall", "shall not",
"should", "should not", "recommended", "may", and "optional" in this
document are to be interpreted as described in IETF RFC 2119.
Warning! The protocol described in this file is currently in the testing
phase. Backward compatible changes may be added together with the
corresponding interface version bump. Backward incompatible changes can only
be done by creating a new major version of the extension.
</description>
<interface name="river_xkb_bindings_v1" version="2">