From feb5dc63085820b4874dd95f11ad2940dccef4e2 Mon Sep 17 00:00:00 2001 From: Pierre Le Marre Date: Tue, 2 Dec 2025 15:23:20 +0100 Subject: [PATCH] Add the wl_keyboard::frame event Introduce the wl_keyboard::frame event to end of a set of events that logically belong together, similarly to other frame events, e.g. wl_pointer::frame. The motivation is to enable keymap negotiation: - Compositor sends multiple consecutive wl_keyboard::keymap events, each one with a different format, then a wl_keyboard::frame event. - Clients select the most appropriate format to parse, if any. Signed-off-by: Pierre Le Marre --- protocol/wayland.xml | 77 +++++++++++++++++++------------------------- 1 file changed, 34 insertions(+), 43 deletions(-) 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. - - - - - - 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. - - - - - @@ -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. @@ -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. @@ -2675,10 +2641,35 @@ - - - + + + 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. + +