xcb_input_query_device_state(3)

πŸ“¦
version 1.17.0 Β· 4 versions
, in alpine 3.22, alpine 3.23, alpine 3.24, arch rolling, centos-stream 10, debian trixie, fedora 43, fedora 44, nixpkgs unstable, opensuse-leap 16.0, ubuntu questing, ubuntu resolute, ubuntu stonking

✨ xcb_input_query_device_state ✨

okay bestie, welcome to the XCB Requests chapter of the manual, section 3 πŸ’… this one is xcb_input_query_device_state and she is lowkey iconic β€” she asks the X server "hey queen, what's the current state of this device?" and the server tells you. that's the whole vibe. no cap.


🌸 NAME 🌸

xcb_input_query_device_state β€” (the original page leaves this blank, so like… that's all we got, bestie πŸ™ˆ)


πŸŽ€ SYNOPSIS πŸŽ€

first up, you gotta pull in the header:

#include <xcb/xinput.h>

Request function

xcb_input_query_device_state_cookie_t
       xcb_input_query_device_state(xcb_connection_t *conn,
       uint8_t device_id);

Reply datastructure

typedef struct xcb_input_query_device_state_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_query_device_state_reply_t;

Reply function

xcb_input_query_device_state_reply_t
       *xcb_input_query_device_state_reply(xcb_connection_t *conn,
       xcb_input_query_device_state_cookie_t cookie,
       xcb_generic_error_t **e);

Reply accessors

int xcb_input_query_device_state_classes_length(const
       xcb_input_query_device_state_reply_t *reply);

xcb_input_input_state_iterator_t
       xcb_input_query_device_state_classes_iterator(const
       xcb_input_query_device_state_reply_t *reply);

πŸ‘‘ REQUEST ARGUMENTS πŸ‘‘

  • conn β€” the XCB connection to X11. your little hotline to the server, fr fr.
  • device_id β€” TODO: NOT YET DOCUMENTED. yeah bestie, the upstream docs left this one on read 😭 it's a uint8_t and it's the device you're asking about, that's all we know.

πŸ¦‹ REPLY FIELDS πŸ¦‹

  • response_type β€” the type of this reply. in this case it's XCB_INPUT_QUERY_DEVICE_STATE. this field is also present in the xcb_generic_reply_t, and it's literally how you tell replies apart from each other πŸ’…
  • sequence β€” the sequence number of the last request processed by the X11 server. her little receipt number 🧾
  • length β€” the length of the reply, in words. and a word is 4 bytes, so do the math bestie.
  • xi_reply_type β€” TODO: NOT YET DOCUMENTED. πŸ™ˆ
  • num_classes β€” TODO: NOT YET DOCUMENTED. πŸ™ˆ

🌈 DESCRIPTION 🌈

nothing here, bestie. the original page has an empty DESCRIPTION section. the silence is deafening πŸ’€

⭐ RETURN VALUE ⭐

she returns an xcb_input_query_device_state_cookie_t πŸͺ β€” that's your little claim ticket.

errors have to be handled when you call the reply function xcb_input_query_device_state_reply, okay? that's the moment of truth.

and if you'd rather handle errors in the event loop instead? use xcb_input_query_device_state_unchecked. see xcb-requests(3) for the deets, iykyk.


πŸ’œ ERRORS πŸ’œ

this request does never generate any errors. periodt. not a single one. flawless behavior honestly πŸ”₯


🌟 SEE ALSO 🌟

this section is empty on the original page too 🫢 nothing to link, nothing to see, moving on.

πŸ“ AUTHOR πŸ“

generated from xinput.xml. if you spot something wrong or wanna make it better, hit up xcb@lists.freedesktop.org for corrections and improvements β€” they're literally waiting for your email bestie πŸ’Œ


and that's the whole page!! this beauty came to you from X Version 11, libxcb 1.17.0, and she is xcb_input_query_device_state(3) β€” slay, stay hydrated, and remember: cookies don't eat themselves πŸͺβœ¨πŸ’–