xcb_xf86dri_get_device_info(3)

💖 xcb_xf86dri_get_device_info 💖

okay bestie, buckle up, we're reading a manual page from libxcb and it's giving "the lore is thin but the struct is THICC". this one lives in the XCB Requests family, it's the xcb_xf86dri_get_device_info situation, and yes, the DRI in the name is that DRI. direct rendering, iconic behavior, no notes. 🎀

---

✨ NAME ✨

xcb_xf86dri_get_device_info — and that's it. that's the whole name section. the original literally just has a dangling dash and nothing after it, and honestly? mysterious main character energy. we don't know what it's called, we just know it's called. 🦋

---

🌸 SYNOPSIS 🌸

first up, the include, don't forget it or nothing compiles and you'll be sad:

#include <xcb/xf86dri.h>

🫶 Request function

xcb_xf86dri_get_device_info_cookie_t
xcb_xf86dri_get_device_info(xcb_connection_t *conn,
                            uint32_t screen);

she returns a cookie, because XCB is obsessed with the cookie-first pattern. you fire the request, you get a cookie, you redeem it later with the reply function. it's giving "order at the counter, pick up at the counter". 🍓

🎀 Reply datastructure

here's the struct, and yes she is a whole meal:

typedef struct xcb_xf86dri_get_device_info_reply_t {
    uint8_t  response_type;
    uint8_t  pad0;
    uint16_t sequence;
    uint32_t length;
    uint32_t framebuffer_handle_low;
    uint32_t framebuffer_handle_high;
    uint32_t framebuffer_origin_offset;
    uint32_t framebuffer_size;
    uint32_t framebuffer_stride;
    uint32_t device_private_size;
} xcb_xf86dri_get_device_info_reply_t;

look at her. framebuffer everything. it's the framebuffer info girlie and she ate. 💅

🔥 Reply function

xcb_xf86dri_get_device_info_reply_t
*xcb_xf86dri_get_device_info_reply(xcb_connection_t *conn,
                                   xcb_xf86dri_get_device_info_cookie_t cookie,
                                   xcb_generic_error_t **e);

hand her the conn and the cookie from earlier, and she hands you back the reply struct (or fills in *e if something went sideways, more on that below).

🌈 Reply accessors

the little helper squad that digs into the reply for you:

uint32_t *xcb_xf86dri_get_device_info_device_private(const
       xcb_xf86dri_get_device_info_request_t *reply);

int xcb_xf86dri_get_device_info_device_private_length(const
       xcb_xf86dri_get_device_info_reply_t *reply);

xcb_generic_iterator_t
       xcb_xf86dri_get_device_info_device_private_end(const
       xcb_xf86dri_get_device_info_reply_t *reply);

🙈 yes, the first accessor really does take an xcb_xf86dri_get_device_info_request_t * while the other two take an xcb_xf86dri_get_device_info_reply_t *. that's exactly what the original says, so we are not touching it. we simply observe and move on. iykyk.

---

⭐ REQUEST ARGUMENTS ⭐

• conn — the XCB connection to X11. your lil hotline to the server, she's the whole vibe. 💜
• screen — TODO: NOT YET DOCUMENTED. no cap, that's what it says. the docs simply did not show up to the group chat for this one. 😭

---

💫 REPLY FIELDS 💫

• response_type — the type of this reply, in this case XCB_XF86DRI_GET_DEVICE_INFO. this field is also present in the xcb_generic_reply_t and can be used to tell replies apart from each other. it's the name tag at the party. 🏷️
• sequence — the sequence number of the last request processed by the X11 server. tracking number behavior, fr fr.
• length — the length of the reply, in words (a word is 4 bytes). keep that conversion in mind, bestie.
• framebuffer_handle_low — TODO: NOT YET DOCUMENTED. 💀
• framebuffer_handle_high — TODO: NOT YET DOCUMENTED. 💀
• framebuffer_origin_offset — TODO: NOT YET DOCUMENTED. 💀
• framebuffer_size — TODO: NOT YET DOCUMENTED. 💀
• framebuffer_stride — TODO: NOT YET DOCUMENTED. 💀
• device_private_size — TODO: NOT YET DOCUMENTED. 💀

so many TODOs. the framebuffer fields are all sitting there with their little "not yet documented" signs on and honestly? relatable. we still list every single one because every single one matters. 🫡

---

🦋 DESCRIPTION 🦋

...and that's it. there is literally nothing here. the DESCRIPTION section is empty in the original. she said "no thoughts, head empty, struct loaded." ✨ we're respecting the silence.

---

👑 RETURN VALUE 👑

Returns an xcb_xf86dri_get_device_info_cookie_t. Errors have to be handled when calling the reply function xcb_xf86dri_get_device_info_reply.

If you want to handle errors in the event loop instead, use xcb_xf86dri_get_device_info_unchecked. See xcb-requests(3) for details.

so: either you check when you redeem the cookie, or you go the _unchecked route and handle it in the event loop like a chill async queen. pick your fighter. 🔥

---

💀 ERRORS 💀

This request does never generate any errors.

not one. zero. none. error-free behavior, we love to see it. slay. 💚

---

🌸 SEE ALSO 🌸

empty. nothing linked, nothing referenced. she stands alone. iconic solo debut. ⭐

---

💖 AUTHOR 💖

Generated from xf86dri.xml. Contact xcb@lists.freedesktop.org for corrections and improvements.

so if something's wrong, don't come for me, come for the mailing list bestie, that's the whole point of the contact line. 📬

---

💜 and that's the page!! this whole thing is from X Version 11, libxcb 1.17.0, and it's the xcb_xf86dri_get_device_info(3) manual. go forth, redeem your cookies, and remember: TODO: NOT YET DOCUMENTED is a state of mind. byeeeee 🎀✨🦋