XIQUERYDEVICE(3)

📦
version 1.8.3 · 6 versions
, in fedora 44

💖 XIQUERYDEVICE(3) — XInput2 device lore, bestie edition 💖

okay so like. you want to know everything about the input devices your X server is holding? bestie, this is literally the page for you. this lives in the XInput2 manual family (XIQUERYDEVICE(3)), and it's giving main-character API energy. let's get into it 🫶

✨ NAME ✨

XIQueryDevice, XIFreeDeviceInfo — get information about devices. that's it, that's the vibe. one of them gets the tea, the other one cleans up after. iconic duo, no cap. 🎀

🌸 SYNOPSIS 🌸

#include <X11/extensions/XInput2.h>

XIDeviceInfo* XIQueryDevice( Display *display,
                             int deviceid,
                             int *ndevices_return);

XIFreeDeviceInfo( XIDeviceInfo *info);

and here's the little cast list of arguments, bc we don't gatekeep:

  • deviceid — specifies the device to query, or XIAllDevices, or XIAllMasterDevices. pick your fighter. 💅
  • display — specifies the connection to the X server. your link to the mothership.
  • ndevices_return — returns the number of devices returned. yes it's a return, through a pointer, because C said so. 😭
  • info — a list of device XIDeviceInfo structs to be freed. the clean-up duty. somebody has to do it.

🦋 DESCRIPTION 🦋

XIQueryDevice returns information about one or more input devices. so if deviceid specifies a device, then ndevices_return is 1 and the returned information describes only the requested device. but if deviceid is XIAllDevices or XIAllMasterDevices, then ndevices_return is the number of devices or master devices, respectively — and the returned information represents all devices or all master devices, respectively. slay, all of them, at once. 👑

and to free the XIDeviceInfo array that XIQueryDevice hands you? use XIFreeDeviceInfo. don't just leave it there, that's rude and also a leak. 🙈

for each input device requested, XIQueryDevice returns an XIDeviceInfo structure. each structure contains information about the capabilities of one input device available to the server. and the struct itself is:

typedef struct
{
    int                 deviceid;
    char                *name;
    int                 use;
    int                 attachment;
    Bool                enabled;
    int                 num_classes;
    XIAnyClassInfo      **classes;
} XIDeviceInfo;

breaking it down, field by field, bc we're thorough in this house:

  • the deviceid is the numeric unique id of the device. it's unique for the life-time of a device, but a server may re-use the id once a device has been removed. so like, ids get recycled. noted. 💀
  • the name points to a null-terminated string specifying the identifier of the device.
  • the use and attachment fields specify the type of the device and the current attachment or pairing. this part is lowkey the juiciest:
    • if use is XIMasterPointer, the device is a master pointer and attachment specifies the deviceid of the paired master keyboard.
    • if use is XIMasterKeyboard, the device is a master keyboard, and the attachment field specifies the paired master pointer.
    • if use is XISlavePointer, the device is a slave device and currently attached to the master pointer specified in attachment.
    • if use is XISlaveKeyboard, the device is a slave device and currently attached to the master keyboard specified in attachment.
    • if use is XIFloatingSlave, the device is a slave device currently not attached to any master device. the value of the attachment field for floating slave devices is undefined. so don't go reading it and forming opinions, bestie. 🚫
  • the enabled field specifies if the device is currently enabled and can send events. disabled devices will not send events. simple as that.
  • the num_classes field specifies the number of input classes pointed to by classes. the first two fields of all input classes are identical:
typedef struct
{
    int         type;
    int         sourceid;
} XIAnyClassInfo;

the type field specifies the type of the input class. currently, the following types are defined: XIKeyClass, XIButtonClass, XIValuatorClass, XIScrollClass, XITouchClass, XIGestureClass. ✨

in the future, additional types may be added. clients are required to ignore unknown input classes. so be a good bestie and skip what you don't recognise, don't crash about it. 🫶

the sourceid is the deviceid this class originated from. for master devices, the sourceid is typically the id of the slave device currently sending events. for slave devices, the sourceid is typically the device's id.

a device may have zero or one XIButtonClass, denoting the device's capability to send button events.

typedef struct {
    int           mask_len;
    unsigned char *mask;
} XIButtonState;

typedef struct
{
    int         type;
    int         sourceid;
    int         num_buttons;
    Atom        *labels;
    XIButtonState state;
} XIButtonClassInfo;

the num_buttons field specifies the number of buttons available on this device. a device that has an XIButtonClass must have at least one button. like, minimum one, ok?

labels is a list of num_buttons Atoms specifying the button labels for this device. if the label is not None, then the label specifies the type of button in physical device order (i.e. as the buttons are numbered on the physical input device).

the state is the current button state as seen by clients (i.e. after button mapping is applied). the mask_len field specifies the length of mask in bytes. for each button on the device, the respective bit in mask is set if the button is currently logically down. 💅

a device may have zero or one XIKeyClass, denoting the device's capability to send key events.

typedef struct
{
    int         type;
    int         sourceid;
    int         num_keycodes;
    int         *keycodes;
} XIKeyClassInfo;

the num_keycodes field specifies the number of keycodes available on this device. a device that has an XIKeyClass must have at least one keycode. again, minimum one.

keycodes is a list of num_keycodes keycodes the device may send.

a device may have zero or more XIValuatorClass, denoting the device's capability to send coordinates. (note: zero or more, these ones stack. obsessed. 🌈)

typedef struct
{
    int         type;
    int         sourceid;
    int         number;
    Atom        label;
    double      min;
    double      max;
    double      value;
    int         resolution;
    int         mode;
} XIValuatorClassInfo;
  • the number field specifies the number of the axis on the physical device.
  • if the label field is not None, the value of label is an Atom describing the axis.
  • min and max are the minimum and maximum values allowed on this axis. if both are zero, no minimum or maximum values are set on this device. value is the current value of this axis.
  • the resolution field specifies the resolution of the device in units/m.
  • the mode specifies the mode of this axis. if the mode is XIModeAbsolute this axis sends absolute coordinates. if the mode is XIModeRelative, this device sends relative coordinates.

next up, scrolling:

typedef struct
{
    int         type;
    int         sourceid;
    int         number;
    int         scroll_type;
    double      increment;
    int         flags;
} XIScrollClassInfo;

this class describes scrolling capability on a valuator. for each XIScrollClassInfo, an XIValuatorClassInfo with the same number is present on the device. they're a matching set, fr fr. 🎀

  • the number field specifies the valuator number on the physical device that this scroll information applies to. see the respective XIValuatorClassInfo for detailed information on this valuator.
  • the scroll_type field specifies the type of scrolling, either XIScrollTypeVertical or XIScrollTypeHorizontal.
  • the increment specifies the value change considered one unit of scrolling down.
  • the flags field specifies flags that apply to this scrolling information:
    • if XIScrollFlagNoEmulation is set, the server will not emulate legacy button events for valuator changes on this valuator.
    • if XIScrollFlagPreferred is set, this axis is the preferred axis for this scroll type and will be used for the emulation of XI_Motion events when the driver submits legacy scroll button events.

now touch, the fun one:

typedef struct
{
    int         type;
    int         sourceid;
    int         mode;
    int         num_touches;
} XITouchClassInfo;

a device may have zero or one XITouchClassInfo, denoting multi-touch capability on the device. a device with a XITouchClassInfo may send TouchBegin, TouchUpdate, TouchEnd and TouchOwnership events. ✨

the mode field is either XIDirectTouch for direct-input touch devices such as touchscreens or XIDependentTouch for indirect input devices such as touchpads. for XIDirectTouch devices, touch events are sent to window at the position the touch occurred. for XIDependentTouch devices, touch events are sent to the window at the position of the device's sprite.

the num_touches field defines the maximum number of simultaneous touches the device supports. a num_touches of 0 means the maximum number of simultaneous touches is undefined or unspecified. this field should be used as a guide only — devices will lie about their capabilities. 😭 yes, they lie. hardware is messy like that, bestie.

a device with an XITouchClassInfo may still send pointer events. the valuators must be defined with the respective XIValuatorClass classes. a valuator may send both pointer and touch-events.

and gestures, the newest little diva:

typedef struct
{
    int         type;
    int         sourceid;
    int         num_touches;
} XIGestureClassInfo;

a device may have zero or one XIGestureClassInfo, denoting touchpad gesture capability on the device. a device with a XIGestureClassInfo may send GestureSwipeBegin, GestureSwipeUpdate, GestureSwipeEnd, GesturePinchBegin, GesturePinchUpdate, GesturePinchEnd.

the num_touches field defines the maximum number of simultaneous touches the device supports. a num_touches of 0 means the maximum number of simultaneous touches is undefined or unspecified. this field should be used as a guide only — devices will lie about their capabilities. same warning, same lies. 🙈

XIQueryDevice can generate a BadDevice error. keep that in mind, it's the dramatic exit. 💅

XIFreeDeviceInfo frees the information returned by XIQueryDevice. that's its whole job and it does it flawlessly.

💀 DIAGNOSTICS 💀

  • BadDevice — an invalid device was specified. the device does not exist or is not a pointer device.

and that's the whole page, bestie!! you now officially know more about XInput2 devices than 99% of people in your group chat, and that's on periodt. 🫶✨

this has been the XInput2 family of docs, page XIQUERYDEVICE(3), dated 05/18/2026 — go forth and query some devices, you absolute icon 👑💖

📦 where this page comes from