XkbSARedirectSetVMods(3)

okay so bestie, welcome to XkbSARedirectSetVMods(3), straight out of the XKB FUNCTIONS manual — it’s giving “tiny setter, big redirect energy.” 💅✨

💖 NAME 💖

XkbSARedirectSetVMods — sets the vmods0 and vmods1 of act from v. That’s the whole assignment, no cap. 🎀

🌸 SYNOPSIS 🌸

void XkbSARedirectSetVMods (XkbRedirectKeyAction act, unsigned int v);

🎀 ARGUMENTS 🎀

• act — the action in which to set the vmods. That’s the target, bestie.
• v — the new value for virtual modifiers. Fresh value, new vibe. ✨

🦋 DESCRIPTION 🦋

Actions associated with the XkbRedirectKeyAction structure generate KeyPress and KeyRelease events containing a keycode different from the key that was pressed or released. Like, the event is lowkey about a different key than the physical one that got tapped. 👀

The type field for the XkbRedirectKeyAction structure should always be XkbSA_RedirectKey. Not “sometimes,” not “if you feel like it” — always. 💅

Key presses cause a KeyPress event for the key specified by the new_key field instead of the actual key. The state reported in this event reports the current effective modifiers changed as follows: any real modifiers selected by the mods_mask field are set to corresponding values from the mods field. Any real modifiers bound to the virtual modifiers specified by the vmods_mask0 and vmods_mask1 fields are either set or cleared, depending on the corresponding values in the vmods0 and vmods1 fields. If the real and virtual modifier definitions specify conflicting values for a single modifier, the real modifier definition has priority. Real mods win that argument, periodt. 🔥

Key releases cause a KeyRelease event for the key specified by the new_key field instead of the actual key. The state for this event consists of the effective keyboard modifiers at the time of the release, changed as described previously. Same redirect logic, release edition. 🦋

The XkbSA_RedirectKey action normally redirects to another key on the same device as the key that caused the event, unless that device does not belong to the input extension KeyClass, in which case this action causes an event on the core keyboard device. (The input extension categorizes devices by breaking them into classes. Keyboards, and other input devices with keys, are classified as KeyClass devices by the input extension.) So yeah: same device normally, core keyboard when the device isn’t in that KeyClass club. 💀

The vmods_mask0 and vmods_mask1 fields actually represent one vmods_mask value. Xkb provides macros to convert between the two formats. Two halves, one mask — iykyk. 🫶

And the last line of this DESCRIPTION section is literally: XkbSARedirectSetVModsMask sets the vmods0 and vmods1 of act from v. Yes, bestie, that’s what it says. 🙈

🌈 STRUCTURES 🌈

typedef struct_XkbRedirectKeyAction {
    unsigned char   type;        /* XkbSA_RedirectKey */
    unsigned char   new_key;     /* keycode to be put in event */
    unsigned char   mods_mask;   /* mask of real mods to be reset */
    unsigned char   mods;        /* mask of real mods to take values from */
    unsigned char   vmods_mask0; /* first half of mask of virtual mods to be reset */
    unsigned char   vmods_mask1; /* other half of mask of virtual mods to be reset */
    unsigned char   vmods0;      /* first half of mask of virtual mods to take values from */
    unsigned char   vmods1;      /* other half of mask of virtual mods to take values from */
} XkbRedirectKeyAction;

That’s the whole page, bestie — footer says X Version 11 and libX11 1.8.14, with XkbSARedirectSetVMods(3) on the right. 🫶💖