Update wayland-protocols to 1.34

Adds xdg-toplevel-drag-v1, xdg-dialog-v1, and linux-drm-syncobj-v1.

Author: ids1024

wayland-protocols/CHANGELOG.md

@@ -1,6 +1,11 @@
 # CHANGELOG: wayland-protocols
 
 ## Unreleased
+- Bump wayland-protocols to 1.34
+  - New staging protocols:
+    - `xdg-toplevel-drag-v1`
+    - `xdg-dialog-v1`
+    - `linux-drm-syncobj-v1`
 
 ## 0.31.2 -- 2024-01-29
 

wayland-protocols/protocols

@@ -194,6 +194,39 @@ pub mod linux_explicit_synchronization {
     }
 }
 
+#[cfg(feature = "staging")]
+pub mod linux_drm_syncobj {
+    //! This protocol allows clients to request explicit synchronization for
+    //! buffers. It is tied to the Linux DRM synchronization object framework.
+    //!
+    //! Synchronization refers to co-ordination of pipelined operations performed
+    //! on buffers. Most GPU clients will schedule an asynchronous operation to
+    //! render to the buffer, then immediately send the buffer to the compositor
+    //! to be attached to a surface.
+    //!
+    //! With implicit synchronization, ensuring that the rendering operation is
+    //! complete before the compositor displays the buffer is an implementation
+    //! detail handled by either the kernel or userspace graphics driver.
+    //!
+    //! By contrast, with explicit synchronization, DRM synchronization object
+    //! timeline points mark when the asynchronous operations are complete. When
+    //! submitting a buffer, the client provides a timeline point which will be
+    //! waited on before the compositor accesses the buffer, and another timeline
+    //! point that the compositor will signal when it no longer needs to access the
+    //! buffer contents for the purposes of the surface commit.
+    //!
+    //! Linux DRM synchronization objects are documented at:
+    //! <https://dri.freedesktop.org/docs/drm/gpu/drm-mm.html#drm-sync-objects>
+
+    /// Version 1
+    pub mod v1 {
+        wayland_protocol!(
+            "./protocols/staging/linux-drm-syncobj/linux-drm-syncobj-v1.xml",
+            []
+        );
+    }
+}
+
 #[cfg(feature = "unstable")]
 pub mod pointer_constraints {
     //! protocol for constraining pointer motions

wayland-protocols/src/wp.rs

@@ -140,3 +140,61 @@ pub mod shell {
         []
     );
 }
+
+#[cfg(feature = "staging")]
+pub mod toplevel_drag {
+    //! This protocol enhances normal drag and drop with the ability to move a
+    //! window at the same time. This allows having detachable parts of a window
+    //! that when dragged out of it become a new window and can be dragged over
+    //! an existing window to be reattached.
+    //!
+    //! A typical workflow would be when the user starts dragging on top of a
+    //! detachable part of a window, the client would create a `wl_data_source` and
+    //! a `xdg_toplevel_drag_v1` object and start the drag as normal via
+    //! `wl_data_device.start_drag`. Once the client determines that the detachable
+    //! window contents should be detached from the originating window, it creates
+    //! a new `xdg_toplevel` with these contents and issues a
+    //! `xdg_toplevel_drag_v1.attach` request before mapping it. From now on the new
+    //! window is moved by the compositor during the drag as if the client called
+    //! `xdg_toplevel.move`.
+    //!
+    //! Dragging an existing window is similar. The client creates a
+    //! `xdg_toplevel_drag_v1` object and attaches the existing toplevel before
+    //! starting the drag.
+    //!
+    //! Clients use the existing drag and drop mechanism to detect when a window
+    //! can be docked or undocked. If the client wants to snap a window into a
+    //! parent window it should delete or unmap the dragged top-level. If the
+    //! contents should be detached again it attaches a new toplevel as described
+    //! above. If a drag operation is cancelled without being dropped, clients
+    //! should revert to the previous state, deleting any newly created windows
+    //! as appropriate. When a drag operation ends as indicated by
+    //! `wl_data_source.dnd_drop_performed` the dragged toplevel window's final
+    //! position is determined as if a `xdg_toplevel_move` operation ended.
+
+    /// Version 1
+    pub mod v1 {
+        wayland_protocol!(
+            "./protocols/staging/xdg-toplevel-drag/xdg-toplevel-drag-v1.xml",
+            [crate::xdg::shell]
+        );
+    }
+}
+
+#[cfg(feature = "staging")]
+pub mod dialog {
+    //! The `xdg_wm_dialog_v1` interface is exposed as a global object allowing
+    //! to register surfaces with a xdg_toplevel role as "dialogs" relative to
+    //! another toplevel.
+    //!
+    //! The compositor may let this relation influence how the surface is
+    //! placed, displayed or interacted with.
+
+    /// Version 1
+    pub mod v1 {
+        wayland_protocol!(
+            "./protocols/staging/xdg-dialog/xdg-dialog-v1.xml",
+            [crate::xdg::shell]
+        );
+    }
+}