INPUTTEST(4)

💖 NAME 💖

inputtest — an X.Org input driver for testing, bestie. that's it, that's the whole job. she's a test queen and she knows it. 👑

---

✨ SYNOPSIS ✨

Section "InputDevice"
  Identifier "devname"
  Driver "inputtest"
  Option "SocketPath"   "path"
  ...
EndSection

like yes, the ... is real, there's more, keep reading bestie, don't ghost me 🙈

---

🌸 DESCRIPTION 🌸

okay so inputtest is an Xorg input driver, and her whole thing is that she takes events that come in over a socket and hands them straight to the server as input events. no cap. she supports the full set of the xf86 driver APIs that Xorg exposes — the whole entire menu, she ate and left no crumbs 💅

her main character use case? various integration tests that need to talk to the input subsystem. if you've got a test that wants to poke input, she's your girl. 🦋

---

🎀 CONFIGURATION DETAILS 🎀

first things first, go check xorg.conf(5) for the general config deets and for all the options that work with every input driver out there. this section? this section is only about what's special to this driver. keep up bestie. 🫶

so an external process can talk to the driver through a named socket</>, and that socket gets created after the driver has been initialized. the paths to the socket get passed in through input driver options. lowkey elegant.

the following driver Options are supported:

• Option "SocketPath" "string" — sets the path where the driver will create a named socket. heads up: any existing file chilling at that location will be removed. she does not share her real estate. 💀
• Option "DeviceType" "string" — sets what type of device is getting emulated. and babes, there are options within the option:
  • Keyboard — initializes a keyboard device. ⌨️
  • Pointer — initializes a relative-mode pointer device. she'll have four valuators: a "Rel X" valuator at axis 0, a "Rel Y" valuator at axis 1, a horizontal scroll valuator set up at axis 2, and a vertical scroll valuator set up at axis 3.
  • PointerAbsolute — initializes an absolute-mode pointer device. also four valuators: an "Abs X" valuator at axis 0, an "Abs Y" valuator at axis 1, a horizontal scroll valuator at axis 2, and a vertical scroll valuator at axis 3.
  • PointerAbsoluteProximity — initializes an absolute-mode pointer device with proximity support. the valuators get initialized exactly like the PointerAbsolute type. same energy, extra feature. ✨
  • Touch — initializes a touch device. she's got 5 valuators: an "Abs MT Position X" at axis 0, an "Abs MT Position Y" valuator at axis 1, a horizontal scroll valuator on axis 2, a vertical scroll valuator on axis 3, and an "Abs MT Pressure" valuator at axis 4. five whole axes, she's thriving.
• Option "TouchCount" "int" — sets the max number of simultaneous touches for touch devices. group hug limit, fr fr.
• Option "PointerButtonCount" "int" — sets the max number of buttons on pointer devices.
• Option "PointerHasPressure" "bool" — picks whether "Abs Pressure" is available at axis 4 on pointer devices. yes or no, she needs an answer. 🙈

---

🌈 INTERFACE WITH THE DRIVER 🌈

the communication with the driver is a binary protocol, and it's defined right here: include/xf86-input-inputtest-protocol.h — go look, it's all in there.

so at the very beginning, the client process that's communicating with the driver has to connect to the socket that the driver created at SocketPath. once that connection is established, it has to write a xf86ITEventClientVersion event and then read back a xf86ITResponseServerVersion response, where the driver tells you the protocol version she supports.

⚠️ and listen, this part matters: if that version is lower than what the client requested, the driver will disconnect. no warning, no discussion, she's gone. goodbye. 😭

after receiving the xf86ITResponseServerVersion message, the client is allowed to start sending events to the driver. each event is an instance of one of the xf86ITEvent* structs. the length field defines the full length of the struct in bytes, and the event field defines the type of the struct. iconic, honestly.

the responses from the server follow the exact same structure. each response is an instance of one of the xf86ITResponse* structs. the length field defines the full length of the struct in bytes, and the event field defines the type of the struct. mirror match, slay. 🪞

and the synchronization with Xorg? that happens via the xf86ITEventWaitForSync event. after sending that event, the client must read a xf86ITResponseSyncFinished event from the socket without sending any additional events. the completion of that read operation is the signal that Xorg has fully processed all the input events sent to it so far. that's the vibe check, and she passed. ✅

---

👑 AUTHORS 👑

Povilas Kanapickas <povilas@radix.lt> — thank you for your service, legend. 🫡

---

💜 SEE ALSO 💜

Xorg(1), xorg.conf(5), Xserver(1), X(7)

go read those too, bestie, iykyk 📚

---

and that's the whole page!! this one's from X Version 11, xorg-server 21.1.25, and it's giving very much the INPUTTEST(4) era. stay hydrated, keep your sockets named, and don't let anybody overwrite your file at SocketPath — she removes it, remember! 💖✨🎀🦋🌸💅🫶