wayland::serve...onization_v1_t(3)

πŸ’… wayland::serve...onization_v1_t(3) β€” Wayland++ girlie edition πŸ¦‹

okay so bestie, you're looking at the Wayland++ manual page for wayland::server::zwp_linux_explicit_synchronization_v1_t, and honestly? she's a whole factory interface. let's get into it ✨


🌸 NAME 🌸

wayland::server::zwp_linux_explicit_synchronization_v1_t β€” the protocol for providing explicit synchronization. that's her. that's the whole vibe. πŸ‘‘


✨ SYNOPSIS ✨

first thing, you gotta pull her in:

#include <wayland-server-protocol-unstable.hpp>

πŸŽ€ Public Member Functions πŸŽ€

  • std::function< void()> & on_destroy () β€” destroy explicit synchronization factory object
  • std::function< void(zwp_linux_surface_synchronization_v1_t, surface_t)> & on_get_synchronization () β€” extend surface interface for explicit synchronization
  • void post_synchronization_exists (std::string const &msg) β€” Post error: the surface already has a synchronization object associated.
  • bool proxy_has_object () const β€” Check whether this wrapper actually wraps an object.
  • void post_no_memory () const
  • uint32_t get_id () const
  • client_t get_client () const
  • unsigned int get_version () const
  • std::string get_class ()

🫢 Detailed Description 🫢

protocol for providing explicit synchronization β€” say it with me πŸ’–

so this global is literally a factory interface, allowing clients to request explicit synchronization for buffers on a per-surface basis. iconic behavior.

  • see zwp_linux_surface_synchronization_v1 for more info, iykyk πŸ‘€

this interface is derived from Chromium's zcr_linux_explicit_synchronization_v1. no cap.

Warning! ⚠️ the protocol described in this file is experimental and backward incompatible changes may be made. backward compatible changes may be added together with the corresponding interface version bump. backward incompatible changes are done by bumping the version number in the protocol and interface names and resetting the interface version. once the protocol is to be declared stable, the 'z' prefix and the version number in the protocol and interface names are removed and the interface version number is reset. so like… don't get attached to the exact name, bestie πŸ’€

Definition at line 2349 of file wayland-server-protocol-unstable.hpp.


🧚 Member Function Documentation 🧚

🌈 std::string wayland::server::resource_t::get_class () [inherited]

retrieve the interface name (class) of a resource object ✨

Returns

  • Interface name of the resource object.

🌈 client_t wayland::server::resource_t::get_client () const [inherited]

get the associated client, obviously 🫢

Returns

  • the client that owns the resource.

🌈 uint32_t wayland::server::resource_t::get_id () const [inherited]

get the internal ID of the resource β€” her little secret identifier πŸŽ€

Returns

  • the internal ID of the resource

🌈 unsigned int wayland::server::resource_t::get_version () const [inherited]

get interface version πŸ’…

Returns

  • Interface version this resource has been constructed with.

🌈 std::function< void()> & zwp_linux_explicit_synchronization_v1_t::on_destroy ()

destroy explicit synchronization factory object. destroy this explicit synchronization factory object.

and hear me when i say: other objects, including zwp_linux_surface_synchronization_v1 objects created by this factory, shall not be affected by this request. she leaves, they stay. main character exits, cast remains. πŸ‘‘

Definition at line 5198 of file wayland-server-protocol-unstable.cpp.


🌈 std::function< void(zwp_linux_surface_synchronization_v1_t, surface_t)> & zwp_linux_explicit_synchronization_v1_t::on_get_synchronization ()

extend surface interface for explicit synchronization ✨

Parameters

  • id β€” the new synchronization interface id
  • surface β€” the surface

instantiate an interface extension for the given wl_surface to provide explicit synchronization. it's giving extension energy.

if the given wl_surface already has an explicit synchronization object associated, the synchronization_exists protocol error is raised. like, she already has one. don't. 😭

graphics APIs, like EGL or Vulkan, that manage the buffer queue and commits of a wl_surface themselves, are likely to be using this extension internally. and if a client is using such an API for a wl_surface, it should not directly use this extension on that surface, to avoid raising a synchronization_exists protocol error. fr fr, hands off that one πŸ™ˆ

Definition at line 5204 of file wayland-server-protocol-unstable.cpp.


🌈 void wayland::server::resource_t::post_no_memory () const [inherited]

post "not enough memory" error to the client πŸ’€

if the compositor has not enough memory to fulfill a request of the client (the source says "certail", but we know what she means), this function can be called to notify the client of this circumstance. communique: there is no memory. slay.


🌈 void zwp_linux_explicit_synchronization_v1_t::post_synchronization_exists (std::string const & msg)

post error: the surface already has a synchronization object associated. 🫠

Definition at line 5210 of file wayland-server-protocol-unstable.cpp.


🌈 bool wayland::server::resource_t::proxy_has_object () const [inherited]

check whether this wrapper actually wraps an object. vibe check on the wrapper herself πŸ’…

Returns

  • true if there is an underlying object, false if this wrapper is empty

πŸ‘‘ Author πŸ‘‘

generated automatically by Doxygen for Wayland++ from the source code. she was built by the machines, bestie πŸ€–πŸ’–


πŸ“ the cute sign-off πŸ“

this was Version 1.0.1, dated Fri Mar 27 2026 β€” and the original header was wayland::serve...onization_v1_t(3) from the Wayland++ manual, in case you were wondering where we came from. bye bestie, go synchronize explicitly, and remember: per-surface basis, always πŸŒˆπŸ’œ

πŸ“¦ where this page comes from