XIGRABDEVICE(3)
πΈ NAME πΈ
okay so bestie, this is the XIGRABDEVICE(3) page and it's about two lil functions: XIGrabDevice and XIUngrabDevice β they grab or ungrab the device. that's it, that's the whole serve π
β¨ SYNOPSIS β¨
#include <X11/extensions/XInput2.h>
Status XIGrabDevice( Display *display,
int deviceid,
Window grab_window,
Time time,
Cursor cursor,
int grab_mode,
int paired_device_mode,
Bool owner_events,
XIEventMask *mask);
Status XIUngrabDevice( Display *display,
int deviceid,
Time time);
π the arguments, explained with love π
cursorβ the cursor image you wanna show off for however long the grab lasts. main character cursor energy β¨displayβ the connection to the X server, aka your lil hotline to the server π«Άdeviceidβ which device is getting grabbed or ungrabbed, no ambiguity here bestiegrab_mode,paired_device_modeβ the grab mode for this device and (if applicable) the paired device. two modes, one vibe checkgrab_windowβ the grab window. literally just the window πmaskβ event mask, aka the guest list for which events get let inowner_eventsβTrueif events are to be reported normally πtimeβ a valid timestamp orCurrentTimeβ°
π DESCRIPTION π
XIGrabDevice actively grabs control of the device. like, it's not being subtle about it. from then on, further device events are reported only to the grabbing client. and not only that β XIGrabDevice overrides any active device grab by this client. it said "my turn" and it meant it π
If the device is an attached slave device, the device is automatically detached from the master device and reattached to the same master device when client ungrabs the device. but wait, there's a plot twist: if the master device is removed while the device is floating as a result of a grab, the device remains floating once the grab deactivates. it's giving "you can't sit with us" πΈ
Now let's talk owner_events because this one lowkey matters:
- if
owner_eventsisFalse, all generated device events are reported with respect tograb_windowif selected. that's the rule, no exceptions π - if
owner_eventsisTrueand a generated device event would normally be reported to this client, it's reported normally. otherwise? the event is reported with respect to thegrab_window, and is only reported if specified in the event mask. iykyk π₯
π the grab modes π
If the grab_mode argument is XIGrabModeAsync, device event processing continues as usual. and if the device is currently frozen by this client, then processing of device events is resumed β we love a comeback β¨
If the grab_mode argument is XIGrabModeSync, the state of the device (as seen by client applications) appears to freeze, and the X server generates no further device events until the grabbing client issues a releasing XIAllowEvents call or until the device grab is released. and no bestie, the actual device changes are not lost while the device is frozen β they're simply queued in the server for later processing. it's a waiting room, not a void π«Ά
If paired_device_mode is XIGrabModeAsync, processing of events from the paired master device is unaffected by activation of the grab. If paired_device_mode is XIGrabModeSync, the state of the paired master device (as seen by client applications) appears to freeze, and the X server generates no further events from this device until the grabbing client issues a releasing XIAllowEvents call or until the device grab is released. and again β actual events are not lost while the devices are frozen; they're simply queued in the server for later processing. also, tiny detail: if the device is a slave device, paired_device_mode is ignored. bye π
π when it just does NOT work π
- If the device is actively grabbed by some other client,
XIGrabDevicefails and returnsAlreadyGrabbed. sorry, taken. - If
grab_windowis not viewable, it fails and returnsGrabNotViewable. can't grab what you can't see π - If the device is frozen by an active grab of another client, it fails and returns
GrabFrozen. brrr. - If the specified time is earlier than the last-device-grab time or later than the current X server time, it fails and returns
GrabInvalidTime. time is fake but the timestamp still has to be valid fr fr β°
Otherwise, the last-device-grab time is set to the specified time. and CurrentTime gets replaced by the current X server time. periodt.
If cursor is not None this cursor is displayed until the client calls XIUngrabDevice. so pick a cute one π
XIGrabDevice can generate BadDevice, BadValue, and BadWindow errors. noted, bestie.
π¦ the ungrab of it all π¦
The XIUngrabDevice request releases the device and any queued events if this client has it actively grabbed from either XIGrabDevice or XIGrabKey or XIGrabButton. If other devices are frozen by the grab, XUngrabDevice thaws them. π§β‘οΈπ§
XUngrabDevice does not release the device and any queued events if the specified time is earlier than the last-device-grab time or is later than the current X server time. so, you know, get your timestamps right.
The X server automatically performs an XIUngrabDevice request if the event window for an active device grab becomes not viewable. the server is the responsible one in this relationship π
XIUngrabDevice can generate a BadDevice error.
π DIAGNOSTICS π
BadValueβ a value is outside of the permitted range. it's giving "ma'am this is a Wendy's" πBadDeviceβ an invalid device was specified. the device does not exist or is not a appropriate for the type of change.BadMatchβ the window is not viewable.BadWindowβ a value for aWindowargument does not name a definedWindow. where even is it π
π BUGS π
The protocol headers for XI 2.0 did not provideXIGrabModeAsyncorXIGrabModeSync. UseGrabModeSyncandGrabModeAsyncinstead, respectively. so if you're on the old protocol headers, swap those names around and you'll be fine bestie π«Ά
β SEE ALSO β
XIAllowEvents(3)β the other half of the grab-and-release situationship π
and that's the page!! dated 05/18/2026, straight from the XIGRABDEVICE(3) manual, mwah πβ¨
π¦ where this page comes from
- fedora 44: libXi-devel 1.8.3-1.fc44 Β· MIT-open-group AND SMLNJ AND MIT
- fedora 44: libXi-devel 1.8.3-1.fc44 Β· MIT-open-group AND SMLNJ AND MIT
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms