OpenGamepadUI is a launcher that assumes a controller in your hands

A launcher designed around a controller, not a keyboard

Open Gamepad UI is a free and open source game launcher and overlay written with the Godot Game Engine 4, and its stated goal is to provide an open and extendable foundation to launch and play games, with a gamepad native experience in mind. That last clause is the whole design brief. A launcher written for a mouse and keyboard has to be re-imagined for a controller, and the re-imagining is the value here, since every menu, every list and every dialog in the project assumes a pad. The project also implements a gamepad input system that allows gamepad input to be remapped to mouse and keyboard, which is the bridge that makes a controller-first interface usable with a game that only speaks mouse. The readme carries a warning that this project is currently in the very early stages of development, and it should be read as a description of the code rather than as a disclaimer about the plan.

The overlay is the feature, not the library browser

The feature list leads with in-game overlay menus, which is the part that distinguishes this from every other launcher. A library browser is a table of games, and there are many of those, but an overlay that appears inside the running game and can be driven with the same controller is a different proposition, because it lets you change settings, check performance or start something else without leaving the game. The second feature is the power tools, TDP control, SMT and the rest, and those are not implemented here but delegated to another project by the same organisation, PowerStation, which handles the machine level controls. That division is worth noticing, because it is the shape of the wider ecosystem, with this project owning the interface and its siblings owning the hardware and input layers, and the launcher itself, the game sources, the artwork and the plugin system being the parts that live in this repository.

Input remapping is somebody else's job

The third feature is fully configurable gamepad input, buttons, axes, mouse and keyboard, and it is implemented through InputPlumber, another project from the same group. The reason to delegate this is that input handling on Linux is a large problem of its own, involving the kernel layer, the device hotplugging and the difference between a controller and a remote control, and a launcher that tried to own all of it would spend its time there. The per-game customizable gamepad profiles are the feature that ties it together, since a controller layout is a property of the game rather than of the system, and storing it per game means a racing wheel or a flight stick can be configured once and remembered for the game that needs it. The two projects together are the reason the overlay can be driven without a keyboard, and reading them as a pair tells you more than either does alone.

The build is a Godot export with a native extension

The Makefile is the most informative file in the repository for an engineer, and it shows a project that is careful about what it produces. The install prefix defaults to your home directory, and there is a cache directory and a rootfs directory for the pieces the exported application needs at run time. The version is read out of a Godot resource file, the `core/global/version.tres`, rather than being written in two places, and the Godot version and release are parsed out of the `godot --version` output so the export template path can be built from it, pointing into the export templates directory for your Godot revision and matching build type and architecture. The architecture mapping is explicit, with x86_64 exporting as x86_64 and aarch64 as arm64, and the default is the host architecture. The output includes a native extension, a shared object built for Linux under the build type and target architecture, alongside every GDScript file, scene and resource in the tree, and the export templates are fetched from the Godot releases on GitHub.

Gamescope and a rootfs make the overlay possible

Two variables in the Makefile explain how the overlay reaches into a running game. The first is gamescope, the compositor that runs the game, and the command line the project uses passes an embed flag and a count of two Xwayland instances, so the launcher can run alongside the game inside the same compositor session. The second is the rootfs, the small filesystem the exported application carries so that it has the files it needs at run time without depending on what is installed on the host. The rest of the build machinery is standard, with a Docker image for the builder published as `ghcr.io/shadowblip/opengamepadui-builder`, and a set of remote debugging variables that mount a path over SSH from a development machine to a target, which is the sort of convenience that tells you the project is developed on a small cluster of Linux boxes with a pad in each of them.

Documentation, plugins and how the project is laid out

The documentation is hosted on readthedocs and split into four guides, an install guide, a user guide, a developer guide that covers building from source, and a plugin guide. That last one matters because the plugin architecture is a listed feature, and a plugin guide is the difference between an extension point and a documented API. The repository layout is consistent with a Godot project that has grown into a product, with a `core/` directory for the main application, `plugins/` and `addons/` for the extension points, an `extensions/` directory for native code, a `package/` directory, `assets/`, `docs/`, a `docker/` directory, and a `rootfs/` directory for the runtime files. The Godot project itself is at the root with `project.godot`, an `entrypoint.tscn` and an `entrypoint.gd` with its resource UID file, and there is an `export_presets.cfg` that describes the Linux export. The `mkdocs.yml` and the readthedocs configuration sit alongside a CREDITS file and a release configuration, so the project publishes its own docs and cuts its own releases.

Early stages, and what that means in practice

The warning at the top of the readme says the project is in the very early stages of development, and the version numbers support the reading. The releases are v0.46.1 from 2026-09-03, v0.46.0 from 2026-07-25 and v0.45.1 from 2026-07-15, so the numbers are moving quickly through a pre one phase, which is what a project looks like while the interface is still changing shape. The last push to the repository was on 2026-10-13, so the work continues. What that means for somebody adopting it is that the documentation, the install path and the plugin API are all likely to move under you, and the sensible approach is to treat the project as a foundation to follow rather than a launcher to depend on, which is also how the readme describes itself, an open and extendable foundation. The two sibling projects, PowerStation for the machine level controls and InputPlumber for the input layer, are the parts you are most likely to end up using directly whatever happens to the launcher.

Editorial conclusion

OpenGamepadUI suits a Linux player who is comfortable with a controller and wants a launcher, a settings screen and an overlay that all work the same way, and it suits a developer who wants to build on a gamepad-native interface rather than a keyboard one with a controller bolted on. It is a poor fit if you need a finished product, because the readme says plainly that the project is in the very early stages of development, and it is a poor fit if you want to run it on Windows, since the build is a Linux export with a native shared object. Before you try it, check three things: the documentation, which has separate install, user, developer and plugin guides, that your distribution or the gamescope setup matches the assumptions the build script makes, and which version you take, with v0.46.1 published on 2026-09-03 and the last push on 2026-10-13.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. ShadowBlip/OpenGamepadUI on GitHub