xcb_allow_events(3)

💅 xcb_allow_events — release queued events

okay bestie, welcome to the XCB Requests corner of the manual, page xcb_allow_events(3) 🦋. this one's all about un-freezing stuff, and honestly? it's giving "let my people go" but for input devices. let's get into it 💖

---

✨ SYNOPSIS ✨

#include <xcb/xproto.h>

🎀 Request function

xcb_void_cookie_t xcb_allow_events(xcb_connection_t *conn, uint8_t mode,
       xcb_timestamp_t time);

---

🌸 REQUEST ARGUMENTS 🌸

• conn — your XCB connection to X11. the whole reason we're here, no cap 💫
• mode — literally the main character of this function. it's one of these values:
  • XCB_ALLOW_ASYNC_POINTER — for AsyncPointer: if the pointer is frozen by the client, pointer event processing just... continues normally again 🫶. and if the pointer got frozen twice by the client on behalf of two separate grabs, AsyncPointer thaws for both. oh and — AsyncPointer has no effect if the pointer is not frozen by the client, but the pointer does not need to be grabbed by the client for this to work. okay but the manpage itself says:

TODO: rewrite this in more understandable terms.

not me relaying the original's own to-do list to you 😭 iconic honestly.

• XCB_ALLOW_SYNC_POINTER — for SyncPointer: if the pointer is frozen and actively grabbed by the client, pointer event processing continues normally until the next ButtonPress or ButtonRelease event is reported to the client — at which point the pointer goes back to looking frozen 😶‍🌫️. BUT if the reported event causes the pointer grab to be released, then the pointer does not freeze. SyncPointer has no effect if the pointer isn't frozen by the client, or if the pointer isn't grabbed by the client. periodt.
• XCB_ALLOW_REPLAY_POINTER — for ReplayPointer: if the pointer is actively grabbed by the client and is frozen as the result of an event having been sent to the client (either from the activation of a GrabButton or from a previous AllowEvents with mode SyncPointer — but not from a GrabPointer), then the pointer grab is released and that event is completely reprocessed, this time ignoring any passive grabs at or above (towards the root) the grab-window of the grab just released 🌀. the request has no effect if the pointer isn't grabbed by the client or if the pointer isn't frozen as the result of an event.
• XCB_ALLOW_ASYNC_KEYBOARD — for AsyncKeyboard: if the keyboard is frozen by the client, keyboard event processing continues normally 💜. if the keyboard is frozen twice by the client on behalf of two separate grabs, AsyncKeyboard thaws for both. AsyncKeyboard has no effect if the keyboard isn't frozen by the client, but the keyboard need not be grabbed by the client.
• XCB_ALLOW_SYNC_KEYBOARD — for SyncKeyboard: if the keyboard is frozen and actively grabbed by the client, keyboard event processing continues normally until the next KeyPress or KeyRelease event is reported to the client, at which time the keyboard again appears to freeze 🥶. however, if the reported event causes the keyboard grab to be released, then the keyboard does not freeze. SyncKeyboard has no effect if the keyboard isn't frozen by the client or if the keyboard isn't grabbed by the client.
• XCB_ALLOW_REPLAY_KEYBOARD — for ReplayKeyboard: if the keyboard is actively grabbed by the client and is frozen as the result of an event having been sent to the client (either from the activation of a GrabKey or from a previous AllowEvents with mode SyncKeyboard — but not from a GrabKeyboard), then the keyboard grab is released and that event is completely reprocessed, this time ignoring any passive grabs at or above (towards the root) the grab-window of the grab just released 🌈. the request has no effect if the keyboard isn't grabbed by the client or if the keyboard isn't frozen as the result of an event.
• XCB_ALLOW_ASYNC_BOTH — for AsyncBoth: if the pointer and the keyboard are frozen by the client, event processing for both devices continues normally ✨. if a device is frozen twice by the client on behalf of two separate grabs, AsyncBoth thaws for both. AsyncBoth has no effect unless both pointer and keyboard are frozen by the client. both or nothing, babe 💅
• XCB_ALLOW_SYNC_BOTH — for SyncBoth: if both pointer and keyboard are frozen by the client, event processing (for both devices) continues normally until the next ButtonPress, ButtonRelease, KeyPress, or KeyRelease event is reported to the client for a grabbed device (button event for the pointer, key event for the keyboard), at which time the devices again appear to freeze ❄️. however, if the reported event causes the grab to be released, then the devices do not freeze — but if the other device is still grabbed, then a subsequent event for it will still cause both devices to freeze. SyncBoth has no effect unless both pointer and keyboard are frozen by the client. if the pointer or keyboard is frozen twice by the client on behalf of two separate grabs, SyncBoth thaws for both (but a subsequent freeze for SyncBoth will only freeze each device once). very demure, very mindful 🎀

• time — a timestamp, and it's there to avoid race conditions when you're running X over the network 🌐.

the special value XCB_CURRENT_TIME will be replaced with the current server time. chef's kiss, no notes ✨

---

🦋 DESCRIPTION 🦋

Releases queued events if the client has caused a device (pointer/keyboard) to freeze due to grabbing it actively. that's the whole vibe, bestie 🫶

heads up: this request has no effect if time is earlier than the last-grab time of the most recent active grab for this client, or if time is later than the current X server time. so don't come in with a stale timestamp and expect magic, okay? 😭

---

🔥 RETURN VALUE 🔥

Returns an xcb_void_cookie_t 💌. errors (if any) have to be handled in the event loop, so stay on your toes.

if you'd rather handle errors directly with xcb_request_check instead, use xcb_allow_events_checked 👑. see xcb-requests(3) for the details.

---

💀 ERRORS 💀

• xcb_value_error_t — you specified an invalid mode. not me catching a bad mode 🚨 like, be serious.

---

🌟 SEE ALSO 🌟

• xcb-requests(3)

---

💜 AUTHOR 💜

Generated from xproto.xml. contact xcb@lists.freedesktop.org for corrections and improvements. they're literally so responsive, iykyk 💌

---

and that's the page, bestie!! this whole thing lives in X Version 11, libxcb 1.17.0 — mwah, slay, go thaw some pointers 🧚‍♀️✨💖