univrsal/input-overlay: keyboard, mouse and gamepad input on an OBS stream

The problem input-overlay solves, and who actually needs it

A viewer watching a speedrun, a rhythm game attempt or a fighting game match cannot see what the player's hands are doing. The capture shows the game, not the input device. input-overlay closes that gap by rendering keyboard, mouse and gamepad state as an overlay inside OBS Studio, so key presses and button presses appear on the same canvas as the game footage.

The audience is narrower than the topic list suggests. The README states the plugin is available for OBS Studio on Windows and Linux (64bit), which means anyone capturing with a different encoder, or on macOS, is outside the supported set. The second group is preset authors: people who build the visual layer, a keyboard image with lit key states, and share it. The repository carries a presets/ directory and a docs/ directory, and the README points to a separate web-based config creation tool, so the project assumes a split between the plugin and the artwork it draws.

If you want a standalone overlay window that works with any capture software, this is the wrong shape of tool. The integration is the product.

How the overlay gets from key press to OBS canvas

The dependency list in the README is the clearest statement of the architecture. input-overlay depends on libuiohook, mongoose and SDL2. libuiohook is the global input hook that reports keyboard and mouse events outside the plugin's own window. SDL2 handles gamepad input, which is why controller support is listed alongside keyboard and mouse rather than treated as a separate feature. mongoose is an embedded HTTP and networking library, and the repository layout backs that up: there is a client/ directory at the top level next to src/, which points at a network path between a capture-side client and the OBS plugin.

What the plugin draws is not hardcoded. Presets live in the presets/ directory, and the README links a converter for old *.ini presets to JSON, marked WIP, which tells you the current preset format is JSON and that older configurations exist in the wild. A preset pairs an image with a layout: the image supplies the visuals, the JSON describes where each key or button sits and how its pressed state is rendered. The config creation tool at univrsal.github.io/input-overlay/cct/ is where that layout is authored.

The practical consequence is that the plugin is only half the work. Installing it gives you a source of input events and an OBS source type. It does not give you a keyboard graphic you like.

Installing input-overlay and adding a first source in OBS

The README does not carry install steps inline. It says to head over to releases for binaries and links an Installation page on the GitHub wiki. That is the authoritative path, and it is the route most users should take.

If you are building from source instead of using a release binary, the top level has CMakeLists.txt, CMakePresets.json and a buildspec.json, and the project uses git submodules for its dependencies, which is why deps/ appears in the repository listing. A submodule-aware clone is required before configuring, or the dependency sources will be missing. The README does not give the clone command, so treat the CMakePresets.json file as the starting point and read it before configuring anything.

Once the plugin is in place, the workflow in OBS is the same as any other source: add the input-overlay source to the scene, then point it at a preset. The README does not document the exact source name shown in OBS, so confirm it in the Add Source list after installation.

For most users the release binary is the shorter path. Download the build for your platform from the releases page, follow the wiki Installation page for where the plugin file belongs on Windows or Linux, and restart OBS before looking for the source.

Presets, skins and the config creation tool

Search traffic around this project clusters on presets and skins, which matches where the friction actually is. The plugin ships a presets/ directory, but the README does not describe what is in it or promise a preset for your keyboard. The config creation tool is a browser page, so authoring a layout does not require a local build or a compiler.

The design is image plus coordinates. You supply a graphic, and the JSON preset records the position and appearance of each element on it. That is flexible and also manual: there is no automatic detection of key positions from an image. If you want a 60 percent keyboard layout with a specific colour scheme, you are placing those keys yourself in the tool.

Two constraints are worth stating plainly. First, the converter for old *.ini presets is labelled WIP in the README, so anyone migrating a large library of legacy presets should expect that path to be incomplete. Second, the README gives no schema documentation for the JSON preset format, so the config creation tool is effectively the specification. If you plan to generate presets programmatically rather than author them by hand, verify the format against the tool's output first.

Where input-overlay is the wrong tool

The clearest limitation is platform. The README says Windows and Linux (64bit) and nothing else. On macOS there is no supported path described in the repository, and no amount of preset work changes that.

The second limitation is the OBS dependency. If your workflow captures with something else, or you want an overlay that a non-OBS application can composite, this plugin does not help. The README's own framing, an OBS Studio plugin, is the boundary.

A third issue is that input capture is global. libuiohook reports input at the system level, which is what makes the overlay work when the game has focus, but it also means the plugin is not scoped to a single application. The README does not document any per-application filtering, so treat the overlay as showing what the machine receives, not what one game receives.

Finally, the project's documentation lives mostly on the wiki and the config creation tool rather than in the README. Anyone who needs a fully self-contained manual in the repository will find the README thin: it lists dependencies, links, and credits, and leaves installation and preset authoring to external pages.

input-overlay and NohBoard: two different answers to the same question

NohBoard is the comparison that keeps coming up in searches, and the difference is architectural rather than cosmetic. NohBoard is a standalone keyboard visualization application: it runs as its own window, and you capture that window into your stream. input-overlay is a plugin inside OBS Studio, drawing on the OBS canvas directly.

The trade-off follows from that. A standalone window works with any capture setup, including ones that are not OBS, and it does not care which encoder you use. It also means another window to manage, another process running, and a capture source dedicated to it. The plugin approach removes the extra window and the extra capture source, and in exchange it locks you to OBS on the platforms the README lists.

There is a second difference in how the visuals are produced. NohBoard has its own skin format and its own community of skins. input-overlay separates the plugin from the artwork and provides a browser-based config creation tool, which lowers the barrier for making a new layout but pushes you toward that tool as the source of truth for the format. Neither approach is strictly better. Pick based on what you capture with, not on which one has more presets.

Maintenance, licensing and what upgrading costs you

The repository is not archived. Its last push was on 2026-07-25, which is recent enough that the project is being worked on, and the most recent release listed is 5.1.0 from 2025-04-06, following 5.0.6 in October 2024 and v5.0.5 in March 2024. The release cadence is measured in months, not weeks, so plan upgrades around releases rather than expecting continuous change.

input-overlay is licensed GPL-2.0, and its dependencies carry their own terms: libuiohook under GPL-3.0, mongoose under GPL-2.0, and SDL2 under the zlib license. If you redistribute the plugin, or ship a build of it, those licences travel with it. The README states the dependency licences explicitly, which makes them easy to check, but it does not discuss redistribution scenarios. That is a question for someone qualified to answer it, not something to infer from the README.

The practical upgrade cost is presets. The README links an *.ini to JSON converter marked WIP, which means the project has already moved preset formats once. If you maintain a large set of layouts, keep the source assets and the JSON under version control so a format change is a regeneration rather than a rewrite. Nothing in the README documents a rollback path for a plugin version that breaks an existing preset, so test a new release against your presets before replacing a working install.

Editorial conclusion

Adopt input-overlay if you already stream through OBS Studio on 64-bit Windows or Linux and want input visuals tied to a scene rather than a separate window. Do not adopt it if your capture pipeline is not OBS, or if you need macOS support, since the README lists only Windows and Linux. Before committing, install the 5.1.0 binary for your platform, open the config creation tool, and confirm that a preset you build there loads and animates inside OBS on your machine.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. README
4. Releases
5. univrsal/input-overlay on GitHub