XCB_XKB_CONTROLS_NOTIFY_EVENT_T(3)

πŸ“¦
version 1.17.0 Β· 4 versions
, in alpine 3.22, alpine 3.23, alpine 3.24, arch rolling, centos-stream 10, debian trixie, fedora 43, fedora 44, nixpkgs unstable, opensuse-leap 16.0, ubuntu questing, ubuntu resolute, ubuntu stonking

πŸ’– xcb_xkb_controls_notify_event_t β€” bestie's guide to the XKB controls notify event πŸ’–

okay so real talk, this is a page from the XCB Events manual, and the star of the show is xcb_xkb_controls_notify_event_t. it's a struct, it's an event, it's lowkey iconic, and we're gonna go through every single field together, no skipping, no cap. πŸŽ€


✨ NAME ✨

xcb_xkb_controls_notify_event_t β€” literally just the name, bestie. that's it. that's the name. πŸ¦‹


✨ SYNOPSIS ✨

first things first, you gotta include the header or none of this works:

#include <xcb/xkb.h>

🧚 Event datastructure

here's the whole struct, copied exactly, don't touch a single character or the compiler will simply end you:

typedef struct xcb_xkb_controls_notify_event_t {
    uint8_t         response_type;
    uint8_t         xkbType;
    uint16_t        sequence;
    xcb_timestamp_t time;
    uint8_t         deviceID;
    uint8_t         numGroups;
    uint8_t         pad0[2];
    uint32_t        changedControls;
    uint32_t        enabledControls;
    uint32_t        enabledControlChanges;
    xcb_keycode_t   keycode;
    uint8_t         eventType;
    uint8_t         requestMajor;
    uint8_t         requestMinor;
    uint8_t         pad1[4];
} xcb_xkb_controls_notify_event_t;

look at those pad0[2] and pad1[4] just vibing in there. they're padding. they're doing nothing. main character energy honestly. πŸ’…


✨ EVENT FIELDS ✨

okay bestie, field by field, let's go. 🌸

  • response_type β€” the type of this event, and in this specific case it's XCB_XKB_CONTROLS_NOTIFY. this same field also shows up in xcb_generic_event_t, which is how you tell your events apart from each other when they're all just hanging out in the same queue. very "how do you do, fellow events" of it. ✨
  • sequence β€” the sequence number of the last request processed by the X11 server. that's it. that's the whole thing. it's the receipt number basically. 🧾
  • xkbType β€” NOT YET DOCUMENTED.
  • time β€” NOT YET DOCUMENTED.
  • deviceID β€” NOT YET DOCUMENTED.
  • numGroups β€” NOT YET DOCUMENTED.
  • changedControls β€” NOT YET DOCUMENTED.
  • enabledControls β€” NOT YET DOCUMENTED.
  • enabledControlChanges β€” NOT YET DOCUMENTED.
  • keycode β€” NOT YET DOCUMENTED.
  • eventType β€” NOT YET DOCUMENTED.
  • requestMajor β€” NOT YET DOCUMENTED.
  • requestMinor β€” NOT YET DOCUMENTED.
not me reading "NOT YET DOCUMENTED" twelve times in a row 😭 that's the whole field description, babes. the docs said "we'll get to it" and then never got to it. it's giving unfinished homework. but fr fr, that IS what the page says, so that's what you get. 🫢

✨ DESCRIPTION ✨

there is literally no description. the section exists. it is empty. it's giving "showed up to the group project and contributed nothing" πŸ’€


✨ SEE ALSO ✨

also empty, bestie. nothing to see here. nothing to also see. πŸ™ˆ


✨ AUTHOR ✨

this page was generated from xkb.xml. if you spot something wrong or wanna suggest corrections and improvements, hit up xcb@lists.freedesktop.org β€” they're literally asking for it, in a nice way. πŸ’œ


warning bestie: every one of those NOT YET DOCUMENTED fields is a real gap in the docs, not a vibe I'm adding. don't go inventing behaviour for them and then blaming me. 😀

okay that's the whole page!! you read the entire struct, every field, the empty sections, the whole thing. slay. ✨

this one came from X Version 11, libxcb 1.17, and that's the version-and-date sign-off, mwah πŸ’‹ go forth and handle your events, bestie. πŸ¦‹πŸ’–πŸŽ€