build: use Meson pkgconfig module

This depends on:
47633330da

Signed-off-by: Simon Ser <contact@emersion.fr>

experimental/xx-input-method/xx-input-method-v2.xml

@@ -47,7 +47,7 @@
     mechanism is discouraged.
   </description>
 
-  <interface name="xx_input_method_v1" version="2">
+  <interface name="xx_input_method_v1" version="3">
     <description summary="input method">
       An input method object allows for clients to compose text.
 
@@ -168,7 +168,7 @@
 
         The initial value of cause is input_method.
       </description>
-      <arg name="cause" type="uint" enum="zwp_text_input_v3.change_cause"/>
+      <arg name="cause" type="uint" enum="xx_text_input_v3.change_cause"/>
     </event>
 
     <event name="content_type">
@@ -183,8 +183,38 @@
         The initial value for hint is none, and the initial value for purpose
         is normal.
       </description>
-      <arg name="hint" type="uint" enum="zwp_text_input_v3.content_hint"/>
-      <arg name="purpose" type="uint" enum="zwp_text_input_v3.content_purpose"/>
+      <arg name="hint" type="uint" enum="xx_text_input_v3.content_hint"/>
+      <arg name="purpose" type="uint" enum="xx_text_input_v3.content_purpose"/>
+    </event>
+    
+    <event name="set_available_actions" since="3">
+      <description summary="announce the available actions">
+        Announces the actions available for the currently active text input.
+
+        Values set with this event are double-buffered. They will get applied
+        on the next .done event.
+        They get reset to the initial value on the next committed deactivate event.
+
+        The initial value is an empty set: no actions are available.
+
+        Values in the available_actions array come from text-input-v3.action.
+      </description>
+      <arg name="available_actions" type="array" summary="available actions"/>
+    </event>
+
+    <event name="announce_supported_features" since="3">
+      <description summary="announce extra supported features">
+        Notifies the input method what the currently active text input client is able to do.
+
+        This event should come within the same .done sequence as .activate. Otherwise, the input method may ignore it.
+        
+        Values set with this event are double-buffered. They will get applied
+        on the next .done event.
+        They get reset to initial on the next committed deactivate event.
+
+        The initial value for features is none.
+      </description>
+      <arg name="features" type="uint" enum="xx_text_input_v3.supported_features"/>
     </event>
 
     <event name="done">
@@ -209,6 +239,18 @@
       </description>
     </event>
 
+    <request name="perform_action" since="3">
+      <description summary="perform action">
+        Perform an action on this text input.
+
+        Values set with this event are double-buffered. They must be applied
+        and reset to initial on the next commit request.
+
+        The initial value of action is none.
+      </description>
+      <arg name="action" type="uint" enum="xx_text_input_v3.action" summary="action to perform"/>
+    </request>
+
     <request name="commit_string">
       <description summary="commit string">
         Send the commit string text for insertion to the application.
@@ -283,6 +325,34 @@
       <arg name="after_length" type="uint"/>
     </request>
 
+    <request name="move_cursor" since="3">
+      <description summary="move cursor and change selection">
+        Unselects text, moves the cursor and selects text.
+
+        This is equivalent to dragging the mouse over some text: it deselects whatever might be currently selected and selects a new range of text.
+        
+        The offsets used in arguments are in bytes relative to the current cursor position. Cursor is the new position of the cursor, and anchor is the opposite end of selection. If there's no selection, anchor should be equal to cursor.
+        
+        The offsets do not take preedit contents into account, nor is preedit changed in any way with this request.
+        
+        Both cursor and anchor must fall on code point boundaries, otherwise text input client may ignore the request. It is therefore not recommended for an input method to move any of them beyond the text received in surrounding_text.
+        
+        When surrounding_text is not supported, the offsets must not be interpreted as bytes, but as some human-readable unit at least as big as a code point, for example a grapheme.
+
+        The cursor and anchor arguments can also take the following special values:
+        BEGINNING := 0x8000_0000 = i32::MIN
+        END := 0x7fff_ffff = i32::MAX
+        meaning, respectively, the beginning and the end of of all text in the input field.
+
+        Values set with this event are double-buffered. They must be applied
+        and reset to initial on the next commit request.
+
+        The initial values of both cursor and anchor are 0.
+      </description>
+      <arg name="cursor" type="int"/>
+      <arg name="anchor" type="int"/>
+    </request>
+    
     <request name="commit">
       <description summary="apply state">
         Apply state changes from commit_string, set_preedit_string and
@@ -298,10 +368,14 @@
         1. Replace existing preedit string with the cursor.
         2. Delete requested surrounding text.
         3. Insert commit string with the cursor at its end.
-        4. Calculate surrounding text to send.
-        5. Insert new preedit text in cursor position.
-        6. Place cursor inside preedit text.
+        4. Move the cursor and selection.
+        5. Calculate surrounding text to send.
+        6. Insert new preedit text in cursor position.
+        7. Place cursor inside preedit text.
+        8. Perform the requested action.
 
+        Note that the input method can not receive more than 4000 bytes of selection text, which might be the case for example when the entire document is selected. Nevertheless, the text input must delete the entire selected range before inserting the commit string.
+        
         The serial number reflects the last state of the xx_input_method_v1
         object known to the client. The value of the serial argument must be
         equal to the number of done events already issued by that object. When
@@ -793,7 +867,7 @@
     </request>
   </interface>
 
-  <interface name="xx_input_method_manager_v2" version="2">
+  <interface name="xx_input_method_manager_v2" version="3">
     <description summary="input method manager">
       The input method manager allows the client to become the input method on
       a chosen seat.

experimental/xx-keyboard-filter/README

@@ -0,0 +1,4 @@
+Keyboard filter protocol
+
+Maintainers:
+Dorota Czaplejewicz <gilaac.dcz@porcupinefactory.org>

experimental/xx-keyboard-filter/xx-keyboard-filter-v1.xml

@@ -0,0 +1,176 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="keyboard_filter_experimental_v1">
+
+  <copyright>
+    Copyright 2018 Mike Blumenkrantz
+    Copyright 2018 Samsung Electronics Co., Ltd
+    Copyright 2018 Red Hat Inc.
+    Copyright 2025 DorotaC
+
+    Permission is hereby granted, free of charge, to any person obtaining a
+    copy of this software and associated documentation files (the "Software"),
+    to deal in the Software without restriction, including without limitation
+    the rights to use, copy, modify, merge, publish, distribute, sublicense,
+    and/or sell copies of the Software, and to permit persons to whom the
+    Software is furnished to do so, subject to the following conditions:
+
+    The above copyright notice and this permission notice (including the next
+    paragraph) shall be included in all copies or substantial portions of the
+    Software.
+
+    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+    DEALINGS IN THE SOFTWARE.
+  </copyright>
+  
+  <description summary="filter and intercept keyboard events">
+    The keyboard_filter protocol allows a client to intercept selected keyboard events and prevent them from reaching the focused surface.
+    
+    This protocol offers a way to alter events reaching an application without the need to allow generating arbitrary keyboard events.
+    
+    High-level overview of the interfaces:
+    
+    The keyboard_filter_manager exposes the bind_to_input_method request which binds a wl_keyboard to an xx_input_method.
+    The resulting keyboard_filter object has the can be then used for intercepting keyboard events in accordance to input method needs.
+    
+    This document adheres to the RFC 2119 when using words like "must",
+    "should", "may", etc.
+
+    Warning! The protocol described in this file is currently in the
+    experimental phase. Backwards incompatible major versions of the
+    protocol are to be expected. Exposing this protocol without an opt-in
+    mechanism is discouraged.
+  </description>
+
+  <interface name="xx_keyboard_filter_v1" version="1">
+    <description summary="keyboard event filtering functionality">
+      Manages the filtering of key presses.
+    </description>
+    
+    <enum name="error">
+      <entry name="invalid_serial" value="0x1" summary="compositor received serial not adhering to requirements"/>
+    </enum>
+
+    <request name="unbind">
+      <description summary="Stop intercepting">
+        Unbind the keyboard and stop intercepting events.
+
+        Unbinds the bound keyboard and the input method. the compositor must stop redirecting keyboard events. Events that the keyboard_filter client has not yet responded to are treated as if they received the "passthrough" action.
+
+        This request takes effect immediately.
+      </description>
+    </request>
+
+    <enum name="filter_action">
+      <entry name="consume" value="0" summary="consume the key event"/>
+      <entry name="passthrough" value="1" summary="pass the key event to the text input client"/>
+    </enum>
+    
+    <request name="filter">
+      <description summary="decide the processing of a keyboard event">
+        This request controls the filtering of keyboard input events before reaching the focused surface.
+        
+        Usage:
+
+        While keyboard_filter is intercepting, the compositor must send every intercepted event to its bound wl_keyboard, and hold a copy of it in an internal queue.
+        When the client responds with the .filter request, the compositor either removes the event from the queue (filter_action.consume), or sends the copy to the original wl_keyboard objects (filter_action.passthrough).
+
+        The compositor must process .filter the oldest event in the queue before processing more recent ones.
+        For this reason, the client sets the argument "serial" to the serial of the corresponding event it received.
+        
+        Exceptions:
+
+        If the event is other than wl_keyboard.key or contains no serial, it cannot be filtered. The keyboard_filter client must not respond to it with .filter request. When such an event is oldest in the queue, the compositor must proceed as if the event had received a "passthrough" reply.
+
+        As of wl_keyboard v10 and keyboard_filter_v1, the only event that can be filtered is the wl_keyboard.key event.
+        
+        Sequence:
+
+        The wl_keyboard begins to receive events after input_method.activate is committed.
+        The valid serial is the serial of the oldest wl_keyboard event which has been sent after input_method.activate but which hasn't yet received a .filter confirmation.
+        The compositor may raise the invalid_serial error in response to events with serials it had not issued.
+        The compositor must ignore events with all other serials. (Particularly, this means events with repeating serials are accepted normally and are not ignored).
+        Events must be filtered in order of arrival.
+      </description>
+      <arg name="serial" type="uint"/>
+      <arg name="action" type="uint" enum="filter_action"/>
+    </request>
+
+    <request name="destroy" type="destructor">
+      <description summary="destroy the keyboard">
+        Destroys the keyboard_filter object, stops event interception, and unbinds the wl_keyboard and input_method objects bound to it.
+      </description>
+    </request>
+  </interface>
+
+  <interface name="xx_keyboard_filter_manager_v1" version="1">    
+    <enum name="error">
+      <entry name="already_bound" value="0x1" summary="an argument is already bound"/>
+      <entry name="wrong_seat" value="0x2" summary="the keyboard i attached to the wrong seat for this operation"/>
+    </enum>
+
+    <request name="bind_to_input_method">
+      <description summary="Bind a keyboard to an input method">
+        Bind a keyboard to an input method for the purpose of capturing key presses before they reach the text input client.
+
+        When a wl_keyboard is bound, the compositor must redirect to it the input events intended for the focused surface with text input enabled. The wl_keyboard instance receives no other events from then on.
+        See keyboard_filter.filter.
+        
+        For the bound wl_keyboard instance to intercept events, the following conditions must be fulfilled:
+        - there's a focused surface,
+        - the surface has an enabled text input object,
+        - the bound input method is active (for the meaning of "active", see input_method.activate, input_method.deactivate).
+        
+        When those conditions are fulfilled, the compositor must start redirecting input events intended for the text input surface to the wl_keyboard bound with this request. Otherwise, the text input surface receives events without intercepting them.
+
+        Be aware that the text input client might use a wl_keyboard object(s) of different version(s) than the one used by the input method. The compositor should issue events as it would normally do for the versions in question. This protocol assumes that events to multiple keyboards of different protocol versions are equivalent.
+
+        Background:
+
+        Whenever the input method is activated, the compositor must start sending it keyboard events intended for the text-input client, so that the input method can be controlled using a keyboard.
+        Traditionally, from the user perspective, input methods receive keys as if they were an overlay: keys which are interesting to the input method gain a special input method meaning, all others work as usual.
+        The binding and the keyboard_filter.filter request together make this possible by letting the input method indicate which events it is interested in.
+
+        Conceptually, when a wl_keyboard is bound to an input_method, the compositor prevents all keyboard events directed to the text input client from reaching it. They are delayed until the input method decides how to filter them using the keyboard_filter.filter request.
+
+        Arguments:
+
+        The wl_keyboard must not be already bound to another interface.
+        The wl_keyboard must only receive events between committed .activate and .deactivate.
+
+        The surface argument represents an arbitrary wl_surface. When issuing wl_keyboard.enter and wl_keyboard.leave on the bound wl_keyboard, the compositor must replace the original surface argument with the one provided by the input method in this request.
+
+        Because the wl_keyboard.enter and wl_keyboard.leave events require a surface as the target, one must be provided even if the input method doesn't display one. A dummy one is sufficient. The provided wl_surface will not be used for any other purpose than explained above.
+        
+        The surface must outlive the input method.
+
+        NOTE: This feature works much better with compositor-side key repeat introduced in wl_seat version 10. This protocol doesn't provide controls for filtering repeat key events generated client-side.
+        A compositor implementing this protocol should implement compositor-side key repeat.
+
+        This request takes effect immediately.
+
+        Attempting to bind a keyboard to an input method which is already bound must cause the already_bound error.
+        Attempting to bind a keyboard object which was already bound must cause the already_bound error.
+        Attempting to bind a keyboard object to an input method acting on a different seat must cause the wrong_seat error.
+        
+        When the input method gets destroyed, the compositor must stop issuing events to the keyboard and ignore any further requests to keyboard_filter, except keyboard_filter.destroy.
+      </description>
+      <arg name="keyboard" type="object" interface="wl_keyboard" />
+      <arg name="input_method" type="object" interface="xx_input_method_v1" />
+      <arg name="surface" type="object" interface="wl_surface" />
+      <arg name="extensions" type="new_id" interface="xx_keyboard_filter_v1"/>
+    </request>
+
+    <request name="destroy" type="destructor">
+      <description summary="destroy the input method manager">
+        Destroys the xx_keyboard_filter_manager_v1 object.
+
+        The xx_keyboard_filter_v1 objects originating from it remain unaffected.
+      </description>
+    </request>
+  </interface>
+</protocol>

experimental/xx-text-input/xx-text-input-v3.xml

@@ -47,7 +47,7 @@
     interface version number is reset.
   </description>
 
-  <interface name="xx_text_input_v3" version="1">
+  <interface name="xx_text_input_v3" version="2">
     <description summary="text input">
       The xx_text_input_v3 interface represents text input and input methods
       associated with a seat. It provides enter/leave events to follow the
@@ -103,7 +103,8 @@
         This request resets all state associated with previous enable, disable,
         set_surrounding_text, set_text_change_cause, set_content_type, and
         set_cursor_rectangle requests, as well as the state associated with
-        preedit_string, commit_string, and delete_surrounding_text events.
+        preedit_string, commit_string, delete_surrounding_text, and action
+        events.
 
         The set_surrounding_text, set_content_type and set_cursor_rectangle
         requests must follow if the text input supports the necessary
@@ -401,11 +402,49 @@
       <arg name="after_length" type="uint" summary="length of text after current cursor position"/>
     </event>
 
+    <event name="move_cursor" since="2">
+      <description summary="move cursor and change selection">
+        Unselects text, moves the cursor and selects text.
+
+        This is equivalent to dragging the mouse over some text: it deselects whatever might be currently selected and selects a new range of text.
+
+        The offsets used in arguments are in bytes relative to the current cursor position. Cursor is the new position of the cursor, and anchor is the opposite end of selection. If there's no selection, anchor should be equal to cursor.
+        In terms of dragging the mouse, the anchor is the start, and cursor the end.
+        
+        The offsets do not take preedit contents into account, nor is preedit changed in any way with this request.
+        
+        Both cursor and anchor must fall on code point boundaries, otherwise text input client may ignore the request. It is therefore not recommended for an input method to move any of them beyond the text received in surrounding_text.
+        <!-- Code point boundary checking must happen in the application because no one else is obliged to track the contents.
+        There are two ways to handle it:
+        
+        1. add a request from the application informing the compositor of the mistake, so that the compositor can send an error and crash the input method, giving it the chance to reset and go back to normal
+        2. just ignore the request and hope the input method can resynchronize through surrounding_text
+        
+        Choosing 2. because it's easier to implement.
+        -->
+
+        When surrounding_text is not supported, the offsets must not be interpreted as bytes, but as some human-readable unit at least as big as a code point, for example a grapheme.
+        
+        The cursor and anchor arguments can also take the following special values:
+        BEGINNING := 0x8000_0000 = i32::MIN
+        END := 0x7fff_ffff = i32::MAX
+        meaning, respectively, the beginning and the end of of all text in the input field.
+
+        Values set with this event are double-buffered. They must be applied
+        and reset to initial on the next commit request.
+
+        The initial values of both cursor and anchor are 0.
+      </description>
+      <arg name="cursor" type="int"/>
+      <arg name="anchor" type="int"/>
+    </event>
+    
     <event name="done">
       <description summary="apply changes">
         Instruct the application to apply changes to state requested by the
-        preedit_string, commit_string and delete_surrounding_text events. The
-        state relating to these events is double-buffered, and each one
+        preedit_string, commit_string delete_surrounding_text, and action
+        events.
+        The state relating to these events is double-buffered, and each one
         modifies the pending state. This event replaces the current state with
         the pending state.
 
@@ -415,9 +454,11 @@
         1. Replace existing preedit string with the cursor.
         2. Delete requested surrounding text.
         3. Insert commit string with the cursor at its end.
-        4. Calculate surrounding text to send.
-        5. Insert new preedit text in cursor position.
-        6. Place cursor inside preedit text.
+        4. Move the cursor and selection.
+        5. Calculate surrounding text to send.
+        6. Insert new preedit text in cursor position.
+        7. Place cursor inside preedit text.
+        8. Perform the requested action.
 
         The serial number reflects the last state of the xx_text_input_v3
         object known to the compositor. The value of the serial argument must
@@ -433,9 +474,86 @@
       </description>
       <arg name="serial" type="uint"/>
     </event>
+
+    <enum name="action" since="2">
+      <description summary="action">
+        A possible action to perform on a text input.
+      </description>
+      <!-- Notably missing: moving cursor, deleting and setting a selection. They are nicer to use as part of the text manipulation interface: ranges can be selected there.
+      Exceptions: the IME doesn't know where lines start or end. The IME will not get to see the entire 4MB document so it can't select all through the text interface. But this doesn't seem urgent. -->
+
+      <!-- types of finish actions are better communicated as a hint: this triggers a URL navigation, this sends a search query, this sends a message, etc. The input method can then choose the appropriate buttons to display -->
+      <entry name="finish" value="0">
+        <description summary="trigger appropriate action for the completion of editing">
+          This should be triggered when the user is done with editing the field and wants to move on. For example, the query was typed and the user wants the search result. Or the name was entered and the address needs to be typed next.
+
+          The action to perform depends on the application, and should match the value of the current content_purpose.
+
+          All clients SHOULD implement this action. Without it, on-screen keyboards don't work as expected.
+        </description>
+      </entry>
+    </enum>
+    
+    <event name="perform_action" since="2">
+      <description summary="action performed">
+        The input method issued an action to perform on this text input.
+
+        Values set with this event are double-buffered. They must be applied
+        and reset to initial on the next .done event.
+
+        The initial value of action is none.
+      </description>
+      <arg name="action" type="uint" enum="action" summary="action performed"/>
+    </event>
+
+    <request name="set_available_actions" since="2">
+      <description summary="announce the available actions">
+        Announces the actions available for the currently active text input.
+
+        Values set with this event are double-buffered. They will get applied
+        on the next .done event.
+        They get reset to the initial value on the next committed deactivate event.
+
+        The initial value is an empty set: no actions are available.
+        
+        Values in the available_actions array come from text-input-v3.action.
+      </description>
+      <!-- Removed the protocol error on none and duplicates because a client has no interest in crashing for slight compositor misbehaviour. Ignoring extraneous values should not be a problem for any half-competent library. -->
+      <arg name="available_actions" type="array" summary="available actions"/>
+      <!-- Should this be a bitmap instead of an array? 32 generic actions should be enough, and client-specific actions would need a new protocol anyway -->
+    </request>
+    
+    <enum name="supported_features" bitfield="true" since="2">
+      <description summary="possible supported features">
+        Client functionality over the baseline that isn't indicated implicitly.
+
+        This does not include events coming with .enable: when the input method receives such an event, it is clear the text input supports it, e.g. content_type, available_actions.
+
+        Baseline functionality like commit_string, set_preedit_string must always be supported for the protocol to be useful.
+        
+        The flags match text-input protocol versions, but should be kept general enough to support other protocols.
+      </description>
+      <entry name="none" value="0x0" summary="no extra functionality supported"/>
+      <entry name="move_cursor" value="0x1" summary="the move_cursor request"/>
+    </enum>
+    
+    <request name="announce_supported_features" since="2">
+      <description summary="announce extra supported features">
+        Notifies the input method what the currently active text input client is able to do.
+
+        This event should come within the same .done sequence as .activate. Otherwise, the input method may ignore it.
+        
+        Values set with this event are double-buffered. They will get applied
+        on the next .done event.
+        They get reset to initial on the next committed deactivate event.
+
+        The initial value for features is none.
+      </description>
+      <arg name="features" type="uint" enum="xx_text_input_v3.supported_features"/>
+    </request>
   </interface>
 
-  <interface name="xx_text_input_manager_v3" version="1">
+  <interface name="xx_text_input_manager_v3" version="2">
     <description summary="text input manager">
       A factory for text-input objects. This object is a global singleton.
     </description>

meson.build

@@ -1,5 +1,5 @@
 project('wayland-protocols',
-	version: '1.46',
+	version: '1.47',
 	meson_version: '>= 0.58.0',
 	license: 'MIT/Expat',
 )
@@ -79,6 +79,7 @@ staging_protocols = {
 
 experimental_protocols = {
 	'xx-input-method': ['v2'],
+	'xx-keyboard-filter': ['v1'],
 	'xx-session-management': ['v1'],
 	'xx-text-input': ['v3'],
 }
@@ -158,34 +159,29 @@ if dep_scanner.version().version_compare('>=1.22.90')
 	include_dirs = ['include']
 endif
 
-wayland_protocols_srcdir = meson.current_source_dir()
+pkgconfig = import('pkgconfig')
 
-pkgconfig_configuration = configuration_data()
-pkgconfig_configuration.set('prefix', get_option('prefix'))
-pkgconfig_configuration.set('includedir', '${prefix}/@0@'.format(get_option('includedir')))
-pkgconfig_configuration.set('datarootdir', '${prefix}/@0@'.format(get_option('datadir')))
-pkgconfig_configuration.set('abs_top_srcdir', wayland_protocols_srcdir)
-pkgconfig_configuration.set('PACKAGE', 'wayland-protocols')
-pkgconfig_configuration.set('WAYLAND_PROTOCOLS_VERSION', wayland_protocols_version)
-
-pkg_install_dir = join_paths(get_option('datadir'), 'pkgconfig')
-configure_file(
-	input: 'wayland-protocols.pc.in',
-	output: 'wayland-protocols.pc',
-	configuration: pkgconfig_configuration,
-	install_dir: pkg_install_dir,
-)
-
-configure_file(
-	input: 'wayland-protocols-uninstalled.pc.in',
-	output: 'wayland-protocols-uninstalled.pc',
-	configuration: pkgconfig_configuration,
+pkgconfig.generate(
+	filebase: 'wayland-protocols',
+	name: 'Wayland Protocols',
+	description: 'Wayland protocol files',
+	dataonly: true,
+	variables: {
+		'prefix': get_option('prefix'),
+		'includedir': '${prefix}/@0@'.format(get_option('includedir')),
+		'datarootdir': '${prefix}/@0@'.format(get_option('datadir')),
+		'pkgdatadir': '${pc_sysrootdir}${datarootdir}/wayland-protocols'
+	},
+	uninstalled_variables: {
+		'includedir': meson.current_build_dir() / 'include',
+		'pkgdatadir': meson.project_source_root(),
+	},
 )
 
 wayland_protocols = declare_dependency(
 	include_directories: include_dirs,
 	variables: {
-		'pkgdatadir': wayland_protocols_srcdir,
+		'pkgdatadir': meson.project_source_root(),
 	},
 	sources: headers,
 )

staging/color-management/appendix.md

@@ -53,6 +53,22 @@ The above are specified by [ITU-R BT.1886].
 Note, that $`E < 0`$ and $`E > 1`$ are possible with limited range
 quantization, as required by e.g. the calibration method in [ITU-R BT.814].
 
+### `compound_power_2_4`
+
+```math
+O = \begin{cases}
+\frac{E}{12.92}, & 0 \leq E < 0.04045\\
+\left( \frac{E + 0.055}{1.055} \right)^{2.4}, & 0.04045 \leq E \leq 1
+\end{cases}
+```
+
+The above is the IEC 61966-2-1 piece-wise transfer function,
+as recorded in [Khronos Data Format Specification][KDFS] 1.4.0
+Section 13.3, and restricted to the unit range.
+
+```math
+L = (L_W - L_B)O + L_B
+```
 
 ### `gamma22`
 
@@ -125,3 +141,4 @@ L = 10'000\ \mathrm{cd/m²} \cdot O + L_B
 [ITU-R BT.814]: https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/specs.md#itu-r-bt814
 [ITU-R BT.1886]: https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/specs.md#itu-r-bt1886
 [ITU-R BT.2100]: https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/specs.md#itu-r-bt2100
+[KDFS]: https://registry.khronos.org/DataFormat/

staging/color-management/color-management-v1.xml

@@ -77,7 +77,7 @@
     only be done by creating a new major version of the extension.
   </description>
 
-  <interface name="wp_color_manager_v1" version="1">
+  <interface name="wp_color_manager_v1" version="2">
     <description summary="color manager singleton">
       A singleton global interface used for getting color management extensions
       for wl_surface and wl_output objects, and for creating client defined
@@ -124,6 +124,14 @@
              summary="ICC-absolute colorimetric"/>
       <entry name="relative_bpc" value="4"
              summary="media-relative colorimetric + black point compensation"/>
+      <entry name="absolute_no_adaptation" value="5" since="2">
+        <description summary="ICC-absolute colorimetric without adaptation">
+          This rendering intent is a modified absolute rendering intent that
+          assumes the viewer is not adapted to the display white point, so no
+          chromatic adaptation between surface and display is done.
+          This can be useful for color proofing applications.
+        </description>
+      </entry>
     </enum>
 
     <enum name="feature">
@@ -280,8 +288,7 @@
           - United States Federal Communications Commission (2003) Title 47 Code
             of Federal Regulations 73.682 (a) (20)
           - Rec. ITU-R BT.1700-0 625 PAL and 625 SECAM
-
-          Note: an sRGB display (IEC 61966-2-1) uses this transfer function.
+          - IEC 61966-2-1 (reference display)
         </description>
       </entry>
       <entry name="gamma28" value="3">
@@ -318,18 +325,18 @@
           - IEC 61966-2-4
         </description>
       </entry>
-      <entry name="srgb" value="9">
-        <description summary="sRGB piece-wise transfer function">
+      <entry name="srgb" value="9" deprecated-since="2">
+        <description summary="Deprecated (ambiguous sRGB transfer function)">
           Transfer characteristics as defined by
           - IEC 61966-2-1 sRGB
 
-          Note: This is not appropriate for describing sRGB material.
-          sRGB material is intended to be viewed on an sRGB display, and
-          that is described by gamma22.
+          As a rule of thumb, use gamma22 for video, motion picture and
+          computer graphics, or compound_power_2_4 for ICC calibrated print
+          workflows.
         </description>
       </entry>
-      <entry name="ext_srgb" value="10">
-        <description summary="Extended sRGB piece-wise transfer function">
+      <entry name="ext_srgb" value="10" deprecated-since="2">
+        <description summary="Deprecated (Extended sRGB piece-wise transfer function)">
           Transfer characteristics as defined by
           - IEC 61966-2-1 sYCC
         </description>
@@ -379,6 +386,12 @@
           ARIB STD-B67 or BT.2100.
         </description>
       </entry>
+      <entry name="compound_power_2_4" value="14" since="2">
+        <description summary="IEC 61966-2-1 encoding function">
+          Encoding characteristics as defined by IEC 61966-2-1, for displays
+          that invert the encoding function.
+        </description>
+      </entry>
     </enum>
 
     <request name="get_output">
@@ -512,6 +525,9 @@
       <description summary="supported rendering intent">
         When this object is created, it shall immediately send this event once
         for each rendering intent the compositor supports.
+
+        A compositor must not advertise intents that are deprecated in the
+        bound version of the interface.
       </description>
 
       <arg name="render_intent" type="uint" enum="render_intent"
@@ -522,6 +538,9 @@
       <description summary="supported features">
         When this object is created, it shall immediately send this event once
         for each compositor supported feature listed in the enumeration.
+
+        A compositor must not advertise features that are deprecated in the
+        bound version of the interface.
       </description>
 
       <arg name="feature" type="uint" enum="feature"
@@ -533,6 +552,9 @@
         When this object is created, it shall immediately send this event once
         for each named transfer function the compositor supports with the
         parametric image description creator.
+
+        A compositor must not advertise transfer functions that are deprecated
+        in the bound version of the interface.
       </description>
 
       <arg name="tf" type="uint" enum="transfer_function"
@@ -544,6 +566,9 @@
         When this object is created, it shall immediately send this event once
         for each named set of primaries the compositor supports with the
         parametric image description creator.
+
+        A compositor must not advertise names that are deprecated in the
+        bound version of the interface.
       </description>
 
       <arg name="primaries" type="uint" enum="primaries"
@@ -556,9 +581,23 @@
         transfer functions and named primaries have been sent.
       </description>
     </event>
+
+    <request name="get_image_description" since="2">
+      <description summary="create an image description from a reference">
+        This request retrieves the image description backing a reference.
+
+        The get_information request can be used if and only if the request that
+        creates the reference allows it.
+      </description>
+
+      <arg name="image_description"
+           type="new_id" interface="wp_image_description_v1"/>
+      <arg name="reference"
+           type="object" interface="wp_image_description_reference_v1"/>
+    </request>
   </interface>
 
-  <interface name="wp_color_management_output_v1" version="1">
+  <interface name="wp_color_management_output_v1" version="2">
     <description summary="output color properties">
       A wp_color_management_output_v1 describes the color properties of an
       output.
@@ -628,7 +667,7 @@
     </request>
   </interface>
 
-  <interface name="wp_color_management_surface_v1" version="1">
+  <interface name="wp_color_management_surface_v1" version="2">
     <description summary="color management extension to a surface">
         A wp_color_management_surface_v1 allows the client to set the color
         space and HDR properties of a surface.
@@ -716,7 +755,7 @@
     </request>
   </interface>
 
-  <interface name="wp_color_management_surface_feedback_v1" version="1">
+  <interface name="wp_color_management_surface_feedback_v1" version="2">
     <description summary="color management extension to a surface">
         A wp_color_management_surface_feedback_v1 allows the client to get the
         preferred image description of a surface.
@@ -739,27 +778,14 @@
              summary="attempted to use an unsupported feature"/>
     </enum>
 
-    <event name="preferred_changed">
-      <description summary="the preferred image description changed">
-        The preferred image description is the one which likely has the most
-        performance and/or quality benefits for the compositor if used by the
-        client for its wl_surface contents. This event is sent whenever the
-        compositor changes the wl_surface's preferred image description.
-
-        This event sends the identity of the new preferred state as the argument,
-        so clients who are aware of the image description already can reuse it.
-        Otherwise, if the client client wants to know what the preferred image
-        description is, it shall use the get_preferred request.
-
-        The preferred image description is not automatically used for anything.
-        It is only a hint, and clients may set any valid image description with
-        set_image_description, but there might be performance and color accuracy
-        improvements by providing the wl_surface contents in the preferred
-        image description. Therefore clients that can, should render according
-        to the preferred image description
+    <event name="preferred_changed" deprecated-since="2">
+      <description summary="the preferred image description changed (32-bit)">
+        Starting from interface version 2, 'preferred_changed2' is sent instead
+        of this event. See the 'preferred_changed2' event for the definition.
       </description>
 
-      <arg name="identity" type="uint" summary="image description id number"/>
+      <arg name="identity" type="uint"
+           summary="the 32-bit image description id number"/>
     </event>
 
     <request name="get_preferred">
@@ -816,9 +842,38 @@
       <arg name="image_description"
            type="new_id" interface="wp_image_description_v1"/>
     </request>
+
+    <!-- Version 2 additions -->
+
+    <event name="preferred_changed2" since="2">
+      <description summary="the preferred image description changed">
+        The preferred image description is the one which likely has the most
+        performance and/or quality benefits for the compositor if used by the
+        client for its wl_surface contents. This event is sent whenever the
+        compositor changes the wl_surface's preferred image description.
+
+        This event sends the identity of the new preferred state as the argument,
+        so clients who are aware of the image description already can reuse it.
+        Otherwise, if the client client wants to know what the preferred image
+        description is, it shall use the get_preferred request.
+
+        The preferred image description is not automatically used for anything.
+        It is only a hint, and clients may set any valid image description with
+        set_image_description, but there might be performance and color accuracy
+        improvements by providing the wl_surface contents in the preferred
+        image description. Therefore clients that can, should render according
+        to the preferred image description
+      </description>
+
+      <arg name="identity_hi" type="uint"
+           summary="high 32 bits of the 64-bit image description id number"/>
+      <arg name="identity_lo" type="uint"
+           summary="low 32 bits of the 64-bit image description id number"/>
+    </event>
+
   </interface>
 
-  <interface name="wp_image_description_creator_icc_v1" version="1">
+  <interface name="wp_image_description_creator_icc_v1" version="2">
     <description summary="holder of image description ICC information">
       This type of object is used for collecting all the information required
       to create a wp_image_description_v1 object from an ICC file. A complete
@@ -934,7 +989,7 @@
     </request>
   </interface>
 
-  <interface name="wp_image_description_creator_params_v1" version="1">
+  <interface name="wp_image_description_creator_params_v1" version="2">
     <description summary="holder of image description parameters">
       This type of object is used for collecting all the parameters required
       to create a wp_image_description_v1 object. A complete set of required
@@ -1005,14 +1060,16 @@
         complete, the protocol error incomplete_set is raised. For the
         definition of a complete set, see the description of this interface.
 
-        The protocol error invalid_luminance is raised if any of the following
-        requirements is not met:
+        When both max_cll and max_fall are set, max_fall must be less or equal
+        to max_cll otherwise the invalid_luminance protocol error is raised.
+
+        In version 1, these following conditions also result in the
+        invalid_luminance protocol error. Version 2 and later do not have this
+        requirement.
         - When max_cll is set, it must be greater than min L and less or equal
           to max L of the mastering luminance range.
         - When max_fall is set, it must be greater than min L and less or equal
           to max L of the mastering luminance range.
-        - When both max_cll and max_fall are set, max_fall must be less or equal
-          to max_cll.
 
         If the particular combination of the parameter set is not supported
         by the compositor, the resulting image description object shall
@@ -1306,7 +1363,7 @@
     </request>
   </interface>
 
-  <interface name="wp_image_description_v1" version="1">
+  <interface name="wp_image_description_v1" version="2">
     <description summary="Colorimetric image description">
       An image description carries information about the pixel color encoding
       and its intended display and viewing environment. The image description is
@@ -1383,38 +1440,22 @@
            summary="ad hoc human-readable explanation"/>
     </event>
 
-    <event name="ready">
-      <description summary="indication that the object is ready to be used">
-        Once this event has been sent, the wp_image_description_v1 object is
-        deemed "ready". Ready objects can be used to send requests and can be
-        used through other interfaces.
+    <event name="ready" deprecated-since="2">
+      <description summary="the object is ready to be used (32-bit)">
+        Starting from interface version 2, the 'ready2' event is sent instead
+        of this event.
 
-        Every ready wp_image_description_v1 protocol object refers to an
-        underlying image description record in the compositor. Multiple protocol
-        objects may end up referring to the same record. Clients may identify
-        these "copies" by comparing their id numbers: if the numbers from two
-        protocol objects are identical, the protocol objects refer to the same
-        image description record. Two different image description records
-        cannot have the same id number simultaneously. The id number does not
-        change during the lifetime of the image description record.
+        For the definition of this event, see the 'ready2' event. The
+        difference to this event is as follows.
 
         The id number is valid only as long as the protocol object is alive. If
         all protocol objects referring to the same image description record are
         destroyed, the id number may be recycled for a different image
         description record.
-
-        Image description id number is not a protocol object id. Zero is
-        reserved as an invalid id number. It shall not be possible for a client
-        to refer to an image description by its id number in protocol. The id
-        numbers might not be portable between Wayland connections. A compositor
-        shall not send an invalid id number.
-
-        This identity allows clients to de-duplicate image description records
-        and avoid get_information request if they already have the image
-        description information.
       </description>
 
-      <arg name="identity" type="uint" summary="image description id number"/>
+      <arg name="identity" type="uint"
+           summary="the 32-bit image description id number"/>
     </event>
 
     <request name="get_information">
@@ -1431,9 +1472,45 @@
       <arg name="information"
            type="new_id" interface="wp_image_description_info_v1"/>
     </request>
+
+    <!-- Version 2 additions -->
+
+    <event name="ready2" since="2">
+      <description summary="the object is ready to be used">
+        Once this event has been sent, the wp_image_description_v1 object is
+        deemed "ready". Ready objects can be used to send requests and can be
+        used through other interfaces.
+
+        Every ready wp_image_description_v1 protocol object refers to an
+        underlying image description record in the compositor. Multiple protocol
+        objects may end up referring to the same record. Clients may identify
+        these "copies" by comparing their id numbers: if the numbers from two
+        protocol objects are identical, the protocol objects refer to the same
+        image description record. Two different image description records
+        cannot have the same id number simultaneously. The id number does not
+        change during the lifetime of the image description record.
+
+        Image description id number is not a protocol object id. Zero is
+        reserved as an invalid id number. It shall not be possible for a client
+        to refer to an image description by its id number in protocol. The id
+        numbers might not be portable between Wayland connections. A compositor
+        shall not send an invalid id number.
+
+        Compositors must not recycle image description id numbers.
+
+        This identity allows clients to de-duplicate image description records
+        and avoid get_information request if they already have the image
+        description information.
+      </description>
+
+      <arg name="identity_hi" type="uint"
+           summary="high 32 bits of the 64-bit image description id number"/>
+      <arg name="identity_lo" type="uint"
+           summary="low 32 bits of the 64-bit image description id number"/>
+    </event>
   </interface>
 
-  <interface name="wp_image_description_info_v1" version="1">
+  <interface name="wp_image_description_info_v1" version="2">
     <description summary="Colorimetric image description information">
       Sends all matching events describing an image description object exactly
       once and finally sends the 'done' event.
@@ -1626,4 +1703,22 @@
            summary="Maximum frame-average light level (cd/m²)"/>
     </event>
   </interface>
+
+  <interface name="wp_image_description_reference_v1" version="1">
+    <description summary="Reference to an image description">
+      This object is a reference to an image description. This interface is
+      frozen at version 1 to allow other protocols to create
+      wp_image_description_v1 objects.
+
+      The wp_color_manager_v1.get_image_description request can be used to
+      retrieve the underlying image description.
+    </description>
+
+    <request name="destroy" type="destructor">
+      <description summary="destroy the reference">
+        Destroy this object. This has no effect on the referenced image
+        description.
+      </description>
+    </request>
+  </interface>
 </protocol>

tests/meson.build

@@ -7,7 +7,7 @@ libwayland = [
 
 # Check that each protocol passes through the scanner
 foreach protocol_file : protocol_files
-	protocol_path = join_paths(wayland_protocols_srcdir, protocol_file)
+	protocol_path = join_paths(meson.project_source_root(), protocol_file)
 	test_name = 'scan-@0@'.format(protocol_file.underscorify())
 	test(test_name, prog_scan_sh,
 		args: protocol_path,
@@ -31,7 +31,7 @@ foreach protocol_file : protocol_files
 	xml_components = xml_file.split('.')
 	protocol_base_file_name = xml_components[0]
 
-	protocol_path = files(join_paths(wayland_protocols_srcdir, protocol_file))
+	protocol_path = files(join_paths(meson.project_source_root(), protocol_file))
 	client_header_path = '@0@-client.h'.format(protocol_base_file_name)
 	server_header_path = '@0@-server.h'.format(protocol_base_file_name)
 	code_path = '@0@-code.c'.format(protocol_base_file_name)

wayland-protocols-uninstalled.pc.in

@@ -1,5 +0,0 @@
-pkgdatadir=@abs_top_srcdir@
-
-Name: Wayland Protocols
-Description: Wayland protocol files (not installed)
-Version: @WAYLAND_PROTOCOLS_VERSION@

wayland-protocols.pc.in

@@ -1,8 +0,0 @@
-prefix=@prefix@
-includedir=@includedir@
-datarootdir=@datarootdir@
-pkgdatadir=${pc_sysrootdir}${datarootdir}/@PACKAGE@
-
-Name: Wayland Protocols
-Description: Wayland protocol files
-Version: @WAYLAND_PROTOCOLS_VERSION@