HID Wiimote & Stream for the next 5 Months

Some may have wondered, others may have already seen my tweets. I’ve moved to Oslo for a 5 months student exchange program last week. So this means i have only my Laptop with me and that is unfortunately not powerful enough to stream. So for the next 5 months, until January, there won’t be any streams from me 🙁
Also i think i wouldn’t find the time for  streaming, since during student exchanges you have better things to do, like exploring the country and so on.

But when i do have some spare time i am going to try to get some work on HID Wiimote done. So at least i am trying to get official Windows 10 Builds done asap. Hopefully they will be available within the next weeks, but i need to find some spare time to install Windows 10 (twice, once on my Laptop and then a second time on a VM) and then setup my development environment, etc.

Until then you can use the Windows 8.1 builds on Windows 10. Someone mentioned they are working just fine. Just don’t forget to turn on the Testmode.

So at the end a photo i took of the wonderful and idyllic nature here in Norway 😀

Sognsvann Lake near Oslo

HID Wiimote Update – 13.07.15

Just two small fixes.


  • Fixed LED Battery Level display for Wii U Pro Controller
  • Each Classic Controller (Pro) & Wii U Pro Controller Trigger has its own input axis

HID Wiimote Source Code available

Wuhu! I have published the Source Code of HID Wiimote on Github.
Some have already asked for it, now i finally did it!

Check it out: https://github.com/jloehr/HID-Wiimote

I am going to fill it with Issues and Milestones in the next days.
But you can add Issues on your own, when encountering a bug.
If you manage to fix a bug, or come up with a cool feature, feel free to contribute.
Fork it, fix it, send a Pull Request!


IR-Mouse HID Wiimote Hotfix

Small hotfix for the IR-Mouse version of HID Wiimote. I stupidly removed the Hardware ID from the .inf file, thinking the IR-Mouse doesn’t need it, because the “-TR” Wii Remote shares it with the Wii U Pro Controller.

Added it back to the .inf file and made a new package batch. When you want to use the newer Wii Remotes with the IR-Mouse driver, uninstall the old one and get the fresh packages from the download page.

Since the Wii U Pro Controller has the same Hardware ID as the newer Wiimotes, the IR-Mouse driver gets also loaded for the Wii U Pro Controller, although it doesn’t have an IR-Sensor.

Changes to IR-Mouse

  • Hotfix for IR-Mouse to enable “-TR” Wii Remotes

HID Wiimote Update 01.06.15

I’ve finally finished the IR-Mouse Version of HID Wiimote!
With that driver you are able to control your mouse pointer by pointing your Wii Remote at your screen. You just need some kind of IR source with up to four points, but best is a Sensor Bar.
The input is slightly steadied but has therefore a small input delay. You can download the driver from the HID Wiimote page. If you are looking for the old DPad-Version you can find it here.

Additionally i made a small update to the Gamepad Version. I fixed a small issue, so the input state is reset when the connection to the controller is lost. You can get the update from the project site as well.

Next i am going to work on the XUSB communication, so i can create a XUSB/XInput Driver for the Wii U Pro Controller.

New IR-Mouse Version

  • Tracks up to four IR-Points
  • Interpolates with previous points to steady
  • Therefore slight delay

Changes to Gamepad

  • Input State is reset, when the connection is lost

HID Wiimote Update 20.04.2015

Wii U Pro Controller

Yay, Update for HID Wiimote! The Nunchuck and Classic Controller (Pro) Extensions are now supported. In Addition to that the Wii U Pro Controller is supported as well.

I’ve added a lot of Buttons and some more Axis as well as a Hat Switch to the Properties Dialog. The Button Mapping switches dynamically when an Extension is plugged in.

With my Wii Remote the Extension is sometimes not correctly detected. In that case you have to remove the Extension and plug it in again until it works (Sometimes take up to 10 tries; but maybe my Wiimote has just a loose contact and there is normally no such problem).

My next task is creating an IR-Mouse driver as many have requested. I’ve already made quite good progress on that.

I would be very happy when you spread the news and this Blog entry or the HID Wiimote Project Page is shared on Facebook, Twitter, Reddit and all other sites.

Last but not least, i am streaming my coding sessions on Livecoding.tv and Twitch.tv. So feel free to join my streams and ask questions. My regular streaming schedule is every Monday starting at 08:00 PM (Berlin/UTC+1).

So get the newest version here.


  • Nunchuck, Classic Controller (Pro) and Wii U Pro Controller are now supported
  • Added more Axis, Buttons and a Hat Switch
  • Unfortunately no more Vista Builds
  • Windows 8.1 Build

Small Update & Streaming

Here is a small update on the progress on HID Wiimote. I’ve almost finished up extension support for the Nunchuck, Classic Controller (Pro) and Wii U Pro Controller.
So i’m confident to release the new build in 1 or 2 weeks.

In the meantime i started to stream my coding sessions on HID Wiimote. So this means you can watch me working on it. My streaming schedule is every Monday starting at 8:00 AM (Berlin/UTC+1). Additional there might be spontaneous streams, so follow me on my streaming channels and Twitter to get notified. My streaming channels are:

After finishing the extension support, i am going to start on an IR-Mouse Driver Version.

OpenAL-MOB with openFrameworks on Android


On work i am currently working on a mobile game project. We are using openFrameworks v0.8.4 in combination with OpenAL for Audio output because we need the HRTF for binaural sounds. The OpenAL implementation is OpenAL-MOB, since it’s an OpenAL-Soft fork with HRTF support and especially supports mobile platforms.

To get OpenAL-MOB integrated into openFrameworks we are using our own wrapper, but the openFrameworks Addon ofxALSoft will do just fine. Just merge the OpenAL-MOB folder into the ofxALSoft addon folder and you are ready to go.


Our main target platform is iOS, so my development system is a Mac OS X. I am therefore referring to the Mac Terminal, but for Linux and Windows the steps should be the same.

To get OpenAL-MOB running and deployed on an iOS Device is quite easy. Just add the ofxALSoft addon and the OpenAL-MOB-ios XCode project to your openFrameworks project in XCode. XCode compiles OpenAL-MOB and links it into your app on its own. So everything is fine.


Our second target platform is Android and the last couple of workdays i tried to get the project running on our Android device.

Currently openFrameworks supported Android IDE is still Eclipse, so i am referring to Eclipse. If you use Android Studio you might to have adjust some additional things.

The problem with openFrameworks for Android is it uses custom makefiles to compile your openFrameworks project and create a shared library. Additionally it is ignoring the Android.mk and Application.mk generating them each build.

OpenAL-MOB provides Android makefiles but since openFrameworks ignores its Android.mk you can’t create a dependency. Even worse due to openFrameworks custom makefiles the addons are compiled as well and everything is linked into one shared library. In this linking process the ofxALSoft addon needs something to be linked again, which is the OpenAL-MOB lib, that needs to be built beforehand.


I came up with a way to get it running anyway. I didn’t create a dependency to automatically  build OpenAL-MOB each deplay, but rather build the library manually. However if you won’t change OpenAL-MOB you just to need to build it once.

The first step is to build a static library of OpenAL-MOB and then include it into the linkage of the openFrameworks shared lib of your project.

Building OpenAL-MOB

Adjusting the Makefile

Open Android.mk in “Path/to/of/addons/ofxALSoft/build_android/jni/“.

First we need to add one compiler flag otherwise we will get some linker errors later when building the openFrameworks project. So add beneath the “ifreq … else … endif” block around the LOCAL_CFLAGS:

LOCAL_CFLAGS += -fno-stack-protector

Second change it to build a static library instead of a shared one. To do so change the last line from




At the end the bottom half of the file should look like:

# set the platform flags
ifeq ($(APP_ABI),x86)
 LOCAL_CFLAGS += -D HAVE_NEON -mfloat-abi=softfp -mfpu=neon -marm

LOCAL_CFLAGS += -fno-stack-protector




Now we are ready to compile it. The ndk-build tool is a little bit broken (or it was in revision 9b) because it evaluates the ifreq … block just once in a call so we need to run two compile passes. First compile for ARM and then in a second run for x86.

Open Application.mk in “Path/to/of/addons/ofxALSoft/build_android/jni/” and set

APP_ABI := armeabi armeabi-v7a

Now open a Terminal and navigate with cd to “Path/to/of/addons/ofxALSoft/build_android/jni/“. Run “Path/to/ndk/ndk-build” in this directory to compile it.

If you get compile errors because he can’t find some header files, specify the APP_PLATFORM argument. You can either add it to your Application.mk file or pass it as command line argument to ndk-build. And make sure the specified Android Version is included in the NDK package.

After building the static libraries for ARM open “/addons/ofxALSoft/build_android/obj/” and rename the folder local to android. OpenFrameworks will later search for the static lib in a directory structure similar to “*/android/$(abi)/libname.a“. Furthermore ndk-build cleans previously build static libs for all target in the local directory when run. So it would delete our previously build libs on the second build pass.

For the second build pass set

 APP_ABI :=x86

in the Application.mk and run ndk-build again.

Copy the “local/x86” folder into “android/x86“.

We now have three static libraries of OpenAL-MOB for each architecture. And can start to add them to the openFrameworks project.

Adding it to your Project

At last we need to include the OpenAL-MOB library into the openFrameworks make process.

Navigate to your openFrameworks project folder and open config.make.

First we need to add the library headers to be included for the addon. Add


at the appropriate position.

Then we need to include the static lib into the linkage. Add

PROJECT_LDFLAGS += $(OF_ROOT)/addons/ofxALSoft-MOB/build_android/obj/$(ABI_LIB_SUBPATH)/libOpenAL-MOB.a

for the linker flag.

Now hit run or build all in eclipse and your project should successfully compile and deploy to your device.


As said the OpenAL-MOB library is built manually, but unless you modify it you just need to build it once and can add it to your repository as prebuilt library. There might be a way to include the build into the openFrameworks makesystem but since i don’t need that i am skipping that step.

HID Wiimote Update 12.10.2014

It has been a while since the last update, but i didn’t had a lot of time in the last couple of months. Due to that this is just a minor update. I looked into the problem with the certificates and the driver signing. Unfortunately i wasn’t able to remove or avoid the necessary driver signature verification deactivation on 64bit systems. But at least i got Windows into loading my driver over the default one, so changing the driver each time should be gone now.

Additionally someone requested to have a driver to use the Wii Remote as mouse.  I’ve made a special build, so the Wii Remote is recognized as mouse. You can move the mouse with the DPad, left and right click is on 1 and 2 and the middle mouse button is mapped to B. In the future i’m going to work on another build to control the mouse with the IR sensor, but this will take some additional time.

Last but not least someone other requested also to have Vista builds. So from now on i will provide Vista builds as well.

Get the newest version here, or the direct download directory


    • Added another installer, so Windows will use HID Wiimote as default driver for the Wii Remote
    • PDad-Mouse Build

HID Wiimote Update 01.07.2014

Today i borrowed a Wii Remote with Plus inside, one of the newer ones (RVL-CNT-01-TR) with the Sync Button on the battery cover. My hearings were true, they have a different hardware ID, but that was just a minor problem and fixed with one line in the INF-file. The bigger problem was, that they differ a little bit in behavior. So in the end you can’t connect the new Wii Remotes by pressing the 1 and 2 buttons, instead you have to use the Sync button each time. There were some additional trouble, but i fixed that as well.

Another new feature are a second X and Y axes for tilt. Currently tilt is only tracked by the accelerometer, so it’s a little bit inaccurate and you have to hold the Wii Remote still. The Motion Plus gyroskop is not supported yet, but that will be my next task. You might need to recalibrate the asxes via the gamecontroller properties dialog. The reason is, that all Wii Remotes are not well calibrated, so the middle, minima and maxiuma are a little bit shifted.

Hower, newest version can be downloaded here: HID Wiimote


  • Added support of the newer Wii Remotes (RVL-CNT-01-TR)
  • Added second X/Y axes representing tilt (Currently only tracked by the accelerometer) 
Properties dialog with driver
Properties dialog of the new driver verion