From f0dbb3d39cb49300285e9e97e1ee2659ead335b6 Mon Sep 17 00:00:00 2001 From: Zheng Junjie Date: Wed, 11 Sep 2024 10:04:31 +0800 Subject: gnu: qtwayland: Fix build. * gnu/packages/patches/qtwayland-update-wayland-xml.patch: new patch. * gnu/local.mk (dist_patch_DATA): Registered it. * gnu/packages/qt.scm (qtwayland)[source]: Use it. Change-Id: I9d48fb905d457fdcb19e0e786a2a10bee2b5a3d3 --- gnu/local.mk | 1 + .../patches/qtwayland-update-wayland-xml.patch | 1287 ++++++++++++++++++++ gnu/packages/qt.scm | 3 +- 3 files changed, 1290 insertions(+), 1 deletion(-) create mode 100644 gnu/packages/patches/qtwayland-update-wayland-xml.patch diff --git a/gnu/local.mk b/gnu/local.mk index 1fbbeedefb..bc89eb6a43 100644 --- a/gnu/local.mk +++ b/gnu/local.mk @@ -2086,6 +2086,7 @@ dist_patch_DATA = \ %D%/packages/patches/qtwayland-dont-recreate-callbacks.patch \ %D%/packages/patches/qtwayland-cleanup-callbacks.patch \ %D%/packages/patches/qtwayland-6-update-wayland-xml.patch \ + %D%/packages/patches/qtwayland-update-wayland-xml.patch \ %D%/packages/patches/ragel-char-signedness.patch \ %D%/packages/patches/randomjungle-disable-static-build.patch \ %D%/packages/patches/rapidcheck-fix-libs.patch \ diff --git a/gnu/packages/patches/qtwayland-update-wayland-xml.patch b/gnu/packages/patches/qtwayland-update-wayland-xml.patch new file mode 100644 index 0000000000..6d60a9bc86 --- /dev/null +++ b/gnu/packages/patches/qtwayland-update-wayland-xml.patch @@ -0,0 +1,1287 @@ +from https://salsa.debian.org/qt-kde-team/qt/qtwayland/-/blob/3f43cd57cdf7b2c1e029a6104cb1835ac08b8b34/debian/patches/wayland_1.23.diff + +Description: update wayland.xml to version 1.23.0 + This updates only the protocol definition, implementations + will need additional commits to opt into using them. +Origin: upstream, https://code.qt.io/cgit/qt/qtwayland.git/commit/?id=c2f61bc47baacf2e +Last-Update: 2024-07-30 + +--- a/src/3rdparty/protocol/wayland.xml ++++ b/src/3rdparty/protocol/wayland.xml +@@ -46,7 +46,7 @@ + compositor after the callback is fired and as such the client must not + attempt to use it after that point. + +- The callback_data passed in the callback is the event serial. ++ The callback_data passed in the callback is undefined and should be ignored. + + +@@ -91,18 +91,20 @@ + + ++ summary="method doesn't exist on the specified interface or malformed request"/> + ++ + + + + + This event is used internally by the object ID management +- logic. When a client deletes an object, the server will send +- this event to acknowledge that it has seen the delete request. +- When the client receives this event, it will know that it can +- safely reuse the object ID. ++ logic. When a client deletes an object that it had created, ++ the server will send this event to acknowledge that it has ++ seen the delete request. When the client receives this event, ++ it will know that it can safely reuse the object ID. + + + +@@ -175,9 +177,12 @@ + + Clients can handle the 'done' event to get notified when + the related request is done. ++ ++ Note, because wl_callback objects are created from multiple independent ++ factory interfaces, the wl_callback interface is frozen at version 1. + + +- ++ + + Notify the client when the related request is done. + +@@ -185,7 +190,7 @@ + + + +- ++ + + A compositor. This object is a singleton global. The + compositor is in charge of combining the contents of multiple +@@ -207,7 +212,7 @@ + + + +- ++ + + The wl_shm_pool object encapsulates a piece of memory shared + between the compositor and client. Through the wl_shm_pool +@@ -256,12 +261,18 @@ + for the pool from the file descriptor passed when the pool was + created, but using the new size. This request can only be + used to make the pool bigger. ++ ++ This request only changes the amount of bytes that are mmapped ++ by the server and does not touch the file corresponding to the ++ file descriptor passed at creation time. It is the client's ++ responsibility to ensure that the file is at least as big as ++ the new pool size. + + + + + +- ++ + + A singleton global object that provides support for shared + memory. +@@ -269,8 +280,8 @@ + Clients can create wl_shm_pool objects using the create_pool + request. + +- At connection setup time, the wl_shm object emits one or more +- format events to inform clients about the valid pixel formats ++ On binding the wl_shm object one or more format events ++ are emitted to inform clients about the valid pixel formats + that can be used for buffers. + + +@@ -291,10 +302,15 @@ + formats are optional and may not be supported by the particular + renderer in use. + +- The drm format codes match the macros defined in drm_fourcc.h. +- The formats actually supported by the compositor will be +- reported by the format event. ++ The drm format codes match the macros defined in drm_fourcc.h, except ++ argb8888 and xrgb8888. The formats actually supported by the compositor ++ will be reported by the format event. ++ ++ For all wl_shm formats and unless specified in another protocol ++ extension, pre-multiplied alpha is used for pixel values. + ++ + + + +@@ -353,6 +369,71 @@ + + + ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ + + + +@@ -376,15 +457,36 @@ + + + ++ ++ ++ ++ ++ ++ Using this request a client can tell the server that it is not going to ++ use the shm object anymore. ++ ++ Objects created via this interface remain unaffected. ++ ++ + + + + + A buffer provides the content for a wl_surface. Buffers are +- created through factory interfaces such as wl_drm, wl_shm or +- similar. It has a width and a height and can be attached to a +- wl_surface, but the mechanism by which a client provides and +- updates the contents is defined by the buffer factory interface. ++ created through factory interfaces such as wl_shm, wp_linux_buffer_params ++ (from the linux-dmabuf protocol extension) or similar. It has a width and ++ a height and can be attached to a wl_surface, but the mechanism by which a ++ client provides and updates the contents is defined by the buffer factory ++ interface. ++ ++ Color channels are assumed to be electrical rather than optical (in other ++ words, encoded with a transfer function) unless otherwise specified. If ++ the buffer uses a format that has an alpha channel, the alpha channel is ++ assumed to be premultiplied into the electrical color channel values ++ (after transfer function encoding) unless otherwise specified. ++ ++ Note, because wl_buffer objects are created from multiple independent ++ factory interfaces, the wl_buffer interface is frozen at version 1. + + + +@@ -507,6 +609,9 @@ + this request after a NULL mime type has been set in + wl_data_offer.accept or no action was received through + wl_data_offer.action. ++ ++ If wl_data_offer.finish request is received for a non drag and drop ++ operation, the invalid_finish protocol error is raised. + + + +@@ -523,7 +628,7 @@ + + This request determines the final result of the drag-and-drop + operation. If the end result is that no action is accepted, +- the drag source will receive wl_drag_source.cancelled. ++ the drag source will receive wl_data_source.cancelled. + + The dnd_actions argument must contain only values expressed in the + wl_data_device_manager.dnd_actions enum, and the preferred_action +@@ -544,17 +649,21 @@ + This request can only be made on drag-and-drop offers, a protocol error + will be raised otherwise. + +- +- ++ ++ + + + + + This event indicates the actions offered by the data source. It +- will be sent right after wl_data_device.enter, or anytime the source +- side changes its offered actions through wl_data_source.set_actions. ++ will be sent immediately after creating the wl_data_offer object, ++ or anytime the source side changes its offered actions through ++ wl_data_source.set_actions. + +- ++ + + + +@@ -595,7 +704,8 @@ + final wl_data_offer.set_actions and wl_data_offer.accept requests + must happen before the call to wl_data_offer.finish. + +- ++ + + + +@@ -692,7 +802,8 @@ + wl_data_device.start_drag. Attempting to use the source other than + for drag-and-drop will raise a protocol error. + +- ++ + + + +@@ -748,7 +859,8 @@ + Clients can trigger cursor surface changes from this point, so + they reflect the current action. + +- ++ + + + +@@ -763,6 +875,7 @@ + + + ++ + + + +@@ -774,7 +887,8 @@ + for the eventual data transfer. If source is NULL, enter, leave + and motion events are sent only to the client that initiated the + drag and the client is expected to handle the data passing +- internally. ++ internally. If source is destroyed, the drag-and-drop session will be ++ cancelled. + + The origin surface is the surface where the drag originates and + the client must have an active implicit grab that matches the +@@ -783,17 +897,18 @@ + The icon surface is an optional (can be NULL) surface that + provides an icon to be moved around with the cursor. Initially, + the top-left corner of the icon surface is placed at the cursor +- hotspot, but subsequent wl_surface.attach request can move the ++ hotspot, but subsequent wl_surface.offset requests can move the + relative position. Attach requests must be confirmed with + wl_surface.commit as usual. The icon surface is given the role of + a drag-and-drop icon. If the icon surface already has another role, + it raises a protocol error. + +- The current and pending input regions of the icon wl_surface are +- cleared, and wl_surface.set_input_region is ignored until the +- wl_surface is no longer used as the icon surface. When the use +- as an icon ends, the current and pending input regions become +- undefined, and the wl_surface is unmapped. ++ The input region is ignored for wl_surfaces with the role of a ++ drag-and-drop icon. ++ ++ The given source may not be used in any further set_selection or ++ start_drag requests. Attempting to reuse a previously-used source ++ may send a used_source error. + + + +@@ -807,6 +922,10 @@ + to the data from the source on behalf of the client. + + To unset the selection, set the source to NULL. ++ ++ The given source may not be used in any further set_selection or ++ start_drag requests. Attempting to reuse a previously-used source ++ may send a used_source error. + + + +@@ -818,7 +937,7 @@ + which will subsequently be used in either the + data_device.enter event (for drag-and-drop) or the + data_device.selection event (for selections). Immediately +- following the data_device_data_offer event, the new data_offer ++ following the data_device.data_offer event, the new data_offer + object will send out data_offer.offer events to describe the + mime types it offers. + +@@ -888,9 +1007,10 @@ + immediately before receiving keyboard focus and when a new + selection is set while the client has keyboard focus. The + data_offer is valid until a new data_offer or NULL is received +- or until the client loses keyboard focus. The client must +- destroy the previous selection data_offer, if any, upon receiving +- this event. ++ or until the client loses keyboard focus. Switching surface with ++ keyboard focus within the same client doesn't mean a new selection ++ will be sent. The client must destroy the previous selection ++ data_offer, if any, upon receiving this event. + + +@@ -978,7 +1098,8 @@ + a basic surface. + + Note! This protocol is deprecated and not intended for production use. +- For desktop-style user interfaces, use xdg_shell. ++ For desktop-style user interfaces, use xdg_shell. Compositors and clients ++ should not implement this interface. + + + +@@ -1272,10 +1393,12 @@ + + + +- ++ + +- A surface is a rectangular area that is displayed on the screen. +- It has a location, size and pixel contents. ++ A surface is a rectangular area that may be displayed on zero ++ or more outputs, and shown any number of times at the compositor's ++ discretion. They can present wl_buffers, receive user input, and ++ define a local coordinate system. + + The size of a surface (and relative positions on it) is described + in surface-local coordinates, which may differ from the buffer +@@ -1302,8 +1425,9 @@ + that this request gives a role to a wl_surface. Often, this + request also creates a new protocol object that represents the + role and adds additional functionality to wl_surface. When a +- client wants to destroy a wl_surface, they must destroy this 'role +- object' before the wl_surface. ++ client wants to destroy a wl_surface, they must destroy this role ++ object before the wl_surface, otherwise a defunct_role_object error is ++ sent. + + Destroying the role object does not remove the role from the + wl_surface, but it may stop the wl_surface from "playing the role". +@@ -1321,6 +1445,10 @@ + + + ++ ++ ++ + + + +@@ -1335,14 +1463,23 @@ + + The new size of the surface is calculated based on the buffer + size transformed by the inverse buffer_transform and the +- inverse buffer_scale. This means that the supplied buffer +- must be an integer multiple of the buffer_scale. ++ inverse buffer_scale. This means that at commit time the supplied ++ buffer size must be an integer multiple of the buffer_scale. If ++ that's not the case, an invalid_size error is sent. + + The x and y arguments specify the location of the new pending + buffer's upper left corner, relative to the current buffer's upper + left corner, in surface-local coordinates. In other words, the + x and y, combined with the new surface size define in which +- directions the surface's size changes. ++ directions the surface's size changes. Setting anything other than 0 ++ as x and y arguments is discouraged, and should instead be replaced ++ with using the separate wl_surface.offset request. ++ ++ When the bound wl_surface version is 5 or higher, passing any ++ non-zero x or y is a protocol violation, and will result in an ++ 'invalid_offset' error being raised. The x and y arguments are ignored ++ and do not change the pending state. To achieve equivalent semantics, ++ use wl_surface.offset. + + Surface contents are double-buffered state, see wl_surface.commit. + +@@ -1363,13 +1500,29 @@ + will not receive a release event, and is not used by the + compositor. + ++ If a pending wl_buffer has been committed to more than one wl_surface, ++ the delivery of wl_buffer.release events becomes undefined. A well ++ behaved client should not rely on wl_buffer.release events in this ++ case. Alternatively, a client could create multiple wl_buffer objects ++ from the same backing storage or use wp_linux_buffer_release. ++ + Destroying the wl_buffer after wl_buffer.release does not change +- the surface contents. However, if the client destroys the +- wl_buffer before receiving the wl_buffer.release event, the surface +- contents become undefined immediately. ++ the surface contents. Destroying the wl_buffer before wl_buffer.release ++ is allowed as long as the underlying buffer storage isn't re-used (this ++ can happen e.g. on client process termination). However, if the client ++ destroys the wl_buffer before receiving the wl_buffer.release event and ++ mutates the underlying buffer storage, the surface contents become ++ undefined immediately. + + If wl_surface.attach is sent with a NULL wl_buffer, the + following wl_surface.commit will remove the surface content. ++ ++ If a pending wl_buffer has been destroyed, the result is not specified. ++ Many compositors are known to remove the surface content on the following ++ wl_surface.commit, but this behaviour is not universal. Clients seeking to ++ maximise compatibility should not destroy pending buffers and should ++ ensure that they explicitly remove content from surfaces, even after ++ destroying buffers. + + +@@ -1397,9 +1550,9 @@ + and clears pending damage. The server will clear the current + damage as it repaints the surface. + +- Alternatively, damage can be posted with wl_surface.damage_buffer +- which uses buffer coordinates instead of surface coordinates, +- and is probably the preferred and intuitive way of doing this. ++ Note! New clients should not use this request. Instead damage can be ++ posted with wl_surface.damage_buffer which uses buffer coordinates ++ instead of surface coordinates. + + + +@@ -1509,16 +1662,18 @@ + + Surface state (input, opaque, and damage regions, attached buffers, + etc.) is double-buffered. Protocol requests modify the pending state, +- as opposed to the current state in use by the compositor. A commit +- request atomically applies all pending state, replacing the current +- state. After commit, the new pending state is as documented for each +- related request. +- +- On commit, a pending wl_buffer is applied first, and all other state +- second. This means that all coordinates in double-buffered state are +- relative to the new wl_buffer coming into use, except for +- wl_surface.attach itself. If there is no pending wl_buffer, the +- coordinates are relative to the current surface contents. ++ as opposed to the active state in use by the compositor. ++ ++ A commit request atomically creates a content update from the pending ++ state, even if the pending state has not been touched. The content ++ update is placed in a queue until it becomes active. After commit, the ++ new pending state is as documented for each related request. ++ ++ When the content update is applied, the wl_buffer is applied before all ++ other state. This means that all coordinates in double-buffered state ++ are relative to the newly attached wl_buffers, except for ++ wl_surface.attach itself. If there is no newly attached wl_buffer, the ++ coordinates are relative to the previous content update. + + All requests that need a commit to become effective are documented + to affect double-buffered state. +@@ -1543,6 +1698,12 @@ + This is emitted whenever a surface's creation, movement, or resizing + results in it no longer having any part of it within the scanout region + of an output. ++ ++ Clients should not use the number of outputs the surface is on for frame ++ throttling purposes. The surface might be hidden even if no leave event ++ has been sent, and the compositor might expect new surface content ++ updates even if no enter event has been sent. The frame event should be ++ used instead. + + + +@@ -1551,10 +1712,12 @@ + + + +- This request sets an optional transformation on how the compositor +- interprets the contents of the buffer attached to the surface. The +- accepted values for the transform parameter are the values for +- wl_output.transform. ++ This request sets the transformation that the client has already applied ++ to the content of the buffer. The accepted values for the transform ++ parameter are the values for wl_output.transform. ++ ++ The compositor applies the inverse of this transformation whenever it ++ uses the buffer contents. + + Buffer transform is double-buffered state, see wl_surface.commit. + +@@ -1610,11 +1773,11 @@ + a buffer that is larger (by a factor of scale in each dimension) + than the desired surface size. + +- If scale is not positive the invalid_scale protocol error is ++ If scale is not greater than 0 the invalid_scale protocol error is + raised. + + ++ summary="scale for interpreting buffer contents"/> + + + +@@ -1658,9 +1821,66 @@ + + + ++ ++ ++ ++ ++ ++ The x and y arguments specify the location of the new pending ++ buffer's upper left corner, relative to the current buffer's upper ++ left corner, in surface-local coordinates. In other words, the ++ x and y, combined with the new surface size define in which ++ directions the surface's size changes. ++ ++ Surface location offset is double-buffered state, see ++ wl_surface.commit. ++ ++ This request is semantically equivalent to and the replaces the x and y ++ arguments in the wl_surface.attach request in wl_surface versions prior ++ to 5. See wl_surface.attach for details. ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ This event indicates the preferred buffer scale for this surface. It is ++ sent whenever the compositor's preference changes. ++ ++ Before receiving this event the preferred buffer scale for this surface ++ is 1. ++ ++ It is intended that scaling aware clients use this event to scale their ++ content and use wl_surface.set_buffer_scale to indicate the scale they ++ have rendered with. This allows clients to supply a higher detail ++ buffer. ++ ++ The compositor shall emit a scale value greater than 0. ++ ++ ++ ++ ++ ++ ++ This event indicates the preferred buffer transform for this surface. ++ It is sent whenever the compositor's preference changes. ++ ++ Before receiving this event the preferred buffer transform for this ++ surface is normal. ++ ++ Applying this transformation to the surface buffer contents and using ++ wl_surface.set_buffer_transform might allow the compositor to use the ++ surface buffer more efficiently. ++ ++ ++ + + +- ++ + + A seat is a group of keyboards, pointer and touch devices. This + object is published as a global during start up, or when such a +@@ -1678,6 +1898,14 @@ + + + ++ ++ ++ These errors can be emitted in response to wl_seat requests. ++ ++ ++ ++ + + + This is emitted whenever a seat gains or loses the pointer, +@@ -1716,7 +1944,8 @@ + This request only takes effect if the seat has the pointer + capability, or has had the pointer capability in the past. + It is a protocol violation to issue this request on a seat that has +- never had the pointer capability. ++ never had the pointer capability. The missing_capability error will ++ be sent in this case. + + + +@@ -1729,7 +1958,8 @@ + 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. ++ never had the keyboard capability. The missing_capability error will ++ be sent in this case. + + + +@@ -1742,7 +1972,8 @@ + This request only takes effect if the seat has the touch + capability, or has had the touch capability in the past. + It is a protocol violation to issue this request on a seat that has +- never had the touch capability. ++ never had the touch capability. The missing_capability error will ++ be sent in this case. + + + +@@ -1751,9 +1982,22 @@ + + + +- In a multiseat configuration this can be used by the client to help +- identify which physical devices the seat represents. Based on +- the seat configuration used by the compositor. ++ In a multi-seat configuration the seat name can be used by clients to ++ help identify which physical devices the seat represents. ++ ++ The seat name is a UTF-8 string with no convention defined for its ++ contents. Each name is unique among all wl_seat globals. The name is ++ only guaranteed to be unique for the current compositor instance. ++ ++ The same seat names are used for all clients. Thus, the name can be ++ shared across processes to refer to a specific wl_seat global. ++ ++ The name event is sent after binding to the seat global. This event is ++ only sent once per seat object, and the name does not change over the ++ lifetime of the wl_seat global. ++ ++ Compositors may re-use the same seat name if the wl_seat global is ++ destroyed and re-created later. + + + +@@ -1769,7 +2013,7 @@ + + + +- ++ + + The wl_pointer interface represents one or more input devices, + such as mice, which control the pointer location and pointer_focus +@@ -1804,20 +2048,22 @@ + where (x, y) are the coordinates of the pointer location, in + surface-local coordinates. + +- On surface.attach requests to the pointer surface, hotspot_x ++ On wl_surface.offset requests to the pointer surface, hotspot_x + and hotspot_y are decremented by the x and y parameters +- passed to the request. Attach must be confirmed by ++ passed to the request. The offset must be applied by + wl_surface.commit as usual. + + The hotspot can also be updated by passing the currently set + pointer surface to this request with new values for hotspot_x + and hotspot_y. + +- The current and pending input regions of the wl_surface are +- cleared, and wl_surface.set_input_region is ignored until the +- wl_surface is no longer used as the cursor. When the use as a +- cursor ends, the current and pending input regions become +- undefined, and the wl_surface is unmapped. ++ The input region is ignored for wl_surfaces with the role of ++ a cursor. When the use as a cursor ends, the wl_surface is ++ unmapped. ++ ++ The serial parameter must match the latest wl_pointer.enter ++ serial number sent to the client. Otherwise the request will be ++ ignored. + + + + + +- ++ + + Discrete step information for scroll and other axes. + + This event carries the axis value of the wl_pointer.axis event in + discrete steps (e.g. mouse wheel clicks). + ++ This event is deprecated with wl_pointer version 8 - this event is not ++ sent to clients supporting version 8 or later. ++ + This event does not occur on its own, it is coupled with a + wl_pointer.axis event that represents this axis value on a + continuous scale. The protocol guarantees that each axis_discrete +@@ -2072,7 +2321,8 @@ + axis number within the same wl_pointer.frame. Note that the protocol + allows for other events to occur between the axis_discrete and + its coupled axis event, including other axis_discrete or axis +- events. ++ events. A wl_pointer.frame must not contain more than one axis_discrete ++ event per axis type. + + This event is optional; continuous scrolling devices + like two-finger scrolling on touchpads do not have discrete +@@ -2090,12 +2340,106 @@ + + + ++ ++ ++ ++ Discrete high-resolution scroll information. ++ ++ This event carries high-resolution wheel scroll information, ++ with each multiple of 120 representing one logical scroll step ++ (a wheel detent). For example, an axis_value120 of 30 is one quarter of ++ a logical scroll step in the positive direction, a value120 of ++ -240 are two logical scroll steps in the negative direction within the ++ same hardware event. ++ Clients that rely on discrete scrolling should accumulate the ++ value120 to multiples of 120 before processing the event. ++ ++ The value120 must not be zero. ++ ++ This event replaces the wl_pointer.axis_discrete event in clients ++ supporting wl_pointer version 8 or later. ++ ++ Where a wl_pointer.axis_source event occurs in the same ++ wl_pointer.frame, the axis source applies to this event. ++ ++ The order of wl_pointer.axis_value120 and wl_pointer.axis_source is ++ not guaranteed. ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ This specifies the direction of the physical motion that caused a ++ wl_pointer.axis event, relative to the wl_pointer.axis direction. ++ ++ ++ ++ ++ ++ ++ ++ Relative directional information of the entity causing the axis ++ motion. ++ ++ For a wl_pointer.axis event, the wl_pointer.axis_relative_direction ++ event specifies the movement direction of the entity causing the ++ wl_pointer.axis event. For example: ++ - if a user's fingers on a touchpad move down and this ++ causes a wl_pointer.axis vertical_scroll down event, the physical ++ direction is 'identical' ++ - if a user's fingers on a touchpad move down and this causes a ++ wl_pointer.axis vertical_scroll up scroll up event ('natural ++ scrolling'), the physical direction is 'inverted'. ++ ++ A client may use this information to adjust scroll motion of ++ components. Specifically, enabling natural scrolling causes the ++ content to change direction compared to traditional scrolling. ++ Some widgets like volume control sliders should usually match the ++ physical direction regardless of whether natural scrolling is ++ active. This event enables clients to match the scroll direction of ++ a widget to the physical direction. ++ ++ This event does not occur on its own, it is coupled with a ++ wl_pointer.axis event that represents this axis value. ++ The protocol guarantees that each axis_relative_direction event is ++ always followed by exactly one axis event with the same ++ axis number within the same wl_pointer.frame. Note that the protocol ++ allows for other events to occur between the axis_relative_direction ++ and its coupled axis event. ++ ++ The axis number is identical to the axis number in the associated ++ axis event. ++ ++ The order of wl_pointer.axis_relative_direction, ++ wl_pointer.axis_discrete and wl_pointer.axis_source is not ++ guaranteed. ++ ++ ++ ++ + + +- ++ + + The wl_keyboard interface represents one or more keyboards + associated with a seat. ++ ++ Each wl_keyboard has the following logical state: ++ ++ - an active surface (possibly null), ++ - the keys currently logically down, ++ - the active modifiers, ++ - the active group. ++ ++ By default, the active surface is null, the keys currently logically down ++ are empty, the active modifiers and the active group are 0. + + + +@@ -2106,13 +2450,17 @@ + + ++ summary="libxkbcommon compatible, null-terminated string; to determine the xkb keycode, clients must add 8 to the key event keycode"/> + + + + + This event provides a file descriptor to the client which can be +- memory-mapped to provide a keyboard mapping description. ++ memory-mapped in read-only mode to provide a keyboard mapping ++ description. ++ ++ From version 7 onwards, the fd must be mapped with MAP_PRIVATE by ++ the recipient, as MAP_SHARED may fail. + + + +@@ -2123,10 +2471,18 @@ + + Notification that this seat's keyboard focus is on a certain + surface. ++ ++ The compositor must send the wl_keyboard.modifiers event after this ++ event. ++ ++ In the wl_keyboard logical state, this event sets the active surface to ++ the surface argument and the keys currently logically down to the keys ++ in the keys argument. The compositor must not send this event if the ++ wl_keyboard already had an active surface immediately before this event. + + + +- ++ + + + +@@ -2136,6 +2492,11 @@ + + The leave notification is sent before the enter notification + for the new focus. ++ ++ In the wl_keyboard logical state, this event resets all values to their ++ defaults. The compositor must not send this event if the active surface ++ of the wl_keyboard was not equal to the surface argument immediately ++ before this event. + + + +@@ -2154,6 +2515,21 @@ + A key was pressed or released. + The time argument is a timestamp with millisecond + granularity, with an undefined base. ++ ++ The key is a platform-specific key code that can be interpreted ++ by feeding it to the keyboard mapping (see the keymap event). ++ ++ If this event produces a change in modifiers, then the resulting ++ wl_keyboard.modifiers event must be sent after this event. ++ ++ In the wl_keyboard logical state, this event adds the key to the keys ++ currently logically down (if the state argument is pressed) or removes ++ the key from the keys currently logically down (if the state argument is ++ released). The compositor must not send this event if the wl_keyboard ++ did not have an active surface immediately before this event. The ++ compositor must not send this event if state is pressed (resp. released) ++ and the key was already logically down (resp. was not logically down) ++ immediately before this event. + + + +@@ -2165,6 +2541,17 @@ + + Notifies clients that the modifier and/or group state has + changed, and it should update its local state. ++ ++ The compositor may send this event without a surface of the client ++ having keyboard focus, for example to tie modifier information to ++ pointer focus instead. If a modifier event with pressed modifiers is sent ++ without a prior enter event, the client can assume the modifier state is ++ valid until it receives the next wl_keyboard.modifiers event. In order to ++ reset the modifier state again, the compositor can send a ++ wl_keyboard.modifiers event with no pressed modifiers. ++ ++ In the wl_keyboard logical state, this event updates the modifiers and ++ group. + + + +@@ -2203,7 +2590,7 @@ + + + +- ++ + + The wl_touch interface represents a touchscreen + associated with a seat. +@@ -2272,6 +2659,8 @@ + currently active on this client's surface. The client is + responsible for finalizing the touch points, future touch points on + this surface may reuse the touch point ID. ++ ++ No frame event is required after the cancel event. + + + +@@ -2347,7 +2736,7 @@ + + + +- ++ + + An output describes part of the compositor geometry. The + compositor works in the 'compositor coordinate system' and an +@@ -2371,10 +2760,9 @@ + + + +- +- This describes the transform that a compositor will apply to a +- surface to compensate for the rotation or mirroring of an +- output device. ++ ++ This describes transformations that clients and compositors apply to ++ buffer contents. + + The flipped values correspond to an initial flip around a + vertical axis followed by rotation. +@@ -2402,6 +2790,20 @@ + + The physical size can be set to zero if it doesn't make sense for this + output (e.g. for projectors or virtual outputs). ++ ++ The geometry event will be followed by a done event (starting from ++ version 2). ++ ++ Clients should use wl_surface.preferred_buffer_transform instead of the ++ transform advertised by this event to find the preferred buffer ++ transform to use for a surface. ++ ++ Note: wl_output only advertises partial information about the output ++ position and identification. Some compositors, for instance those not ++ implementing a desktop-style output layout or those exposing virtual ++ outputs, might fake this information. Instead of using x and y, clients ++ should use xdg_output.logical_position. Instead of using make and model, ++ clients should use name and description. + + +@@ -2418,7 +2820,7 @@ + + ++ summary="additional transformation applied to buffer contents during presentation"/> + + + +@@ -2442,11 +2844,31 @@ + current. In other words, the current mode is always the last + mode that was received with the current flag set. + ++ Non-current modes are deprecated. A compositor can decide to only ++ advertise the current mode and never send other modes. Clients ++ should not rely on non-current modes. ++ + The size of a mode is given in physical hardware units of + the output device. This is not necessarily the same as + the output size in the global compositor space. For instance, + the output may be scaled, as described in wl_output.scale, +- or transformed, as described in wl_output.transform. ++ or transformed, as described in wl_output.transform. Clients ++ willing to retrieve the output size in the global compositor ++ space should use xdg_output.logical_size instead. ++ ++ The vertical refresh rate can be set to zero if it doesn't make ++ sense for this output (e.g. for virtual outputs). ++ ++ The mode event will be followed by a done event (starting from ++ version 2). ++ ++ Clients should not use the refresh rate to schedule frames. Instead, ++ they should use the wl_surface.frame event or the presentation-time ++ protocol. ++ ++ Note: this information is not always meaningful for all outputs. Some ++ compositors, such as those exposing virtual outputs, might fake the ++ refresh rate or the size. + + + +@@ -2471,8 +2893,9 @@ + This event contains scaling geometry information + that is not in the geometry event. It may be sent after + binding the output object or if the output scale changes +- later. If it is not sent, the client should assume a +- scale of 1. ++ later. The compositor will emit a non-zero, positive ++ value for scale. If it is not sent, the client should ++ assume a scale of 1. + + A scale larger than 1 means that the compositor will + automatically scale surface buffers by this amount +@@ -2480,12 +2903,11 @@ + displays where applications rendering at the native + resolution would be too small to be legible. + +- It is intended that scaling aware clients track the +- current output of a surface, and if it is on a scaled +- output it should use wl_surface.set_buffer_scale with +- the scale of the output. That way the compositor can +- avoid scaling the surface, and the client can supply +- a higher detail image. ++ Clients should use wl_surface.preferred_buffer_scale ++ instead of this event to find the preferred buffer ++ scale to use for a surface. ++ ++ The scale event will be followed by a done event. + + + +@@ -2498,6 +2920,62 @@ + use the output object anymore. + + ++ ++ ++ ++ ++ ++ Many compositors will assign user-friendly names to their outputs, show ++ them to the user, allow the user to refer to an output, etc. The client ++ may wish to know this name as well to offer the user similar behaviors. ++ ++ The name is a UTF-8 string with no convention defined for its contents. ++ Each name is unique among all wl_output globals. The name is only ++ guaranteed to be unique for the compositor instance. ++ ++ The same output name is used for all clients for a given wl_output ++ global. Thus, the name can be shared across processes to refer to a ++ specific wl_output global. ++ ++ The name is not guaranteed to be persistent across sessions, thus cannot ++ be used to reliably identify an output in e.g. configuration files. ++ ++ Examples of names include 'HDMI-A-1', 'WL-1', 'X11-1', etc. However, do ++ not assume that the name is a reflection of an underlying DRM connector, ++ X11 connection, etc. ++ ++ The name event is sent after binding the output object. This event is ++ only sent once per output object, and the name does not change over the ++ lifetime of the wl_output global. ++ ++ Compositors may re-use the same output name if the wl_output global is ++ destroyed and re-created later. Compositors should avoid re-using the ++ same name if possible. ++ ++ The name event will be followed by a done event. ++ ++ ++ ++ ++ ++ ++ Many compositors can produce human-readable descriptions of their ++ outputs. The client may wish to know this description as well, e.g. for ++ output selection purposes. ++ ++ The description is a UTF-8 string with no convention defined for its ++ contents. The description is not guaranteed to be unique among all ++ wl_output globals. Examples might include 'Foocorp 11" Display' or ++ 'Virtual X11 output via :1'. ++ ++ The description event is sent after binding the output object and ++ whenever the description changes. The description is optional, and may ++ not be sent at all. ++ ++ The description event will be followed by a done event. ++ ++ ++ + + + +@@ -2569,6 +3047,8 @@ + + ++ + + + +@@ -2578,14 +3058,18 @@ + plain wl_surface into a sub-surface. + + The to-be sub-surface must not already have another role, and it +- must not have an existing wl_subsurface object. Otherwise a protocol +- error is raised. ++ must not have an existing wl_subsurface object. Otherwise the ++ bad_surface protocol error is raised. + + Adding sub-surfaces to a parent is a double-buffered operation on the + parent (see wl_surface.commit). The effect of adding a sub-surface + becomes visible on the next time the state of the parent surface is + applied. + ++ The parent surface must not be one of the child surface's descendants, ++ and the parent must be different from the child surface, otherwise the ++ bad_parent protocol error is raised. ++ + This request modifies the behaviour of wl_surface.commit request on + the sub-surface, see the documentation on wl_subsurface interface. + +@@ -2621,7 +3105,7 @@ + wl_surface state directly. A sub-surface is initially in the + synchronized mode. + +- Sub-surfaces have also other kind of state, which is managed by ++ Sub-surfaces also have another kind of state, which is managed by + wl_subsurface requests, as opposed to wl_surface requests. This + state includes the sub-surface position relative to the parent + surface (wl_subsurface.set_position), and the stacking order of +@@ -2640,15 +3124,18 @@ + synchronized mode, and then assume that all its child and grand-child + sub-surfaces are synchronized, too, without explicitly setting them. + +- If the wl_surface associated with the wl_subsurface is destroyed, the +- wl_subsurface object becomes inert. Note, that destroying either object +- takes effect immediately. If you need to synchronize the removal +- of a sub-surface to the parent surface update, unmap the sub-surface +- first by attaching a NULL wl_buffer, update parent, and then destroy +- the sub-surface. ++ Destroying a sub-surface takes effect immediately. If you need to ++ synchronize the removal of a sub-surface to the parent surface update, ++ unmap the sub-surface first by attaching a NULL wl_buffer, update parent, ++ and then destroy the sub-surface. + + If the parent wl_surface object is destroyed, the sub-surface is + unmapped. ++ ++ A sub-surface never has the keyboard focus of any seat. ++ ++ The wl_surface.offset request is ignored: clients must use set_position ++ instead to move the sub-surface. + + + +@@ -2656,8 +3143,7 @@ + The sub-surface interface is removed from the wl_surface object + that was turned into a sub-surface with a + wl_subcompositor.get_subsurface request. The wl_surface's association +- to the parent is deleted, and the wl_surface loses its role as +- a sub-surface. The wl_surface is unmapped immediately. ++ to the parent is deleted. The wl_surface is unmapped immediately. + + + +@@ -2675,9 +3161,7 @@ + surface area. Negative values are allowed. + + The scheduled coordinates will take effect whenever the state of the +- parent surface is applied. When this happens depends on whether the +- parent surface is in synchronized mode or not. See +- wl_subsurface.set_sync and wl_subsurface.set_desync for details. ++ parent surface is applied. + + If more than one set_position request is invoked by the client before + the commit of the parent surface, the position of a new request always +@@ -2700,9 +3184,7 @@ + The z-order is double-buffered. Requests are handled in order and + applied immediately to a pending state. The final pending state is + copied to the active state the next time the state of the parent +- surface is applied. When this happens depends on whether the parent +- surface is in synchronized mode or not. See wl_subsurface.set_sync and +- wl_subsurface.set_desync for details. ++ surface is applied. + + A new sub-surface is initially added as the top-most in the stack + of its siblings and parent. diff --git a/gnu/packages/qt.scm b/gnu/packages/qt.scm index 37d9eb0bee..c3a7ce8780 100644 --- a/gnu/packages/qt.scm +++ b/gnu/packages/qt.scm @@ -1956,7 +1956,8 @@ set of plugins for interacting with pulseaudio and GStreamer.") (method url-fetch) (uri (qt-url name version)) (patches (search-patches "qtwayland-dont-recreate-callbacks.patch" - "qtwayland-cleanup-callbacks.patch")) + "qtwayland-cleanup-callbacks.patch" + "qtwayland-update-wayland-xml.patch")) (sha256 (base32 "1w9nclz1lfg5haq3m6ihils0kl2n1pqagdyh71ry1m281w8gvly8")))) -- cgit v1.2.3