XIALLOWEVENTS(3)

🌸 XIALLOWEVENTS(3) — the XIAllowEvents era, bestie 💅

okay so. welcome to XIALLOWEVENTS(3), the page about XIAllowEvents — aka the "release queued events" function. it's giving traffic controller energy for your frozen devices, and honestly? iconic.

---

✨ NAME ✨

XIAllowEvents — release queued events 🎀

---

🌈 SYNOPSIS 🌈

#include <X11/extensions/XInput2.h>

Status XIAllowEvents( Display *display,
                      int deviceid,
                      int event_mode,
                      Time time );

Status XIAllowTouchEvents( Display *dpy,
                           int deviceid,
                           unsigned int touchid,
                           Window grab_window,
                           int event_mode );

and here's what all the little guys mean, bestie 🫶

• display — the connection to the X server. your lil phone line to the server fr fr.
• device — the device that's about to get grabbed or released 👀
• event_mode — this one's the main character: it says whether a device gets thawed and events get replayed, or how a grabbed touch sequence should be handled.
• time — a valid server time, or CurrentTime.
• touchid — the ID of the touch sequence to accept or reject. lowkey it gets ignored for any event mode that isn't AcceptTouch or RejectTouch, so don't stress about it there.
• grab_window — the window on which you accept or reject a touch sequence grab. same deal: ignored for event modes other than AcceptTouch and RejectTouch.

---

💖 DESCRIPTION 💖

the XIAllowEvents request releases some queued events if the client has caused a device to freeze. it's also the one you call for touch grab and ownership processing. multitasking queen 💅

no cap, this function does absolutely nothing if the time you specified is earlier than the last-grab time of the most recent active grab for the client, or if the time you specified is later than the current X server time. and heads up — the time parameter must be CurrentTime for requests with event modes of XIAcceptTouch and XIRejectTouch. periodt.

so here's the tea on what actually happens, depending on which constant you hand to the event_mode argument ☕

• XIAsyncDevice — if the specified device is frozen by the client, event processing for that device just continues as usual. if the device got frozen multiple times by the client on behalf of multiple separate grabs, XIAsyncDevice thaws for all of them. it has no effect if the specified device isn't frozen by the client — but plot twist, the device doesn't even need to be grabbed by the client. 💫
• XISyncDevice — if the specified device is frozen and actively grabbed by the client, event processing for that device continues normally until the next button press or release, or key press or release, or a gesture begin or end event (depends on the grab) gets reported to the client. at that moment, the specified device goes right back to looking frozen again. but if the reported event causes the grab to be released, then the specified device does not freeze. XISyncDevice has no effect if the specified device isn't frozen by the client, or isn't grabbed by the client.
• XIReplayDevice — if the specified device is actively grabbed by the client and is frozen as the result of an event having been sent to the client (either from activating a XIGrabButton or from a previous XIAllowEvents with mode SyncDevice, but not from a Grab), then the grab is released and that event is completely reprocessed. this time, though, the request ignores any passive grabs at or above (towards the root) the grab window of the grab just released. the request has no effect if the specified device isn't grabbed by the client, or if it isn't frozen as the result of an event. and ooh — in the case of a gesture begin event being replayed, the original grabbing client will receive a XI_GesturePinchEnd or XI_GestureSwipeEnd event. 🫶
• XIAsyncPairedDevice — if the paired master device is frozen by the client, event processing for it continues as usual. if the paired device got frozen multiple times by the client on behalf of multiple separate grabs, XIAsyncPairedDevice thaws for all. it has no effect if the device isn't frozen by the client — but those devices don't need to be grabbed by the client. also, XIAsyncPairedDevice has no effect if deviceid specifies a slave device. 🚫
• XISyncPair — if both the device and the paired master device are frozen by the client, event processing (for both devices) continues normally until the next XI_ButtonPress, XI_ButtonRelease, XI_KeyPress, or XI_KeyRelease event is reported to the client for a grabbed device (button event for a pointer, key event for a keyboard), at which time the devices again appear to freeze. however, if the reported event causes the grab to be released, then the devices don't freeze — but if the other device is still grabbed, then a subsequent event for it will still cause both devices to freeze. XISyncPair has no effect unless both the device and the paired master device are frozen by the client. if the device or paired master device got frozen twice by the client on behalf of two separate grabs, XISyncPair thaws for both (but a subsequent freeze for XISyncPair will only freeze each device once). and yup — XISyncPair has no effect if deviceid specifies a slave device.
• XIAsyncPair — if the device and the paired master device 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. XIAsyncPair has no effect unless both the device and the paired master device are frozen by the client. also XIAsyncPair has no effect if deviceid specifies a slave device. 😭
• XIAcceptTouch — the client is deemed to have taken control of the touch sequence once it owns the sequence. TouchEnd events will be sent to all clients listening to the touch sequence that have either grabbed the touch sequence on a child window of the grab_window, or have received events for the touch sequence through event selection. those clients will no longer receive any TouchUpdate events. slay, ownership secured 👑
• XIRejectTouch — the client is no longer interested in the touch sequence, and will receive a XI_TouchEnd event. if the client is the current owner of the sequence, ownership gets passed on to the next listener. it's giving "not it" 🙈

---

🩷 DIAGNOSTICS 🩷

the error list, bestie. read it, love it, fear it a little:

• BadDevice — an invalid deviceid was specified. 💀
• BadAccess — this error may occur if event_mode is XIAcceptTouch and this client is not the current or potential owner of the specified touch ID.
• BadValue — this error may occur if event_mode is XIAcceptTouch and touch ID is invalid.
• BadWindow — a value for a grab_window argument does not name a defined Window.

---

🔥 SEE ALSO 🔥

XIGrabButton(3) — go read that one next, iykyk ✨

---

okay that's the whole page, you ate it up 🎀 this was the XIALLOWEVENTS(3) page, dated 05/18/2026, and the footer was just XIALLOWEVENTS(3) again because the man page loves a lil repetition. bye bestie, go thaw something 💜🦋