wayland::zwp_...nstraints_v1_t(3)

🎀 wayland::zwp_pointer_constraints_v1_t(3) — Wayland++ 🎀

Okay so this is the Wayland++ manual page for wayland::zwp_pointer_constraints_v1_t, and it's literally the friend who tells your pointer where it can and cannot go. 💅

🌸 NAME 🌸

wayland::zwp_pointer_constraints_v1_t — constrain the movement of a pointer

That's the whole vibe: constraining pointer movement. No cap. ✨

✨ SYNOPSIS ✨

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

Inherits wayland::proxy_t.

🧚 Public Types 🧚

• enum class wrapper_type { standard, display, foreign, proxy_wrapper }

💖 Public Member Functions 💖

• zwp_locked_pointer_v1_t lock_pointer (surface_t const &surface, pointer_t const &pointer, region_t const &region, zwp_pointer_constraints_v1_lifetime const &lifetime) — locks the pointer to a position
• zwp_confined_pointer_v1_t confine_pointer (surface_t const &surface, pointer_t const &pointer, region_t const &region, zwp_pointer_constraints_v1_lifetime const &lifetime) — confines the pointer to a region
• uint32_t get_id () const — grabs the id of a proxy object
• std::string get_class () const — grabs the interface name (class) of a proxy object
• uint32_t get_version () const — grabs the protocol object version of a proxy object
• wrapper_type get_wrapper_type () const — grabs the type of a proxy object
• void set_queue (event_queue_t queue) — assigns a proxy to an event queue
• wl_proxy * c_ptr () const — gets a pointer to the underlying C struct
• bool proxy_has_object () const — checks whether this wrapper actually wraps an object
• operator bool () const — checks whether this wrapper actually wraps an object
• bool operator== (const proxy_t &right) const — checks whether two wrappers refer to the same object
• bool operator!= (const proxy_t &right) const — checks whether two wrappers refer to different objects
• void proxy_release () — releases the wrapped object (if any), making this an empty wrapper

⭐ Static Public Attributes ⭐

• static constexpr std::uint32_t lock_pointer_since_version = 1 — minimum protocol version required for the lock_pointer function
• static constexpr std::uint32_t confine_pointer_since_version = 1 — minimum protocol version required for the confine_pointer function

🦋 Detailed Description 🦋

Okay so zwp_pointer_constraints_v1_t is the global interface that exposes pointer constraining functionality. It serves two requests: lock_pointer for locking the pointer to its position, and confine_pointer for locking the pointer to a region. Two requests, two vibes. ✨

The lock_pointer and confine_pointer requests create the objects wp_locked_pointer and wp_confined_pointer respectively, and the client can use these objects to interact with the lock. Basically the request makes the object, then you chat with the object. 💅

For any surface, only one lock or confinement may be active across all wl_pointer objects of the same seat. If a lock or confinement is requested when another lock or confinement is active or requested on the same surface and with any of the wl_pointer objects of the same seat, an 'already_constrained' error will be raised. So don't double-book, bestie. That's the rule. 🫶

Definition at line 2453 of file wayland-client-protocol-unstable.hpp.

🔥 Member Enumeration Documentation 🔥

enum class wayland::proxy_t::wrapper_type [strong], [inherited]

This enum describes the underlying wl_proxy type and the properties of a proxy_t that affect construction, destruction, and event handling. It's basically the "what kind of C pointer are we holding?" label. 👑

Enumerator:

• standard — C pointer is a standard type compatible with wl_proxy*. Events are dispatched and it is destructed when the proxy_t is destructed. User data is set.
• display — C pointer is a wl_display*. No events are dispatched, wl_display_disconnect is called when the proxy_t is destructed. User data is set.
• foreign — C pointer is a standard type compatible with wl_proxy*, but another library owns it and it should not be touched in a way that could affect the operation of the other library. No events are dispatched, wl_proxy_destroy is not called when the proxy_t is destructed, user data is not touched. Consequently, there is no reference counting for the proxy_t. Lifetime of such wrappers should preferably be short to minimize the chance that the owning library decides to destroy the wl_proxy.
• proxy_wrapper — C pointer is a wl_proxy* that was constructed with wl_proxy_create_wrapper. No events are dispatched, wl_proxy_wrapper_destroy is called when the proxy_t is destroyed. Reference counting is active. A reference to the proxy_t creating this proxy wrapper is held to extend its lifetime until after the proxy wrapper is destroyed.

Definition at line 117 of file wayland-client.hpp.

💜 Member Function Documentation 💜

💫 wayland::proxy_t::c_ptr

wl_proxy * wayland::proxy_t::c_ptr () const [inherited]

This is your backstage pass to the underlying C struct. It gets a pointer to that underlying C struct.

Returns: the underlying wl_proxy wrapped by this proxy_t if it exists; otherwise an exception is thrown. 😭

💫 zwp_pointer_constraints_v1_t::confine_pointer

zwp_confined_pointer_v1_t zwp_pointer_constraints_v1_t::confine_pointer
    (surface_t const & surface, pointer_t const & pointer, region_t const &
    region, zwp_pointer_constraints_v1_lifetime const & lifetime)

confine pointer to a region

Parameters:

• surface — surface to lock pointer to
• pointer — the pointer that should be confined
• region — region of surface
• lifetime — confinement lifetime

This request is how you tell the client to confine the pointer cursor to a given region. Heads up: it may not take effect immediately. In the future, when the compositor decides its implementation-specific constraints are satisfied, the pointer confinement will activate and the compositor sends a confined event. So it's a "when the compositor says so" situation. 🦋

To figure out where the pointer needs to be for confinement to activate, the compositor uses the intersection of the region you passed with this request and the input region of the surface. Whether it warps the pointer or requires some kind of user interaction for the confinement to activate is up to the compositor. If the region is null, the surface input region is used. No region? Surface input region it is.

The request creates a new object wp_confined_pointer which is used to interact with the confinement as well as receive updates about its state. See the the description of wp_confined_pointer for further information.

Definition at line 5762 of file wayland-client-protocol-unstable.cpp.

💫 wayland::proxy_t::get_class

std::string wayland::proxy_t::get_class () const [inherited]

This gets the interface name (class) of a proxy object.

Returns: the interface name of the object associated with the proxy. 🎀

💫 wayland::proxy_t::get_id

uint32_t wayland::proxy_t::get_id () const [inherited]

This gets the id of a proxy object.

Returns: the id the object associated with the proxy.

💫 wayland::proxy_t::get_version

uint32_t wayland::proxy_t::get_version () const [inherited]

This gets the protocol object version of a proxy object. It gets the protocol object version of a proxy object, or 0 if the proxy was created with unversioned API.

A returned value of 0 means that no version information is available, so the caller must make safe assumptions about the object's real version.

display_t will always return version 0.

Returns: the protocol object version of the proxy or 0.

💫 wayland::proxy_t::get_wrapper_type

wrapper_type wayland::proxy_t::get_wrapper_type () const [inline],
    [inherited]

This gets the type of a proxy object.

Definition at line 303 of file wayland-client.hpp.

💫 zwp_pointer_constraints_v1_t::lock_pointer

zwp_locked_pointer_v1_t zwp_pointer_constraints_v1_t::lock_pointer
    (surface_t const & surface, pointer_t const & pointer, region_t const &
    region, zwp_pointer_constraints_v1_lifetime const & lifetime)

lock pointer to a position

Parameters:

• surface — surface to lock pointer to
• pointer — the pointer that should be locked
• region — region of surface
• lifetime — lock lifetime

This request lets the client ask to disable movements of the virtual pointer (i.e. the cursor), which effectively locks the pointer to a position. It may not take effect immediately. In the future, when the compositor deems implementation-specific constraints are satisfied, the pointer lock will be activated and the compositor sends a locked event. So yeah, it's a future-tense situation. 💅

The protocol provides no guarantee that the constraints are ever satisfied, and it does not require the compositor to send an error if the constraints cannot ever be satisfied. That means it's possible to request a lock that will never activate. Not me asking for something that never happens. 💀

When you request a lock, there may not be another pointer constraint of any kind requested or active on the surface for any of the wl_pointer objects of the seat of the passed pointer. If there is, an error will be raised. See general pointer lock documentation for more details.

The intersection of the region passed with this request and the input region of the surface is used to determine where the pointer must be in order for the lock to activate. Whether the compositor warps the pointer or requires some kind of user interaction for the lock to activate is up to the compositor. If the region is null, the surface input region is used.

A surface may receive pointer focus without the lock being activated. Important vibe check.

The request creates a new object wp_locked_pointer which is used to interact with the lock as well as receive updates about its state. See the the description of wp_locked_pointer for further information.

Note that while a pointer is locked, the wl_pointer objects of the corresponding seat will not emit any wl_pointer.motion events, but relative motion events will still be emitted via wp_relative_pointer objects of the same seat. wl_pointer.axis and wl_pointer.button events are unaffected. So motion events are on pause, relative motion still slides through, and axis/button are untouched. Periodt.

Definition at line 5755 of file wayland-client-protocol-unstable.cpp.

💫 wayland::proxy_t::operator bool

wayland::proxy_t::operator bool () const [inherited]

This checks whether this wrapper actually wraps an object.

Returns: true if there is an underlying object, false if this wrapper is empty.

💫 wayland::proxy_t::operator!=

bool wayland::proxy_t::operator!= (const proxy_t & right) const [inherited]

This checks whether two wrappers refer to different objects.

💫 wayland::proxy_t::operator==

bool wayland::proxy_t::operator== (const proxy_t & right) const [inherited]

This checks whether two wrappers refer to the same object.

💫 wayland::proxy_t::proxy_has_object

bool wayland::proxy_t::proxy_has_object () const [inherited]

This checks whether this wrapper actually wraps an object.

Returns: true if there is an underlying object, false if this wrapper is empty.

💫 wayland::proxy_t::proxy_release

void wayland::proxy_t::proxy_release () [inherited]

This releases the wrapped object (if any), making this an empty wrapper. Note that display_t instances cannot be released this way. Attempts to do so are ignored. So don't try it with display_t, bestie.

Examples: foreign_display.cpp.

💫 wayland::proxy_t::set_queue

void wayland::proxy_t::set_queue (event_queue_t queue) [inherited]

Parameters: queue — The event queue that will handle this proxy

This assigns the proxy to an event queue. Events coming from the proxy will be queued in queue instead of the display's main queue.

See also: display_t::dispatch_queue().

Examples: proxy_wrapper.cpp.

💾 Member Data Documentation 💾

okay bestie, last stretch — these are the member data bits, aka the lil constants living on the class itself. they're both static and constexpr, so you don't even need an object to peek at them, they're just there, iconically available at compile time. 💅

• std::uint32_t wayland::zwp_pointer_constraints_v1_t::confine_pointer_since_version = 1 — [static], [constexpr]. this one is literally just the minimum protocol version required for the confine_pointer function. that's it, that's the whole vibe. value's 1, so it's been valid since the very beginning, no cap. ✨
• std::uint32_t wayland::zwp_pointer_constraints_v1_t::lock_pointer_since_version = 1 — [static], [constexpr]. same energy, different function: the minimum protocol version required for lock_pointer. also = 1. 🎀

the juicy sourcing deets, since you know I'd never gatekeep:

• confine_pointer_since_version is defined at line 2552 of file wayland-client-protocol-unstable.hpp.
• lock_pointer_since_version is defined at line 2521 of file wayland-client-protocol-unstable.hpp.

ngl, these two are the definition of low-effort-but-essential. tiny lil version numbers carrying the whole stability contract on their backs. main character energy honestly. 👑

---

🫶 Author 🫶

Generated automatically by Doxygen for Wayland++ from the source code. so like, a robot wrote it, not a person — which means if the docs are dry, blame the machine, not me. 😭

---

aaaand that's a wrap on wayland::zwp_...nstraints_v1_t(3), bestie!! you made it to the end, I'm so proud. 🥹💖 this whole thing is Version 1.0.1, dated Fri Mar 27 2026, straight from the Wayland++ source code. go forth and constrain those pointers, you absolute icon. 🌈✨🦋