xcb_grab_key(3)

💖 xcb_grab_key(3) 💖

okay so bestie, welcome to xcb_grab_key — this is one of the XCB Requests pages (from libxcb 1.17.0, X Version 11, if you were wondering who's serving looks today 💅). It's a request function, it's giving keyboard-grabbing main character energy, and we're gonna go through the WHOLE thing together. no skimming. grab a snack 🍓

---

✨ NAME ✨

xcb_grab_key — grab keyboard key(s). literally just. seizing a key. iconic behavior 👑

---

✨ SYNOPSIS ✨

🌸 Request function 🌸

#include <xcb/xproto.h>

xcb_void_cookie_t xcb_grab_key(xcb_connection_t *conn,
       uint8_t owner_events, xcb_window_t grab_window,
       uint16_t modifiers, xcb_keycode_t key, uint8_t pointer_mode,
       uint8_t keyboard_mode);

that's the whole signature bestie, take it in 🫶

---

✨ REQUEST ARGUMENTS ✨

• conn — the XCB connection to X11. your lil hotline to the server 📞
• owner_events — if it's 1, the grab_window will still get the key events. if it's 0, events are not reported to the grab_window. that's the whole deal, no in-between ✨
• grab_window — specifies the window on which the key should be grabbed. which window is getting the honor 🎀
• modifiers — the modifiers to grab.

using the special value XCB_MOD_MASK_ANY means grab the key with all possible modifier combinations. every single one. no cap.

• key — the keycode of the key to grab.

the special value XCB_GRAB_ANY means grab any key. yes really, any. slay 💅

• pointer_mode — one of the following values:
  • XCB_GRAB_MODE_SYNC — the state of the keyboard appears to freeze: no further keyboard events are generated by the server until the grabbing client issues a releasing AllowEvents request or until the keyboard grab is released. frozen. paused. on ice 🧊
  • XCB_GRAB_MODE_ASYNC — keyboard event processing continues normally. business as usual, no drama 🌈
• keyboard_mode — one of the following values:
  • XCB_GRAB_MODE_SYNC — the state of the keyboard appears to freeze: no further keyboard events are generated by the server until the grabbing client issues a releasing AllowEvents request or until the keyboard grab is released.
  • XCB_GRAB_MODE_ASYNC — keyboard event processing continues normally.

(yes bestie, pointer_mode and keyboard_mode have the exact same two options listed. that's not me being lazy, that's literally the page 🙈)

---

✨ DESCRIPTION ✨

so what does this actually do? it establishes a passive grab on the keyboard. in the future, the keyboard is actively grabbed (as for GrabKeyboard), the last-keyboard-grab time is set to the time at which the key was pressed (as transmitted in the KeyPress event), and the KeyPress event is reported if all of the following conditions are true:

1. The keyboard is not grabbed and the specified key (which can itself be a modifier key) is logically pressed when the specified modifier keys are logically down, and no other modifier keys are logically down.
2. Either the grab_window is an ancestor of (or is) the focus window, or the grab_window is a descendant of the focus window and contains the pointer.
3. A passive grab on the same key combination does not exist on any ancestor of grab_window.

the interpretation of the remaining arguments is as for XGrabKeyboard. the active grab is terminated automatically when the logical state of the keyboard has the specified key released (independent of the logical state of the modifier keys), at which point a KeyRelease event is reported to the grabbing window.

ngl, important note: the logical state of a device (as seen by client applications) may lag the physical state if device event processing is frozen. so your app might be a lil behind on the tea ☕

a modifiers argument of AnyModifier is equivalent to issuing the request for all possible modifier combinations (including the combination of no modifiers). it is not required that all modifiers specified have currently assigned KeyCodes. a keycode argument of AnyKey is equivalent to issuing the request for all possible KeyCodes. otherwise, the specified keycode must be in the range specified by min_keycode and max_keycode in the connection setup, or a BadValue error results. fr fr, mind your ranges 💀

if some other client has issued a XGrabKey with the same key combination on the same window, a BadAccess error results. when using AnyModifier or AnyKey, the request fails completely, and a BadAccess error results (no grabs are established) if there is a conflicting grab for any combination. like, all or nothing, periodt.

---

✨ RETURN VALUE ✨

returns an xcb_void_cookie_t. errors (if any) have to be handled in the event loop. that's the vibe check — you don't get them handed to you 🎀

if you want to handle errors directly with xcb_request_check instead, use xcb_grab_key_checked. see xcb-requests(3) for details.

---

✨ ERRORS ✨

• xcb_access_error_t — another client has already issued a GrabKey with the same button/key combination on the same window. somebody beat you to it bestie 😭
• xcb_value_error_t — the key is not XCB_GRAB_ANY and not in the range specified by min_keycode and max_keycode in the connection setup.
• xcb_window_error_t — the specified window does not exist. it's giving ghost town 👻

---

✨ SEE ALSO ✨

xcb-requests(3), xcb_grab_keyboard(3)

---

✨ AUTHOR ✨

generated from xproto.xml. contact xcb@lists.freedesktop.org for corrections and improvements. (they're the ones to @ when something's off, not me 💜)

---

okay that's the whole page, you ate that. this was X Version 11, from libxcb 1.17.0, and the page itself is xcb_grab_key(3) — now go grab a key and be the main character of your own event loop ✨💖🦋