xcb_input_get...motion_events(3)

💖 xcb_input_get...motion_events — the XCB Requests glow-up 💖

okay bestie, so this is a page from the XCB Requests fam, and it lives in the libxcb manual, section 3. Her whole name is xcb_input_get...motion_events(3) and honestly? she's giving ✨niche X11 lore✨. Buckle up, we're doing the full rundown, no skips. 🎀

---

✨ NAME ✨

xcb_input_get_device_motion_events — and that's literally it, that's the whole name field. The original just... trails off. Iconic of her. 🫶

---

✨ SYNOPSIS ✨

First things first, you gotta pull in the header:

#include <xcb/xinput.h>

🌸 Request function

xcb_input_get_device_motion_events_cookie_t
       xcb_input_get_device_motion_events(xcb_connection_t *conn,
       xcb_timestamp_t start, xcb_timestamp_t stop, uint8_t device_id);

🦋 Reply datastructure

here's the struct, and yes we're copying every single field because that's the whole assignment:

typedef struct xcb_input_get_device_motion_events_reply_t {
    uint8_t  response_type;
    uint8_t  xi_reply_type;
    uint16_t sequence;
    uint32_t length;
    uint32_t num_events;
    uint8_t  num_axes;
    uint8_t  device_mode;
    uint8_t  pad0[18];
} xcb_input_get_device_motion_events_reply_t;

that pad0[18] is doing absolutely nothing and yet it must be respected. queen of silence. 💅

🧚 Reply function

xcb_input_get_device_motion_events_reply_t
       *xcb_input_get_device_motion_events_reply(xcb_connection_t *conn,
       xcb_input_get_device_motion_events_cookie_t cookie,
       xcb_generic_error_t **e);

💜 Reply accessors

two lil helpers, both yours:

int xcb_input_get_device_motion_events_events_length(const
       xcb_input_get_device_motion_events_reply_t *reply);

xcb_input_device_time_coord_iterator_t
       xcb_input_get_device_motion_events_events_iterator(const
       xcb_input_get_device_motion_events_reply_t *reply);

---

🌈 REQUEST ARGUMENTS 🌈

• conn — your XCB connection to X11, aka the lil phone line to the server. 📞
• start — TODO: NOT YET DOCUMENTED. bestie the docs simply did not show up. 🫠
• stop — also TODO: NOT YET DOCUMENTED. same energy.
• device_id — yep. TODO: NOT YET DOCUMENTED. three for three, a clean sweep. 💀

---

⭐ REPLY FIELDS ⭐

• response_type — the type of this reply, and in this case it's XCB_INPUT_GET_DEVICE_MOTION_EVENTS. This field also lives in the xcb_generic_reply_t, so you can use it to tell your replies apart from each other. very "which one of y'all is it" of her. 🔍
• sequence — the sequence number of the last request the X11 server actually processed.
• length — how long the reply is, in words. and a word is 4 bytes, in case anyone was wondering. 📏
• xi_reply_type — TODO: NOT YET DOCUMENTED. 🙈
• num_events — TODO: NOT YET DOCUMENTED. 🙈
• num_axes — TODO: NOT YET DOCUMENTED. 🙈
• device_mode — TODO: NOT YET DOCUMENTED. 🙈

---

🎀 DESCRIPTION 🎀

so... the DESCRIPTION section is empty. like, truly empty. a blank canvas. the original just moves straight on. we love a mysterious queen with no explanation. 💅✨

---

🫶 RETURN VALUE 🫶

She hands you back an xcb_input_get_device_motion_events_cookie_t. 🍪 Now, errors? Those don't get handled here, bestie — you deal with them later when you call the reply function xcb_input_get_device_motion_events_reply.

But if you'd rather catch your errors in the event loop instead, go ahead and use xcb_input_get_device_motion_events_unchecked. Peep xcb-requests(3) for the full tea. ☕

---

🍓 ERRORS 🍓

good news fr fr: this request never generates any errors. not a single one. she's unproblematic. periodt. 👑

---

👑 SEE ALSO 👑

nothing here either — this section is empty in the original, so no cross-references to send you to. (the xcb-requests(3) mention up in RETURN VALUE is doing all the heavy lifting, iykyk. 😭)

---

💖 AUTHOR 💖

Generated from xinput.xml. If you've got corrections or improvements, hit up xcb@lists.freedesktop.org. 📧

---

and that's the whole page, bestie, you ate it. 🍽️✨

X Version 11 · libxcb 1.17.0 · xcb_input_get...motion_events(3)

mwah, love u, go read the source code. 💜🦋🌸