XkbGetDeviceLedInfo(3)

🎀 XkbGetDeviceLedInfo(3) — from the XKB FUNCTIONS manual 🎀

okay so this is the XKB FUNCTIONS page for XkbGetDeviceLedInfo(3) — a whole mouthful, but she’s iconic and she’s here to fetch LED feedback tea from an input extension device. 💅✨

🌸 NAME 🌸

XkbGetDeviceLedInfo — query the indicator names, maps, and state associated with an LED feedback of an input extension device. No cap, that’s the whole vibe. 🎀

✨ SYNOPSIS ✨

Status XkbGetDeviceLedInfo (Display *dpy, XkbDeviceInfoPtr device_info,
       unsigned int led_class, unsigned int led_id, unsigned int which);

🦋 ARGUMENTS 🦋

• dpy — connection to X server. Your link to the server, bestie. 🔌
• device_info — structure to update with results. She gets the results poured into her. ✨
• led_class — LED feedback class assigned by input extension. The class the input extension handed out. 🎟️
• led_id — LED feedback ID assigned by input extension. The specific ID the input extension assigned. 🆔
• which — mask indicating desired information. It says which info you actually want. 🎯

💖 DESCRIPTION 💖

XkbGetDeviceLedInfo queries the server for the desired LED information for the feedback specified by led_class and led_id for the X input extension device indicated by device_spec->device_info and waits for a reply. Like, it sends the ask and waits for the server to answer. ⏳ If successful, XkbGetDeviceLedInfo backfills the relevant fields of device_info as determined by which with the results and returns Success. Slay, success. ✅

Valid values for which are the inclusive OR of any of XkbXI_IndicatorNamesMask, XkbXI_IndicatorMapsMask, and XkbXI_IndicatorStateMask. That’s the whole menu, no secret options. 🍓

The fields of device_info that are filled in when this request succeeds are name, type, supported, and unsupported, and portions of the leds structure corresponding to led_class and led_id as indicated by the bits set in which. The device_info->leds vector is allocated if necessary and sz_leds and num_leds filled in. The led_class, led_id and phys_indicators fields of the device_info->leds entry corresponding to led_class and led_id are always filled in. Always, bestie. 💅

If which contains XkbXI_IndicatorNamesMask, the names_present and names fields of the device_info->leds structure corresponding to led_class and led_id are updated, if which contains XkbXI_IndicatorStateMask, the corresponding state field is updated, and if which contains XkbXI_IndicatorMapsMask, the maps_present and maps fields are updated. It’s giving targeted updates only. 🎯

If a compatible version of Xkb is not available in the server or the Xkb extension has not been properly initialized, XkbGetDeviceLedInfo returns BadAccess. If allocation errors occur, a BadAlloc status is returned. If the device has no indicators, a BadMatch error is returned. If ledClass or ledID have illegal values, a BadValue error is returned. If they have legal values but do not specify a feedback that contains LEDs and is associated with the specified device, a BadMatch error is returned. Yeah, that’s the error lore — read it carefully, bestie. 😭

🌈 DIAGNOSTICS 🌈

• BadAccess — The Xkb extension has not been properly initialized. 🚫
• BadAlloc — Unable to allocate storage. 💀
• BadMatch — A compatible version of Xkb was not available in the server or an argument has correct type and range, but is otherwise invalid. 😬
• BadValue — An argument is out of range. 🙈

---

Sign-off time, bestie: source/version is X Version 11, libX11 1.8.14, and the footer title is XkbGetDeviceLedInfo(3) — no date on this one, just the source/version and title. Mwah, bye! 💖🫶