AntiMicroX: Mapping a Gamepad to Keyboard and Mouse Input on Linux and Windows

The gap AntiMicroX fills: applications that only listen for a keyboard

Plenty of software reads keyboard and mouse events and nothing else. Older games, some emulators, a few media players and a long tail of desktop utilities never learned to talk to a game controller. AntiMicroX sits between the controller and the application and translates one input vocabulary into the other. According to the README, it maps gamepad keys to keyboard buttons, mouse buttons and moves, scripts and executables, and macros built from those elements.

The intended user is someone holding a gamepad in front of a program that will never see it. The README frames the tool as a way to control any desktop application with a gamepad on Linux and Windows. A second, quieter audience is people with atypical controllers: the README notes that AntiMicroX can generate SDL2 configuration, which is useful for mapping an unusual gamepad onto a generic layout such as an Xbox 360 pad. That is a different job from key remapping, and it is worth knowing the project does both before you go looking for a separate tool.

How the mapping pipeline works, from SDL2 device to emitted key event

The architecture visible in the repository is a C++ desktop application built with CMake, with source under src/ and tests under tests/. Controller input arrives through SDL2, which is why the README can offer SDL2 configuration generation and why device identification is exposed in terms of SDL names. From there the application resolves the active mapping set and emits the configured output: a keyboard event, a mouse event, or an external script or executable.

Mappings are grouped into profiles, and the README describes assigning multiple switchable sets of mappings to a gamepad, so a single controller can behave differently depending on which set is active. Profiles can also be tied to the active application window through auto profiles, which the README explicitly qualifies as not available on Wayland. Control of the active set is exposed outside the GUI through D-Bus: the service is named io.github.antimicrox, and InputDevice objects live at paths of the form /InputDevice/<N>, where N is the device index. That is the part of the design with the most reach, because it means a script or another application can switch sets without touching the window.

Installing AntiMicroX and mapping your first button

Installation depends on the platform. On Windows the README says to download the antimicrox-X.X.X-AMD64.exe installer from the release site and run it. On Linux there are several routes, and the Flathub package is the one that runs across most major distributions. If Flathub is already configured, the README gives this command:

flatpak install flathub io.github.antimicrox.antimicrox

The README warns that the Flatpak package may not work correctly with Wayland and links a wiki page about an open uinput error. Under Flatpak the binary is not on your PATH in the usual way, so the README offers an alias for your shell configuration:

alias antimicrox='flatpak run io.github.antimicrox.antimicrox'

Distribution packages exist too. Fedora and openSUSE are covered by dnf and zypper respectively, and the README shows the Fedora command as dnf install antimicrox. Debian and Ubuntu users are pointed at a .deb package on the release site, and Arch users at the AUR or the chaotic-aur repository. Building from source is documented separately in BUILDING.md, which the README points to for the dependency list.

Once the application is running, the first real task is checking that the controller is visible. The D-Bus interface is the quickest way to confirm this without reading the window. Enumerating the InputDevice objects and calling getSDLName returns a human-readable name such as "Microsoft Xbox 360 Controller". The README gives this example for selecting a control set:

dbus-send --print-reply --dest=io.github.antimicrox /InputDevice/0 io.github.antimicrox.InputDevice.setActiveSetNumber int32:0

If that call succeeds, the device is registered and the set number changed. If it fails, the controller is not being seen by SDL2, and the mapping work is premature.

Where AntiMicroX breaks down: Wayland, auto profiles, and maintenance

Two limitations are stated by the project itself and both matter. The first is Wayland. The README says auto profiles, which assign a profile to the active application window, do not work there. If your workflow depends on the profile changing when you alt-tab between a game and a launcher, that workflow does not exist on a Wayland session. The second is packaging: the README notes that the Flatpak package may not work correctly with Wayland and links a fix for an open uinput error, which means the Linux install method with the widest distribution coverage is also the one with the most caveats on a modern session.

There is a third issue that is not technical. The README opens with a notice that the project is looking for a new maintainer, that support is limited, and that no new features will be added unless external contributors write them. The last push to the repository was on 2026-08-18, so the code is not abandoned, but the stated intent is maintenance rather than development. Anyone choosing AntiMicroX for a long-lived setup should read that notice as the headline, not the footnote. It also means feature requests and unusual bug reports may sit.

A final boundary: AntiMicroX is not a virtual controller driver. It emits keyboard and mouse input. If a game reads XInput directly and simply refuses to accept your particular pad, remapping keys will not help; the problem is device identity, and the SDL2 configuration generation path is the relevant feature, not the key mapping.

AntiMicroX against JoyToKey and the wider remapping field

The most common comparison is with JoyToKey, a long-standing Windows utility with the same core idea: read a joystick, emit keyboard and mouse events. The practical difference is platform and packaging. JoyToKey is a Windows application. AntiMicroX is a C++/SDL2 program that runs on Linux and Windows, ships as a Flatpak, AppImage, .deb, and distribution package on Linux, and exposes a D-Bus service that a script can drive. If your environment is Linux, or you want to switch mapping sets from outside the GUI, that D-Bus interface is the concrete difference. If you are on Windows and only need a simple key-to-button map, the extra machinery buys you little.

A second alternative is the controller configuration built into the application you are trying to use. Steam Input, for example, remaps controllers at the platform level. That approach keeps everything inside one runtime and avoids a separate process, but it only covers software launched through that runtime. AntiMicroX operates at the desktop level, which is why the README can claim it works with any desktop application, and also why it needs the permissions and session support that a per-application solution does not.

Licence, upgrade cost, and what GPL-3.0 means for your setup

AntiMicroX is licensed under GPL v.3, and the README points to the LICENSE file in the source tree for the full text. For an end user running the packaged binary, the licence is not something you interact with. For anyone redistributing the application, bundling it into a product, or linking it into a larger work, the GPL-3.0 obligations are real and worth reading rather than assuming. This is not legal advice; if redistribution is part of your plan, have someone qualified read the LICENSE text.

Upgrade cost is low in the ordinary case. Releases are tagged and packaged: 3.6.1 on 2026-05-24, 3.6.0 on 2026-05-06, and 3.5.1 on 2025-01-27. Profiles are the thing to preserve across upgrades, and the README links a separate ProfileTips.md in the repository root, which suggests profile behaviour has enough nuance to warrant its own document. Back up your profile files before a major version jump, and check that the packaged version in your distribution is not several releases behind, since the README's own packaging status badge tracks exactly that.

Editorial conclusion

Adopt AntiMicroX if you need to drive a keyboard-only game or desktop application from a controller on Linux or Windows, and accept that the project is asking for a new maintainer and is not adding features. Do not adopt it on Wayland if you depend on auto profiles, since the README states that per-window profile switching does not work there. Before committing, verify three things: that your controller is detected through SDL2, that your desktop session is X.org rather than Wayland if you need auto profiles, and that the packaged version in your distribution is recent enough for the mappings you need. The upstream maintainer question in discussion 1171 is the single fact most likely to change your decision.

Frequently asked questions

Official sources

1. AntiMicroX/antimicrox on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases