XGrabKeyboard(3)

okay bestie, welcome to the XLIB FUNCTIONS manual page for XGrabKeyboard(3) and XUngrabKeyboard(3) πŸ’– this is the keyboard-grab lore, and no cap, every detail is staying.

✨ NAME ✨

XGrabKeyboard, XUngrabKeyboard - grab the keyboard

🌸 SYNTAX 🌸

int XGrabKeyboard(Display *display, Window grab_window, Bool
              owner_events, int pointer_mode, int keyboard_mode, Time time);
int XUngrabKeyboard(Display *display, Time time);

πŸŽ€ ARGUMENTS πŸŽ€

  • display β€” Specifies the connection to the X server.
  • grab_window β€” Specifies the grab window.
  • keyboard_mode β€” Specifies further processing of keyboard events. You can pass GrabModeSync or GrabModeAsync.
  • owner_events β€” Specifies a Boolean value that indicates whether the keyboard events are to be reported as usual.
  • pointer_mode β€” Specifies further processing of pointer events. You can pass GrabModeSync or GrabModeAsync.
  • time β€” Specifies the time. You can pass either a timestamp or CurrentTime.

πŸ’… DESCRIPTION πŸ’…

okay so XGrabKeyboard is the main character here: it actively grabs control of the keyboard and generates FocusIn and FocusOut events. After that, further key events are reported only to the grabbing client. XGrabKeyboard overrides any active keyboard grab by this client. If owner_events is False, all generated key events are reported with respect to grab_window. If owner_events is True and a generated key event would normally be reported to this client, it is reported normally; otherwise, the event is reported with respect to the grab_window. Both KeyPress and KeyRelease events are always reported, independent of any event selection made by the client. periodt πŸ’…

If the keyboard_mode argument is GrabModeAsync, keyboard event processing continues as usual. If the keyboard is currently frozen by this client, then processing of keyboard events is resumed. If the keyboard_mode argument is GrabModeSync, the state of the keyboard (as seen by client applications) appears to freeze, and the X server generates no further keyboard events until the grabbing client issues a releasing XAllowEvents call or until the keyboard grab is released. Actual keyboard changes are not lost while the keyboard is frozen; they are simply queued in the server for later processing. lowkey iconic queue behavior 🧚

If pointer_mode is GrabModeAsync, pointer event processing is unaffected by activation of the grab. If pointer_mode is GrabModeSync, the state of the pointer (as seen by client applications) appears to freeze, and the X server generates no further pointer events until the grabbing client issues a releasing XAllowEvents call or until the keyboard grab is released. Actual pointer changes are not lost while the pointer is frozen; they are simply queued in the server for later processing. same frozen-state energy, but for the pointer πŸ¦‹

If the keyboard is actively grabbed by some other client, XGrabKeyboard fails and returns AlreadyGrabbed. If grab_window is not viewable, it fails and returns GrabNotViewable. If the keyboard is frozen by an active grab of another client, it fails and returns GrabFrozen. If the specified time is earlier than the last-keyboard-grab time or later than the current X server time, it fails and returns GrabInvalidTime. Otherwise, the last-keyboard-grab time is set to the specified time (CurrentTime is replaced by the current X server time). so many little β€œnot today” outcomes, but the fallback is slay ✨

XGrabKeyboard can generate BadValue and BadWindow errors.

The XUngrabKeyboard function releases the keyboard and any queued events if this client has it actively grabbed from either XGrabKeyboard or XGrabKey. XUngrabKeyboard does not release the keyboard and any queued events if the specified time is earlier than the last-keyboard-grab time or is later than the current X server time. It also generates FocusIn and FocusOut events. The X server automatically performs an UngrabKeyboard request if the event window for an active keyboard grab becomes not viewable. automatic cleanup? love that for us 🫢

πŸ”₯ DIAGNOSTICS πŸ”₯

  • BadValue β€” Some numeric value falls outside the range of values accepted by the request. Unless a specific range is specified for an argument, the full range defined by the argument's type is accepted. Any argument defined as a set of alternatives can generate this error.
  • BadWindow β€” A value for a Window argument does not name a defined Window.

🌈 SEE ALSO 🌈


kisses bestie 🫢 this page is from X Version 11, libX11 1.8.14 β€” and the footer has no date, just those version vibes. bye πŸ’…

πŸ“¦ where this page comes from