xcb_input_open_device(3)

🌸 NAME 🌸

xcb_input_open_device — and that's it, bestie, the description after the dash is literally empty in the source. It's giving mystery. It's giving "we'll tell you later". Anyway, this is a section 3 manual page (that's the library-functions section, iykyk) from libxcb, and it lives in xcb_input_open_device(3). 💅

---

✨ SYNOPSIS ✨

First things first, you gotta pull in the header:

#include <xcb/xinput.h>

🎀 Request function

xcb_input_open_device_cookie_t
       xcb_input_open_device(xcb_connection_t *conn, uint8_t device_id);

🎀 Reply datastructure

typedef struct xcb_input_open_device_reply_t {
    uint8_t  response_type;
    uint8_t  xi_reply_type;
    uint16_t sequence;
    uint32_t length;
    uint8_t  num_classes;
    uint8_t  pad0[23];
} xcb_input_open_device_reply_t;

🎀 Reply function

xcb_input_open_device_reply_t
       *xcb_input_open_device_reply(xcb_connection_t *conn,
       xcb_input_open_device_cookie_t cookie, xcb_generic_error_t **e);

🎀 Reply accessors

xcb_input_input_class_info_t *xcb_input_open_device_class_info(const
       xcb_input_open_device_request_t *reply);

int xcb_input_open_device_class_info_length(const
       xcb_input_open_device_reply_t *reply);

xcb_input_input_class_info_iterator_t
       xcb_input_open_device_class_info_iterator(const
       xcb_input_open_device_reply_t *reply);
uint8_t
       *xcb_input_open_device_pad_1 (const
       xcb_input_open_device_request_t *reply)

Not me noticing that last one has no semicolon 🫠 — that is exactly how it's written in the source, so don't come for me, I'm just the messenger. Also yes, xcb_input_open_device_class_info and xcb_input_open_device_pad_1 take an xcb_input_open_device_request_t *reply. Weird? Yes. Iconic? Also yes. Copy it verbatim and you'll be fine. 💜

---

🦋 REQUEST ARGUMENTS 🦋

• conn — your XCB connection to X11. That's the whole vibe. 🫶
• device_id — TODO: NOT YET DOCUMENTED. Bestie the docs literally left this one blank. I cannot make it up, that would be lying, and lying is not the move. 🙈

---

🌈 REPLY FIELDS 🌈

• response_type — the type of this reply, and in this case it's XCB_INPUT_OPEN_DEVICE. This field also shows up in the xcb_generic_reply_t, so you can use it to tell your replies apart from each other. Very main character energy, honestly. ⭐
• sequence — the sequence number of the last request that got processed by the X11 server. 📬
• length — how long the reply is, in words. And a word here is 4 bytes, in case you were about to count wrong. 💀
• xi_reply_type — TODO: NOT YET DOCUMENTED. Another blank, no cap. 😭
• num_classes — TODO: NOT YET DOCUMENTED. Yeah. Three for three on the mystery. 🕵️‍♀️

---

💖 DESCRIPTION 💖

Okay so… there is genuinely nothing written under DESCRIPTION in this page. It's a blank section. An empty vibe check. The heading is there, the words are not. We respect the silence. 🎀

---

👑 RETURN VALUE 👑

It hands you back an xcb_input_open_device_cookie_t. Cute, right? But here's the thing, bestie: errors have to be handled when you call the reply function xcb_input_open_device_reply.

And if you'd rather handle your errors inside the event loop instead? Then use xcb_input_open_device_unchecked. See xcb-requests(3) for the details, fr fr. 🔥

---

💀 ERRORS 💀

This request does never generate any errors. Not one. Zero. None. We love a low-drama request. ✨

---

🧚 SEE ALSO 🧚

This section is empty on this page, bestie. Nothing listed. Just vibes and a heading. 🌸

---

🍓 AUTHOR 🍓

Generated from xinput.xml. If you spot something that needs corrections or improvements, hit up xcb@lists.freedesktop.org — they're the ones to talk to. 📧

---

And that's the whole page, mwah. 💋 This one's from X Version 11, libxcb 1.17.0, and it's filed under xcb_input_open_device(3). Go forth and open some devices, you absolute icon. 🦋✨💅