diff --git a/protocol/river-input-management-v1.xml b/protocol/river-input-management-v1.xml
index 9ee9608..81f707c 100644
--- a/protocol/river-input-management-v1.xml
+++ b/protocol/river-input-management-v1.xml
@@ -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>
diff --git a/protocol/river-layer-shell-v1.xml b/protocol/river-layer-shell-v1.xml
index 0a9a437..0167e9d 100644
--- a/protocol/river-layer-shell-v1.xml
+++ b/protocol/river-layer-shell-v1.xml
@@ -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.
diff --git a/protocol/river-libinput-config-v1.xml b/protocol/river-libinput-config-v1.xml
index 18e4518..5e38b08 100644
--- a/protocol/river-libinput-config-v1.xml
+++ b/protocol/river-libinput-config-v1.xml
@@ -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>
diff --git a/protocol/river-window-management-v1.xml b/protocol/river-window-management-v1.xml
index dd9e556..64bfa58 100644
--- a/protocol/river-window-management-v1.xml
+++ b/protocol/river-window-management-v1.xml
@@ -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.
diff --git a/protocol/river-xkb-bindings-v1.xml b/protocol/river-xkb-bindings-v1.xml
index 041b1bd..de4f100 100644
--- a/protocol/river-xkb-bindings-v1.xml
+++ b/protocol/river-xkb-bindings-v1.xml
@@ -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">