diff --git a/README.md b/README.md
index b1fce58..67131cd 100644
--- a/README.md
+++ b/README.md
@@ -96,10 +96,10 @@ combination of methods.
 **libei** side-steps this issue by making the *communication* itself a
 an implementation detail and providing different *negotiation* backends.
 A client can attempt to establish a **libei** context through a Flatpak
-Portal first and all back onto a public DBus interface and fall back onto
-e.g. a named UNIX socket. All with a few lines of code only. There is only
-one spot the client has to care about this, the actual emulation of input is
-identical regardless of backend.
+Portal first and fall back onto a public DBus interface and then fall back
+onto e.g. a named UNIX socket. All with a few lines of code only. There is
+only one spot the client has to care about this, the actual emulation of input
+is identical regardless of backend.
 
 High-level summary
 ------------------
@@ -116,11 +116,11 @@ A client starts a `libei` context and connects to the server - either
 directly, via DBus or via a portal. The server (or the portal) approves or
 denies the client. After successful authentication the server sends one or
 more seats (a logical group of devices) to the client; the client can
-request the creation of a device with capabilities `pointer`, `keyboard` or
+request the creation of devices with capabilities `pointer`, `keyboard` or
 `touch`, etc. in those seats.
 
-The client triggers input events on this device, the server receives those
-as events through `libeis` and can forwards them as if they were libinput
+The client triggers input events on these devices, the server receives those
+as events through `libeis` and can forward them as if they were regular input
 events. The server has control of the client stream. If the stream is
 paused, events from the client are discarded. If the stream is resumed, the
 server will receive the events (but may discard them anyway depending on
@@ -138,8 +138,7 @@ For a `synergy` use-case, the setup requires:
   forwards those to the remote `synergy-server` which sends them via `libei`
   to the compositor B.
 
-**libei** does not provide a method for capturing events, see the
-"Capability monitoring" section below.
+**libei** does not provide a method for capturing events.
 
 Using REIS
 ----------
@@ -257,6 +256,9 @@ Some of the capabilities are distinctively display server-specific, for
 example the concept of a seat and a device is different between X and
 Wayland.
 
+At this point, no implementation of capability monitoring is planned for
+**libei**.
+
 ### Keyboard layouts
 
 The emulated input may require a specific keyboard layout, for example
@@ -264,9 +266,8 @@ for softtokens (usually: constant layout "us") or for the `synergy` case
 where the remote keyboard should have the same keymap as the local one, even
 where the remote host is configured otherwise.
 
-libei provides keymap negotation: the client can pick a keymap, the server
-can accept it, refuse it, or override it with its own. In the latter two
-cases it is up to the client to handle the result.
+In **libei**, the server informs the client about the keymap it expects and it
+is up to the client to provide the correct keyboard events.
 
 Modifier state handling, group handling, etc. is still a private
 implementation so even where the server supports individual keymaps. So it