XkbNoteIndicatorChanges(3)

📦
version 1.8.4 · 2 versions
, in debian bookworm

💖 XkbNoteIndicatorChanges — the XKB FUNCTIONS glow-up (section 3 of your manual, bestie) 💖

okay so picture this: your indicator lights are doing their little thing, changing state, changing maps, being dramatic, and you're over here like "bestie I need to remember that." That's literally what this function is for. It's XkbNoteIndicatorChanges(3) from libX11, and she is serving utility. ✨

🎀 NAME 🎀

XkbNoteIndicatorChanges — notes the changes in a changes structure. that's it, that's the whole job, and she does it flawlessly. no cap. 💅

🌸 SYNOPSIS 🌸

void XkbNoteIndicatorChanges (XkbIndicatorChangesPtr old,
       XkbIndicatorNotifyEvent *new, unsigned int wanted);

like, void, so she returns nothing. she just does. main character energy fr fr. 👑

🦋 ARGUMENTS 🦋

  • old — the XkbIndicatorChanges structure that's getting updated. this is the one you're writing into, the glow-up target. 🫶
  • new — the event you're copying changes from. your source material, your inspo. 🌈
  • wanted — which changes are actually getting noted. picky? no, curated. ✨

💜 DESCRIPTION 💜

so here's the tea. whenever an indicator changes state, the server sends XkbIndicatorStateNotify events to all interested clients. and similarly — key word similarly — whenever an indicator's map changes, the server sends XkbIndicatorMapNotify events to all interested clients. the server is not shy, she tells everyone who's listening. 😭

now, to actually receive those XkbIndicatorStateNotify events? you use XkbSelectEvents with both the bits_to_change and values_for_bits parameters containing XkbIndicatorStateNotifyMask. both of them. do not skip one, I'm begging. 🙈

and to receive XkbIndicatorMapNotify events, you use XkbSelectEvents with XkbIndicatorMapNotifyMask. simple. iconic. no notes. 💅

but what if you only want events for specific indicators? (valid. we love a selective queen.) then you use XkbSelectEventDetails. set the event_type parameter to XkbIndicatorStateNotify or XkbIndicatorMapNotify, and set both the bits_to_change and values_for_bits detail parameters to a mask where each bit specifies one indicator — turning on those bits that specify the indicators you want events for. one bit per indicator, turn on what you want, leave the rest. it's giving checkbox behavior honestly. 🎀

okay now the changed parameter — she's a mask that's the bitwise inclusive OR of the indicators that have changed. and here's the nuance bestie, don't sleep on it:

  • if the event is of type XkbIndicatorMapNotify, changed reports the maps that changed. 🗺️
  • if the event is of type XkbIndicatorStateNotify, changed reports the indicators that have changed state. 💡

and state is a mask that specifies the current state of all indicators — whether they have changed or not — for both XkbIndicatorStateNotify and IndicatorMapNotify events. she's the full picture, not just the diff. 📸

so when your client application receives either a XkbIndicatorStateNotify event or a XkbIndicatorMapNotify event, you can note the changes in a changes structure by calling XkbNoteIndicatorChanges. that's the whole vibe. you got an event, you got a struct, you got a function that marries them. 💖

now the wanted parameter — she is the bitwise inclusive OR of XkbIndicatorMapMask and XkbIndicatorStateMask. and what XkbNoteIndicatorChanges does is copy any changes reported in new and specified in wanted into the changes record specified by old. read that again. copies. reported in new. specified in wanted. into old. the whole pipeline is right there and she's clean. 🔥

⭐ STRUCTURES ⭐

plot twist: both types of indicator events use the same structure. one struct, two events, she contains multitudes. 🌈

typedef struct _XkbIndicatorNotify {
  int            type;       /* Xkb extension base event code */
  unsigned long  serial;     /* X server serial number for event */
  Bool           send_event; /* True => synthetically generated */
  Display *      display;    /* server connection where event generated */
  Time           time;       /* server time when event generated */
  int            xkb_type;   /* specifies state or map notify */
  int            device;     /* Xkb device ID, will not be XkbUseCoreKbd */
  unsigned int   changed;    /* mask of indicators with new state or map */
  unsigned int   state;      /* current state of all indicators */
} XkbIndicatorNotifyEvent;

and xkb_type is either XkbIndicatorStateNotify or XkbIndicatorMapNotify, depending on whether the event is a kbIndicatorStateNotify event or kbIndicatorMapNotify event. (yes, the original manual page writes those last two exactly like that — kbIndicatorStateNotify and kbIndicatorMapNotify — and I am not about to change a single character of a manpage. respect the source. periodt. 💀)

👑 SEE ALSO 👑

go read your sisters, they're all iconic:

🫶 reminder bestie: the masks are bitwise inclusive ORs, XkbSelectEvents needs both bits_to_change and values_for_bits set for the state notify mask, and old is the struct you're writing into. keep those straight and you're golden. ✨

🌸 okay that's the page!! this was XkbNoteIndicatorChanges(3) from the XKB FUNCTIONS manual, shipped with libX11 1.8.4, X Version 11. stay slaying, stay notified, and go note those changes. mwah!! 💖🎀🦋

📦 where this page comes from