Wayland compositor (wlroots)
git clone https://git.lucas.co/cce-compositor.git
rwm: allow consecutive rendering update sequences
This is already what I ended up implementing in river, this updates the
protocol documentation to match the implementation.
protocol/river-window-management-v1.xml | 388 +++++++++++++++++---------------
river/WindowManager.zig | 2 +-
2 files changed, 212 insertions(+), 178 deletions(-)
diff --git a/protocol/river-window-management-v1.xml b/protocol/river-window-management-v1.xml
index 1792b20..72e3049 100644
--- a/protocol/river-window-management-v1.xml
+++ b/protocol/river-window-management-v1.xml
@@ -51,43 +51,64 @@
windows, shell surfaces, decoration surfaces, borders, window cropping,
and more.
- The main loop of this protocol is as follows:
-
- 1. The server waits for an input event, window state change, etc.
-
- 2. The server sends events indicating all changes since the last
- update followed by the update_windowing_start event.
-
- 4. The client sends requests modifying windowing state or rendering state
+ Windowing state may only be modified by the window manager as part of a
+ windowing update sequence. A windowing update sequence is started with the
+ update_windowing_start event and ended with the update_windowing_finish
+ request. It is a protocol error to modify window state outside of a
+ windowing update sequence.
+
+ A windowing update sequence is always followed by at least one rendering
+ update sequence. A rendering update sequence is started with the
+ update_rendering_start event and ended with the update
+ update_rendering_finish request.
+
+ Rendering state may be modified by the window manager during a windowing
+ update sequence or a rendering update sequence. Regardless of when the
+ rendering state is modified, it is applied with the next
+ update_rendering_finish request. It is a protocol error to modify
+ rendering state outside of a windowing or rendering update sequence.
+
+ The server will start a windowing update sequence by sending new state and
+ the update_windowing_start event as soon as possible whenever there is a
+ change in state that must be communicated with the window manager.
+
+ If the window manager client needs to ensure a windowing update sequence
+ is started due to a state change the compositor is not aware of, it may
+ send the update_windowing_dirty request.
+
+ The server will start a rendering update sequence by sending new state and
+ the update_rendering_start event as soon as possible whenever there is a
+ change in window dimensions or position that must be communicated with the
+ window manager. Multiple rendering update sequences may be made
+ consecutively without a windowing update sequence in between, for example
+ during interactive move/resize of windows or if a window independently
+ changes its own dimensions.
+
+ To summarize the main loop of this protocol is as follows:
+
+ 1. The server sends events indicating all changes since the last
+ windowing update followed by the update_windowing_start event.
+
+ 2. The client sends requests modifying windowing state or rendering state
(as defined above) followed by the update_windowing_finish request.
- 6. The server sends new state to windows and waits for all window size
- changes. After all windows are ready it sends the new window sizes to
- the client followed by the update_rendering_start event.
+ 3. The server sends new state to windows and waits for responses.
+
+ 4. The server sends new window position and/or dimensions to the client
+ followed by the update_rendering_start event.
- 7. The client sends requests modifying rendering state (as defined above)
+ 5. The client sends requests modifying rendering state (as defined above)
followed by the update_rendering_finish request.
- After step 7, loop back to step 1 or, if there was a state change since
- the last update, skip straight to step 2.
+ 6. If window dimensions/positions change, loop back to step 4.
+ If state that requires a windowing update sequence changes or if the
+ client makes an update_windowing_dirty request, loop back to step 1.
For the purposes of frame perfection, the server may delay rendering new
- state committed by the windows in step 6 until after step 7 is finished.
-
- If the window manager client needs to ensure an update sequence is started
- due to a state change the compositor is not aware of, it may send the
- update_mark_dirty request.
+ state committed by the windows in step 3 until after step 5 is finished.
It is a protocol error for the client to make an update_windowing_finish
or update_rendering_finish request that violates this ordering.
-
- It is a protocol error to send requests modifying windowing state before
- the update_windowing_start event or after the update_windowing_finish
- request.
-
- It is a protocol error to send requests modifying rendering state before
- the update_windowing_start event or after the update_rendering_finish
- request.
</description>
<enum name="error">
@@ -146,13 +167,13 @@
</request>
<event name="update_windowing_start">
- <description summary="start the windowing update sequence phase">
+ <description summary="start a windowing update sequence">
This event indicates that the server has sent events indicating all
- state changes since the last update sequence.
+ state changes since the last windowing update sequence.
In response to this event, the client should make requests modifying
windowing state as it chooses. Then, the client must make the
- update_windowing_finish request to move the update sequence forward.
+ update_windowing_finish request.
See the description of the river_window_manager_v1 interface for a
complete overview of the update sequence loop.
@@ -160,7 +181,7 @@
</event>
<request name="update_windowing_finish">
- <description summary="finish the windowing update sequence phase">
+ <description summary="finish a windowing update sequence">
This request indicates that the client has made all changes to windowing
state it wishes to include in the current update sequence and that the
server should atomically send these state changes to the windows and
@@ -175,15 +196,27 @@
</description>
</request>
+ <request name="update_windowing_dirty">
+ <description summary="ensure a windowing update sequence is started">
+ This request ensures a windowing update sequence is started and that an
+ update_windowing_start event is sent by the server. If this request is
+ made during an ongoing update sequence, a new update sequence will be
+ started as soon as the current one is completed.
+
+ The client may want to use this request due to an internal state change
+ that the compositor is not aware of (e.g. a dbus event) which should
+ affect windowing or rendering state.
+ </description>
+ </request>
+
<event name="update_rendering_start">
- <description summary="start the rendering update sequence phase">
- This event indicates that windows have received and reacted to the
- windowing state changes sent in the current update sequence and that
- all new window dimensions have been sent to the window manager client.
+ <description summary="start a rendering update sequence">
+ This event indicates that the server has sent all river_node_v1.position
+ and river_window_v1.dimensions events necessary.
In response to this event, the client should make requests modifying
rendering state as it chooses. Then, the client must make the
- update_rendering_finish request to finish the current update sequence.
+ update_rendering_finish request.
See the description of the river_window_manager_v1 interface for a
complete overview of the update sequence loop.
@@ -191,34 +224,22 @@
</event>
<request name="update_rendering_finish">
- <description summary="finish the rendering update sequence phase">
+ <description summary="finish a rendering update sequence">
This request indicates that the client has made all changes to rendering
state it wishes to include in the current update sequence and that the
server should atomically apply and display these state changes to the
- user, completing the current update sequence.
+ user.
After sending this request, it is a protocol error for the client to
make further changes to rendering state until the next
- update_windowing_start event is received.
+ update_windowing_start or update_rendering_start event is received,
+ whichever comes first.
See the description of the river_window_manager_v1 interface for a
complete overview of the update sequence loop.
</description>
</request>
- <request name="update_mark_dirty">
- <description summary="Ensure an update sequence is started">
- This request ensures an update sequence is started and that an
- update_windowing_start event sent by the server. If this request is
- made during an ongoing update sequence, a new update sequence will be
- started as soon as the current one is completed.
-
- The client may want to use this request due to an internal state change
- that the compositor is not aware of (e.g. a dbus event) which should
- affect windowing or rendering state.
- </description>
- </request>
-
<event name="session_locked">
<description summary="the session has been locked">
This event indicates that the session has been locked.
@@ -292,7 +313,9 @@
A newly created window will not be displayed until the window manager
proposes window dimensions with the propose_dimensions request as part of
- an update sequence and that update sequence completes.
+ a windowing update sequence, the server replies with a dimensions event as
+ part of a rendering update sequence, and that rendering update sequence is
+ finished.
TODO:
- window cropping
@@ -338,8 +361,8 @@
The server will send a river_window_v1.closed event if/when the window
has been closed.
- This request modifies windowing state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies windowing state and may only be made as part of a
+ windowing update sequence, see the river_window_manager_v1 description.
</description>
</request>
@@ -385,11 +408,12 @@
the window content and are unaffected by the presence of borders or
decoration surfaces.
- This event is sent during update sequences after the
- update_windowing_finish request and before the update_rendering_start
- event. It may also be sent at the beginning of an update sequence before
- the update_windowing_start event if, for example, a window independently
- decides to change its dimensions.
+ This event is sent as part of a rendering update sequence before the
+ update_rendering_start event.
+
+ It may be sent due to a propose_dimensions request in a previous
+ windowing update sequence or because a window independently decides to
+ change its dimensions.
</description>
<arg name="width" type="int"/>
<arg name="height" type="int"/>
@@ -410,15 +434,20 @@
only allow dimensions that are multiple of the cell size.
When a propose_dimensions request is made, the server must send a
- dimensions event in response during the update sequence even if the
- window dimensions are unchanged since the most recent dimensions event.
+ dimensions event in response as soon as possible. It may not be possible
+ to send a dimensions event in the very next rendering update sequence
+ if, for example, the window takes too long to respond to the first
+ proposed dimensions. In this case, the server will send the dimensions
+ event in a future rendering update sequence. The window will not be
+ displayed until the first dimensions event is received and the rendering
+ update sequence is finished.
Note that the dimensions of a river_window_v1 refer to the dimensions of
the window content and are unaffected by the presence of borders or
decoration surfaces.
- This request modifies windowing state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies windowing state and may only be made as part of a
+ windowing update sequence, see the river_window_manager_v1 description.
</description>
<arg name="width" type="int"/>
<arg name="height" type="int"/>
@@ -432,8 +461,8 @@
Newly created windows are considered shown unless explicitly hidden with
the hide request.
- This request modifies rendering state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies rendering state and may only be made as part of a
+ rendering update sequence, see the river_window_manager_v1 description.
</description>
</request>
@@ -446,8 +475,8 @@
Newly created windows are considered shown unless explicitly hidden with
the hide request.
- This request modifies rendering state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies rendering state and may only be made as part of a
+ rendering update sequence, see the river_window_manager_v1 description.
</description>
</request>
@@ -532,8 +561,8 @@
This is the default if neither this request nor the use_ssd request is
ever made.
- This request modifies windowing state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies windowing state and may only be made as part of a
+ windowing update sequence, see the river_window_manager_v1 description.
</description>
</request>
@@ -545,8 +574,8 @@
This request will have no effect if the client only supports client side
decoration, see the decoration_hint event.
- This request modifies windowing state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies windowing state and may only be made as part of a
+ windowing update sequence, see the river_window_manager_v1 description.
</description>
</request>
@@ -582,8 +611,8 @@
position/dimensions of the window content and are unaffected by the
presence of borders or decoration surfaces.
- This request modifies rendering state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies rendering state and may only be made as part of a
+ rendering update sequence, see the river_window_manager_v1 description.
</description>
<arg name="edges" type="uint" enum="edges"/>
<arg name="width" type="int"/>
@@ -606,8 +635,8 @@
part of a tiled layout. If this request is never made, the window is
informed that it is not part of a tiled layout.
- This request modifies windowing state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies windowing state and may only be made as part of a
+ windowing update sequence, see the river_window_manager_v1 description.
</description>
<arg name="edges" type="uint" enum="edges"/>
</request>
@@ -706,8 +735,8 @@
for all new windows. If this request is never made, the compositor will
inform windows that all capabilities are supported.
- This request modifies windowing state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies windowing state and may only be made as part of a
+ windowing update sequence, see the river_window_manager_v1 description.
</description>
<arg name="caps" type="uint" enum="capabilities"/>
</request>
@@ -768,8 +797,8 @@
The window manager remains responsible for handling the position and
dimensions of the window while it is maximized.
- This request modifies windowing state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies windowing state and may only be made as part of a
+ windowing update sequence, see the river_window_manager_v1 description.
</description>
</request>
@@ -779,8 +808,8 @@
information to adapt the style of its client-side window decorations for
example.
- This request modifies windowing state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies windowing state and may only be made as part of a
+ windowing update sequence, see the river_window_manager_v1 description.
</description>
</request>
@@ -823,8 +852,8 @@
shall not affect the current position and dimensions of a fullscreen
window.
- This request modifies windowing state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies windowing state and may only be made as part of a
+ windowing update sequence, see the river_window_manager_v1 description.
</description>
<arg name="output" type="object" interface="river_output_v1"/>
</request>
@@ -837,8 +866,8 @@
determined by the most recent set_position and propose_dimensions
requests.
- This request modifies windowing state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies windowing state and may only be made as part of a
+ windowing update sequence, see the river_window_manager_v1 description.
</description>
</request>
@@ -889,8 +918,8 @@
If this request is never sent, the x and y offsets are undefined by this
protocol and left up to the compositor.
- This request modifies rendering state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies rendering state and may only be made as part of a
+ rendering update sequence, see the river_window_manager_v1 description.
</description>
<arg name="x" type="int"/>
<arg name="y" type="int"/>
@@ -906,8 +935,8 @@
surface after this request and before the update_rendering_finish
request, failure to do so is a protocol error.
- This request modifies rendering state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies rendering state and may only be made as part of a
+ rendering update sequence, see the river_window_manager_v1 description.
</description>
</request>
</interface>
@@ -953,8 +982,8 @@
after this request and before the update_rendering_finish request,
failure to do so is a protocol error.
- This request modifies rendering state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies rendering state and may only be made as part of a
+ rendering update sequence, see the river_window_manager_v1 description.
</description>
</request>
</interface>
@@ -990,8 +1019,8 @@
If this request is never sent, the position of the node is undefined by
this protocol and left up to the compositor.
- This request modifies rendering state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies rendering state and may only be made as part of a
+ rendering update sequence, see the river_window_manager_v1 description.
</description>
<arg name="x" type="int"/>
<arg name="y" type="int"/>
@@ -1013,9 +1042,8 @@
position. For example, this event is necessary to communicate the
results of interactive resize to the window manager client.
- This event is sent during update sequences after the
- update_windowing_finish request and before the update_rendering_start
- event.
+ This event is sent as part of a rendering update sequence before the
+ update_rendering_start event.
</description>
<arg name="x" type="int"/>
<arg name="y" type="int"/>
@@ -1026,8 +1054,8 @@
This request places the node above all other nodes in the compositor's
render list.
- This request modifies rendering state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies rendering state and may only be made as part of a
+ rendering update sequence, see the river_window_manager_v1 description.
</description>
</request>
@@ -1036,8 +1064,8 @@
This request places the node below all other nodes in the compositor's
render list.
- This request modifies rendering state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies rendering state and may only be made as part of a
+ rendering update sequence, see the river_window_manager_v1 description.
</description>
</request>
@@ -1048,8 +1076,8 @@
Attempting to place a node above itself has no effect.
- This request modifies rendering state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies rendering state and may only be made as part of a
+ rendering update sequence, see the river_window_manager_v1 description.
</description>
<arg name="other" type="object" interface="river_node_v1"/>
</request>
@@ -1061,8 +1089,8 @@
Attempting to place a node below itself has no effect.
- This request modifies rendering state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies rendering state and may only be made as part of a
+ rendering update sequence, see the river_window_manager_v1 description.
</description>
<arg name="other" type="object" interface="river_node_v1"/>
</request>
@@ -1187,8 +1215,8 @@
<description summary="give keyboard focus to a window">
Request that the compositor send keyboard input to the given window.
- This request modifies windowing state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies windowing state and may only be made as part of a
+ windowing update sequence, see the river_window_manager_v1 description.
</description>
<arg name="window" type="object" interface="river_window_v1"/>
</request>
@@ -1198,8 +1226,8 @@
Request that the compositor send keyboard input to the given shell
surface.
- This request modifies windowing state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies windowing state and may only be made as part of a
+ windowing update sequence, see the river_window_manager_v1 description.
</description>
<arg name="shell_surface" type="object" interface="river_shell_surface_v1"/>
</request>
@@ -1208,8 +1236,8 @@
<description summary="clear keyboard focus">
Request that the compositor not send keyboard input to any client.
- This request modifies windowing state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies windowing state and may only be made as part of a
+ windowing update sequence, see the river_window_manager_v1 description.
</description>
</request>
@@ -1290,9 +1318,9 @@
Rationale: While the shell surface does receive all wl_pointer,
wl_touch, etc. input events for the surface directly, these events do
- not necessarily trigger an update sequence and therefore do not allow
- the window manager to update focus or perform other actions in response
- to the input in a race-free way.
+ not necessarily trigger a windowing update sequence and therefore do not
+ allow the window manager to update focus or perform other actions in
+ response to the input in a race-free way.
This event will be followed by an update_windowing_start event after all
other new state has been sent by the server.
@@ -1310,8 +1338,8 @@
op_add_resize_window requests will be moved/resized based on input
corresponding to the provided serial (e.g. pointer or touch input).
- All windows must be added to the operation in the same update sequence
- as the op_start_serial request.
+ All windows must be added to the operation in the same windowing update
+ sequence as the op_start_serial request.
No windows are implicitly included in the operation, even the window
that requested the move/resize must be explicitly added to the
@@ -1319,12 +1347,12 @@
The operation continues until the pointer button, touch point or similar
corresponding to the given serial is released or the op_end request is
- made and applied during an update sequence.
+ made and applied during a windowing update sequence.
This request is ignored if an operation is already in progress.
- This request modifies windowing state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies windowing state and may only be made as part of a
+ windowing update sequence, see the river_window_manager_v1 description.
</description>
<arg name="serial" type="uint"/>
</request>
@@ -1335,23 +1363,22 @@
operation with the op_add_move_window and op_add_resize_window requests
will be moved/resized based on the movement of the pointer.
- All windows must be added to the operation in the same update sequence
- as the op_start_serial request.
+ All windows must be added to the operation in the same windowing update
+ sequence as the op_start_serial request.
The pointer operation continues until the op_end request is made during
- an update sequence and that update sequence completes.
-
+ a windowing update sequence and that update sequence is finished.
This request is ignored if an operation is already in progress.
- This request modifies windowing state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies windowing state and may only be made as part of a
+ windowing update sequence, see the river_window_manager_v1 description.
</description>
</request>
<request name="op_add_move_window">
<description summary="add movement of a window to an operation">
This request causes the position of a window to be updated by an
- operation started in the same update sequence as this request.
+ operation started in the same windowing update sequence as this request.
Multiple windows may be added to and moved or resized by a single
operation.
@@ -1360,11 +1387,12 @@
recent op_add_move_window or op_add_resize_window request will have an
effect.
- This request is ignored if not made in the same update sequence as the
- op_start_serial or op_start_pointer request that starts an operation.
+ This request is ignored if not made in the same windowing update
+ sequence as the op_start_serial or op_start_pointer request that starts
+ an operation.
- This request modifies windowing state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies windowing state and may only be made as part of a
+ windowing update sequence, see the river_window_manager_v1 description.
</description>
<arg name="window" type="object" interface="river_window_v1"/>
</request>
@@ -1372,7 +1400,8 @@
<request name="op_add_resize_window">
<description summary="add resize of a window to an operation">
This request causes the position/dimensions of a window to be updated by
- an operation started in the same update sequence as this request.
+ an operation started in the same windowing update sequence as this
+ request.
Multiple windows may be added to and moved or resized by a single
operation.
@@ -1381,8 +1410,9 @@
recent op_add_move_window or op_add_resize_window request will have an
effect.
- This request is ignored if not made in the same update sequence as the
- op_start_serial or op_start_pointer request that starts an operation.
+ This request is ignored if not made in the same windowing update
+ sequence as the op_start_serial or op_start_pointer request that starts
+ an operation.
The edges argument determines which edges of the window are resized from
during the operation.
@@ -1392,8 +1422,8 @@
edges. Resizing from, for example, both the top and right edges is
allowed.
- This request modifies windowing state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies windowing state and may only be made as part of a
+ windowing update sequence, see the river_window_manager_v1 description.
</description>
<arg name="window" type="object" interface="river_window_v1"/>
<arg name="edges" type="uint" enum="river_window_v1.edges"/>
@@ -1405,8 +1435,8 @@
This request is ignored if there is no operation in progress.
- This request modifies windowing state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies windowing state and may only be made as part of a
+ windowing update sequence, see the river_window_manager_v1 description.
</description>
</request>
@@ -1433,8 +1463,8 @@
This request may be useful to place bounds on an interactive pointer
move or resize for example.
- This request modifies windowing state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies windowing state and may only be made as part of a
+ windowing update sequence, see the river_window_manager_v1 description.
</description>
<arg name="region" type="object" allow-null="true" interface="wl_region"/>
</request>
@@ -1444,8 +1474,8 @@
Warp the pointer to the given position in the compositor's logical
coordinate space.
- This request modifies windowing state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies windowing state and may only be made as part of a
+ windowing update sequence, see the river_window_manager_v1 description.
</description>
<arg name="x" type="int"/>
<arg name="y" type="int"/>
@@ -1475,7 +1505,8 @@
configurable properties.
The new key binding is not enabled until initial configuration is
- completed and the enable request is made during an update sequence.
+ completed and the enable request is made during a windowing update
+ sequence.
</description>
<arg name="id" type="new_id" interface="river_xkb_binding_v1"/>
<arg name="keysym" type="uint" summary="an xkbcommon keysym"/>
@@ -1491,7 +1522,8 @@
linux/input-event-codes.h header file (e.g. BTN_RIGHT).
The new pointer binding is not enabled until initial configuration is
- completed and the enable request is made during an update sequence.
+ completed and the enable request is made during a windowing update
+ sequence.
</description>
<arg name="id" type="new_id" interface="river_pointer_binding_v1"/>
<arg name="button" type="uint" summary="a Linux input event code"/>
@@ -1505,7 +1537,8 @@
and receive events when the key binding is triggered.
The new key binding is not enabled until initial configuration is
- completed and the enable request is made during an update sequence.
+ completed and the enable request is made during a windowing update
+ sequence.
Normally, all key events are sent to the surface with keyboard focus by
the compositor. Key events that trigger a key binding are not sent to the
@@ -1554,8 +1587,8 @@
completed and the window manager wishes the key binding to be able to be
triggered.
- This request modifies windowing state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies windowing state and may only be made as part of a
+ windowing update sequence, see the river_window_manager_v1 description.
</description>
</request>
@@ -1564,8 +1597,8 @@
This request may be used to temporarily disable the key binding. It may
be later re-enabled with the enable request.
- This request modifies windowing state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies windowing state and may only be made as part of a
+ windowing update sequence, see the river_window_manager_v1 description.
</description>
</request>
@@ -1577,12 +1610,12 @@
This event will be followed by an update_windowing_start event after all
other new state has been sent by the server.
- The compositor should wait for the update sequence to complete before
- processing further input events. This allows the window manager client
- to, for example, modify key bindings and keyboard focus without racing
- against future input events. The window manager should of course respond
- as soon as possible as the capacity of the compositor to buffer incoming
- input events is finite.
+ The compositor should wait for the windowing update sequence to complete
+ before processing further input events. This allows the window manager
+ client to, for example, modify key bindings and keyboard focus without
+ racing against future input events. The window manager should of course
+ respond as soon as possible as the capacity of the compositor to buffer
+ incoming input events is finite.
</description>
</event>
@@ -1599,12 +1632,12 @@
This event will be followed by an update_windowing_start event after all
other new state has been sent by the server.
- The compositor should wait for the update sequence to complete before
- processing further input events. This allows the window manager client
- to, for example, modify key bindings and keyboard focus without racing
- against future input events. The window manager should of course respond
- as soon as possible as the capacity of the compositor to buffer incoming
- input events is finite.
+ The compositor should wait for the windowing update sequence to complete
+ before processing further input events. This allows the window manager
+ client to, for example, modify key bindings and keyboard focus without
+ racing against future input events. The window manager should of course
+ respond as soon as possible as the capacity of the compositor to buffer
+ incoming input events is finite.
</description>
</event>
</interface>
@@ -1615,7 +1648,8 @@
receive events when the binding is triggered.
The new key binding is not enabled until initial configuration is
- completed and the enable request is made during an update sequence.
+ completed and the enable request is made during a windowing update
+ sequence.
Normally, all pointer button events are sent to the surface with pointer
focus by the compositor. Pointer button events that trigger a pointer
@@ -1640,8 +1674,8 @@
completed and the window manager wishes the pointer binding to be able
to be triggered.
- This request modifies windowing state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies windowing state and may only be made as part of a
+ windowing update sequence, see the river_window_manager_v1 description.
</description>
</request>
@@ -1650,8 +1684,8 @@
This request may be used to temporarily disable the pointer binding. It
may be later re-enabled with the enable request.
- This request modifies windowing state and may only be made as part of an
- update sequence, see the river_window_manager_v1 description.
+ This request modifies windowing state and may only be made as part of a
+ windowing update sequence, see the river_window_manager_v1 description.
</description>
</request>
@@ -1663,12 +1697,12 @@
This event will be followed by an update_windowing_start event after all
other new state has been sent by the server.
- The compositor should wait for the update sequence to complete before
- processing further input events. This allows the window manager client
- to, for example, modify key bindings and keyboard focus without racing
- against future input events. The window manager should of course respond
- as soon as possible as the capacity of the compositor to buffer incoming
- input events is finite.
+ The compositor should wait for the windowing update sequence to complete
+ before processing further input events. This allows the window manager
+ client to, for example, modify key bindings and keyboard focus without
+ racing against future input events. The window manager should of course
+ respond as soon as possible as the capacity of the compositor to buffer
+ incoming input events is finite.
</description>
</event>
@@ -1685,12 +1719,12 @@
This event will be followed by an update_windowing_start event after all
other new state has been sent by the server.
- The compositor should wait for the update sequence to complete before
- processing further input events. This allows the window manager client
- to, for example, modify key bindings and keyboard focus without racing
- against future input events. The window manager should of course respond
- as soon as possible as the capacity of the compositor to buffer incoming
- input events is finite.
+ The compositor should wait for the windowing update sequence to complete
+ before processing further input events. This allows the window manager
+ client to, for example, modify key bindings and keyboard focus without
+ racing against future input events. The window manager should of course
+ respond as soon as possible as the capacity of the compositor to buffer
+ incoming input events is finite.
</description>
</event>
</interface>
diff --git a/river/WindowManager.zig b/river/WindowManager.zig
index 3f4c064..674259d 100644
--- a/river/WindowManager.zig
+++ b/river/WindowManager.zig
@@ -170,6 +170,7 @@ fn handleRequest(
}
wm.updateWindowingFinish();
},
+ .update_windowing_dirty => wm.dirtyWindowing(),
.update_rendering_finish => {
if (wm.state != .update_rendering) {
wm_v1.postError(.update_sequence_order,
@@ -179,7 +180,6 @@ fn handleRequest(
}
wm.updateRenderingFinish();
},
- .update_mark_dirty => wm.dirtyWindowing(),
.get_shell_surface => |args| {
const surface = wlr.Surface.fromWlSurface(args.surface);
ShellSurface.create(