FreePIE: scripting your mouse and keyboard from a Wiimote or a tracker

What the application actually bridges

FreePIE, the Programmable Input Emulator, is an application for bridging and emulating input devices. It has applications primarily in video gaming, but can also be used for VR interaction, remote control and other applications.

A typical application might be controlling the mouse in a PC game using a Wiimote. That example tells you the whole shape of the thing. You have an input device that the game does not understand, and you want the game to see a mouse. FreePIE sits in the middle, reads the device through a plugin, runs your script to translate the readings, and feeds the result into the virtual mouse and keyboard drivers that the game does understand.

The script is what makes it programmable. Device control schemes are customized for specific applications by executing scripts from the FreePIE GUI. The script language is based on the Python syntax and offers non-programmers an easy way to interface devices.

That last point is the design choice that separates FreePIE from most of its competitors. A tool that requires you to compile something is a tool for programmers. A tool whose configuration is a Python script that a non-programmer can read and lightly modify is a tool for the much larger population of people who want to map a controller and do not want to learn a plugin API.

The audience is therefore unusual for a technical tool: hobbyists and tinkerers in games and VR, researchers building input experiments, and developers who need a scripted input bridge rather than a driver.

The plugin system, and why the comparison with GlovePIE is the interesting part

The project states that it is very similar to the popular utility GlovePIE, but encourages open development and integration with any device. That sentence is the whole positioning, and it explains the architecture.

The software is designed to allow third party developers to add their own I/O plugins either through direct integration into the core library or through a separately compiled plugin mechanism. Two routes, and the difference matters. Direct integration means the plugin is compiled into the product, which is faster at runtime and gives access to internals. A separately compiled plugin means it is loaded at runtime, which is faster to distribute and lets a plugin exist without a fork of the whole application.

The repository layout shows the structure that supports this. There is a FreePIE.Core.Contracts project, which is the interface layer that a plugin implements, and a separate FreePIE.Core.Plugins directory, which is where the shipped plugins live. FreePIE.Core is the engine, FreePIE.GUI is the application, FreePIE.GUI.CodeCompletion is a separate project for editor assistance, and FreePIE.Console is a command line front end. There are also several test projects, FreePIE.Tests.Core, FreePIE.Tests.Core.Plugins and FreePIE.Tests.Test, plus a Lib directory and a BuildTools directory.

Having the contracts in their own assembly is what makes the separately compiled plugin mechanism possible, and having code completion as its own project tells you the scripting experience was treated as a first class concern rather than an afterthought.

The licence is GPLv2, which is worth noting given the comparison. A fork of a proprietary-adjacent utility that is copyleft means the plugin ecosystem inherits that constraint, which affects how third party developers are likely to distribute their work.

What the device support list actually covers

The changelog in the readme is the only place the feature set is enumerated, and it reads as a list of specific hardware handled over about eight years of development.

On the motion tracking and VR side, the history includes support for Oculus Rift, Oculus VR DK2, and repeated Oculus VR SDK updates, with sensor prediction added in settings, support for Razer Hydra, Hydra (Sixense) SDK emulation, the Vuzix tracker, the Yei 3 Space trackers, Carl Zeiss Cinemizer OLED, Razor hydra hemisphere tracking, and Tobii EyeX. TrackIR support arrived with a fix for TrackIR emulation for games like Euro truck sim 2, and Freetrack client spoofing was added with the client dll included, so Freetrack works even if Facetracknoir is installed.

On the input side, WiiMote support arrived first for buttons only, then Wiimote M+ and Nunchuck support with a custom library, and later Wiimote M+ calibration fixes with a calibration success event and a setting for M+ data fusion. The Wii Balanceboard and the Wii Classic Controller and guitar hero controllers came later, as did multiple XBox controllers, DirectX joysticks, MIDI devices in read only mode, and general button support in the mouse plugin.

Android support runs through a companion APK, with the protocol optimised at one point and the raw data made accessible to scripts. The Android APK was later rewritten as a service for a more stable experience, and multiple Android devices were added.

The output side includes vJoy virtual joystick support, replacing Headsoft vJoy with the Sourceforge open source vJoy, and ppJoy joystick emulation, along with a plugin for third party software to read and write from and to FreePIE.

Python scripts, command line autorun, and a curve editor

The scripting side has accumulated a set of small capabilities that matter more than they look.

The language changed to Python at version 0.4.211.0, and the engine has been updated since. Code completion arrived as an early beta at 0.3.115.0 and was improved repeatedly, with the last mentions noting various stability fixes for code completion and a cosmetic fix for code completion and Windows 8. The script editor also got ctrl+F among other improvements, and the error window was improved with a script line number for errors.

Scripts can be loaded from the command line, and an autorun file can be used from cmd with a file argument and the /r flag. The system tray feature lets you minimise to tray from the command line with /t. A portable mode was added at 1.6.512.0, so app files are saved in the program folder rather than in the user profile, and there was a fix for a performance issue with large script files.

The filter and mapping vocabulary is where the practical work happens. A deadband filter was added to eliminate drift with the more sensitive mouse emulation, and a continuous rotation filter was added to eliminate jumps in mouse emulation when passing tracker center, with a later spelling correction from filters.continousRotation to filters.continuousRotation. Other filters include scaled deadband, ensureMapRange and stopWatch, and spelling filters were added as a category.

There is also a curve editor, with an improved curve editor at 1.7.528.0 and an apply button added to Edit Selected Curve point for usability reasons, along with an improved Watch window. A curve editor is what lets a mouse mapping be non-linear, which is often the difference between a mapping that feels right and one that does not.

Installing it, and the fact that the release trail stopped in 2019

The installation story is short, and the reason is worth being explicit about. The latest downloadable installer can be found at the project page linked from the readme, and the readme points to the wiki for the scripting and plugin reference manual. There is no package manager entry, no container image and no cross platform build described.

This is a Windows application. The changelog makes the platform assumptions plain: FreePIE should now work on w7 and w8 without admin rights, there were fixes for the latest version of vjoy driver and a cosmetic fix for code completion and Windows 8, and the build tooling in the tree is a Visual Studio solution, FreePIE.sln, with BuildTools and a .nuget directory.

Now the maintenance picture, which is the thing to weigh. The repository is not archived and the last push was on 2026-07-16. The most recent release, 1.11.724, was published on 2019-01-22, before that 1.10.666 on 2017-10-14 and 1.9.629 on 2016-02-16. So the working tree receives commits while the tagged releases stopped seven years ago.

That combination has consequences. If you install the installer, you get 2019 software. If you build from the source tree, you get whatever the current commits contain, which may include fixes that were never released, and you are building a Visual Studio solution yourself. The changelog in the readme also stops at 1.11.724.0, so the readme is not a complete record of what changed after that point.

The practical approach is therefore to build from the master branch if you need anything newer than the installer, and to treat the wiki reference manual as the source of truth for the current script API, since the released documentation and the current code can drift apart.

Where FreePIE is the wrong tool

There are cases where this is a poor choice, and they are not unusual.

The first is current hardware. A 2019 release means no plugin for a device that appeared after it, and even the current source tree is a seven year old codebase for Windows. If you need a brand new headset, a new motion controller or a new phone to work with a game, the odds that FreePIE has a plugin for it are low, and the odds that you will write one yourself are high. That is a real cost.

The second is if you only need one well supported device to work. If the device you have is natively supported by the game, an entire input bridge between you and the game is unnecessary, and you inherit latency, calibration drift and a second failure surface for nothing.

The third is if you need something other than Windows. The tree is a Visual Studio solution and the changelog references Windows 7, Windows 8 and system tray behaviour. There is an Android APK, but that is a companion app for feeding device data to a Windows host, not an Android build of FreePIE.

The fourth is maintenance. A project whose last tagged release is from 2019 is a project you are adopting as-is, with no upstream to file a bug against. The readme points to the wiki, and there is a public issue tracker, but the recent commit activity does not suggest a stream of fixes.

The fifth is a scope misunderstanding. FreePIE emulates input devices. It is not a motion tracking system in its own right, it is not a VR runtime, and it does not solve the problem of a game that needs a different input paradigm entirely. It sits between a device and a game, and if the game is the problem rather than the device, FreePIE will not help.

Against a driver, and against writing the mapping in the game's own tool

Two comparisons put the value in perspective.

The first is against installing a driver for the device. A driver makes the device present itself as something the operating system already understands, usually a mouse, a joystick or a keyboard, and then the game works with no further effort. The difference in approach is that a driver is a fixed translation decided by the vendor, while FreePIE is a translation you write. A Wiimote as a mouse is a tilt-to-cursor mapping with a deadband and a curve, and there is no driver that will guess your deadband. So the trade is flexibility for effort: you get exactly the mapping you want, and you are responsible for it.

The second is against the mapping tools games ship with. A flight simulator or a racing game will have a calibration screen and an axis curve editor, and for a mouse or a standard controller that is faster than anything you would do in Python. FreePIE earns its place in the gap between those cases: devices the game has no concept of, such as a Wiimote, a phone as a sensor, a MIDI controller, or a head tracker, and mappings that are more than a straight axis assignment.

The 2019 timeline matters for this comparison, because the alternatives have moved. Native support for odd controllers has improved across the industry since then, and the plugin ecosystem of a modern title may well cover the device you were going to bridge. FreePIE's answer to that is the open plugin model and the scripts, which are still a good way to do something no game author anticipated. But it is worth checking whether the simpler route became available after the last release.

Editorial conclusion

Adopt FreePIE if you are on Windows, you have a device that has no game support, and you want to write the mapping yourself in Python rather than hunt for a driver. Skip it if you need current hardware support or a maintained project, since the last tagged release is 1.11.724 from 2019 while the last push was on 2026-07-16, so the working tree moves but the releases do not. Verify first that a plugin exists for the device you want to use, and that the script API your mapping needs is covered by the wiki reference, because the plugin list is the project's real feature set.

Frequently asked questions

Official sources

1. AndersMalmgren/FreePIE on GitHub
2. Issues
3. README
4. Releases