diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index e53b0197..b8426384 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -2037,33 +2037,6 @@
 	use the seat object anymore.
       </description>
     </request>
-
-    <!-- Version 11 additions -->
-
-    <request name="get_keyboard_with_formats">
-      <description summary="return keyboard object">
-	The ID provided will be initialized to the wl_keyboard interface
-	for this seat.
-
-	This is an alternative to get_keyboard that informs the server of the
-	keymap formats supported by the client. The server selects one of the
-	provided format that it supports itself and may start to send keyboard
-	events. It is advised, but not mandatory, to respect the client’s order
-	of preference of the formats.
-
-	TODO: what if none of the format is supported?
-
-	This request only takes effect if the seat has the keyboard
-	capability, or has had the keyboard capability in the past.
-	It is a protocol violation to issue this request on a seat that has
-	never had the keyboard capability. The missing_capability error will
-	be sent in this case.
-      </description>
-      <arg name="id" type="new_id" interface="wl_keyboard" summary="seat keyboard"/>
-      <arg name="formats" type="array"
-           summary="A list of keymap_format values, ordered by preference"/>
-    </request>
-
   </interface>
 
   <interface name="wl_pointer" version="11">
@@ -2493,18 +2466,6 @@
 
       By default, the active surface is null, the keys currently logically down
       are empty, the active modifiers and the active group are 0.
-
-      Since version 11, clients must first negotiate the keymap format in order
-      to receive any keyboard event:
-
-      1. Client sends a set_supported_keymap_formats request,
-      2. Server responds with either:
-
-         - a keymap event, with the corresponding keymap_format being supported
-           by both the server and the client; the server is advised to use the
-           format with most features.
-         - a no_supported_keymap_format error if no common supported format is
-           found.
     </description>
 
     <enum name="keymap_format">
@@ -2528,6 +2489,11 @@
 
 	From version 7 onwards, the fd must be mapped with MAP_PRIVATE by
 	the recipient, as MAP_SHARED may fail.
+
+	From version 11 onwards, multiple wl_keyboard.keymap events may be sent
+	within the same frame, each one with a different keymap format. Clients
+	should select at most one of these events. Clients are advised to select
+	the format with most supported features.
       </description>
       <arg name="format" type="uint" enum="keymap_format" summary="keymap format"/>
       <arg name="fd" type="fd" summary="keymap file descriptor"/>
@@ -2675,10 +2641,35 @@
 
     <!-- Version 11 additions -->
 
-    <enum name="error" since="11">
-      <entry name="no_supported_keymap_format" value="0" since="11"
-	     summary="none of the keymap formats provided by the client is supported"/>
-    </enum>
+    <event name="frame">
+      <description summary="end of keyboard event sequence">
+	Indicates the end of a set of events that logically belong together.
+	A client is expected to accumulate the data in all events within the
+	frame before proceeding.
+
+	All wl_keyboard events before a wl_keyboard.frame event belong
+	logically together. For example, multiple wl_keyboard.keymap event may
+	be sent — each one with a different format — and finally a
+	wl_keyboard.frame event. The client may use this information to select
+	the keymap format that fits best.
+
+	A wl_keyboard.frame event is sent for every logical event group,
+	even if the group only contains a single wl_keyboard event.
+	Specifically, a client may get a sequence: key, frame, key, modifier,
+	frame, key, frame.
+
+	The wl_keyboard.enter and wl_keyboard.leave events are logical events
+	generated by the compositor and not the hardware. These events are
+	also grouped by a wl_keyboard.frame. When the keyboard focus moves from
+	one surface to another, a compositor should group the
+	wl_keyboard.leave event within the same wl_keyboard.frame.
+	However, a client must not rely on wl_keyboard.leave and
+	wl_keyboard.enter being in the same wl_keyboard.frame.
+	Compositor-specific policies may require the wl_keyboard.leave and
+	wl_keyboard.enter event being split across multiple wl_keyboard.frame
+	groups.
+      </description>
+    </event>
   </interface>
 
   <interface name="wl_touch" version="11">