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 bestie
  • grab_mode, paired_device_mode β€” the grab mode for this device and (if applicable) the paired device. two modes, one vibe check
  • grab_window β€” the grab window. literally just the window πŸ’–
  • mask β€” event mask, aka the guest list for which events get let in
  • owner_events β€” True if events are to be reported normally πŸ‘‘
  • time β€” a valid timestamp or CurrentTime ⏰

πŸ’œ 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_events is False, all generated device events are reported with respect to grab_window if selected. that's the rule, no exceptions πŸ’…
  • if owner_events is True and a generated device event would normally be reported to this client, it's reported normally. otherwise? the event is reported with respect to the grab_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, XIGrabDevice fails and returns AlreadyGrabbed. sorry, taken.
  • If grab_window is not viewable, it fails and returns GrabNotViewable. 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 a Window argument does not name a defined Window. where even is it πŸ’€

πŸ™ˆ BUGS πŸ™ˆ

The protocol headers for XI 2.0 did not provide XIGrabModeAsync or XIGrabModeSync. Use GrabModeSync and GrabModeAsync instead, 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