uLaunchELF v4.42b

Open PS2 Loader v0.8

SMS Media Player v2.9 R4

Free McBoot 1.8b

ESR beta r9b

Open Ps2 Loader Guides & Tutorials

Free MCBOOT Guides & Tutorials
Wiimote Driver


General info

(A technical description of the Wiimote and its interface is available on the Wiimote page)

The Wiimote appears to use the USB HID class to communicate with the Wii. It also supports SDP.

Download Windows Driver

Download Linux Test Application doesn't deserve to be called a driver... It's a very poorly written proof of concept, which I rushed to do in a few hours with no prior knowledge of bluetooth. It works under Linux. You need pybluez.

Get now!

Download Linux Wiimote-to-Joystick Daemon

Using wm2js you can use your Wiimote like a normal Joypad (/dev/input/jsX). The daemon is written in C and needs libbluetooth (bluez) and uinput support


Current status

Connection to the Wiimote using hidd, sdptool, and hcitool all work. SDP and HCI seem to work correctly but there seems to be some problems with HID.

A connection can be set up using hidd --connect <bdaddr> afterwards button presses can be seen by running hcidump -X. The kernel registers the connection and creates a event file for the controller in /dev/input/. The connection can later be destroyed using hidd --kill <bdaddr> or hidd --unplug <bdaddr>.

To write HID commands to the wiimote you'll need to patch bluez-utils-2.25/hidd/main.c and recompile. Afterwards do mkfifo /tmp/hid and then write data of the form '%x %x %x ..' to /tmp/hid after connecting with hidd.


HID Specs

LED's are controlled using a SET_REPORT HID request on Output channel 11. The left 4 bit's are the only ones that matter and correspond (in order) to the LED's.

Force feedback can be turned on and off using a SET_REPORT HID request on a either Output channel 10, 11, 13, 14, 15, or 19. Using channel 11 is not advised since it messes with LED's. To turn force feedback on set the least significant bit to 1.

Linear force data can be logged using a SET_REPORT HID request on Output channel 12. The first parameter is a force feedback parameter while the second must be 31. Some other 3X numbers work for the 2nd parameter and do different things, but I'm not sure what exactly. Logging can be turned back off using 30. (example to turn logging on: 52 12 02 31) When logging data data with 31 the last 3 bytes of data represent the forces with ~80 being 0 force. The 1st bit represents the side to side force, the 2nd is the lengthwise force and the 3rd is the up-down force.

The 3x number seems to set the Report type returned, and the valid selections (and report lengths) match the input reports in the Wii Bluetooth Specs HID Descriptor. Selecting either 0x3e and 0x3f causes the wiimote to return alternating 3e and 3f reports.

See Wii Bluetooth Specs HID Descriptor for a decoding of the HID descriptor block reported by the Wiimote.


Linear force data can be logged using a SET_REPORT request, however rotational data currently can not be logged. Both are needed in order to obtain decent positions due to the force of gravity. There's a chance that the calculations are done in the wiimote at not sure how to set it to do so. (There's evidence that the controller only has a 3-axis sensor, so any rotation information may need to come from interpretation of the 3-axis sensor readings, possibly combined with the sensor bar position reading...) The speaker does not work but may be controlled with a SET_REPORT HID request.


Can someone attempt to capture some of the communication that happens between the Wiimote and the Wii during synchronization? Using hcidump (from the bluez project) could be useful. Data regarding the Wii's bluetooth capabilities. Attempt to initiate a connection to the Wii acting like a Wiimote and see how it responds. Port to unix (for OS X) when linux driver is done Examine the Japanese WiinRemote software

Linux driver architecture and ideas

The Linux Wiimote driver, wiimoted, will be based on hidd. It will run in userland and will require no extra kernel modules. wiimoted will automatically or manually connect to discoverable wiimotes. It will set the LEDs to something sensible.

There is no reason to have a 4 remote limit; let's allow for the 7 devices maximum that Bluetooth supports (using LED combinations, for example: LEDs 1 through 4 will be used as expected, followed by two on the left for the fifth remote, two on the right for the sixth, and finally all four for the seventh).

wiimoted will expose a socket interface for other programs to connect to it. Using ASCII or binary communications is up for debate.

Programs which connect to wiimoted can choose to associate themselves with any combination of remotes available to wiimoted, and will be able to query their capabilities, accessories, etc. Each wiimote will be considered a separate entity, and all further aspects of communication with wiimoted are per-remote.

Programs may request any combination of features from the remote. Multiple clients may use the same remote at once. Since there are fundamental limitations in certain feature combinations, a priority mechanism must be designed.

Clients that connect to wiimoted will specify a priority level. Lower numerical values for priority are considered to take precedence over higher values (same as the UNIX process priorities). Negative values are allowed.

Note: the previous system discussed here was deemed too complicated and possibly inconsistent, and has been replaced with a simpler one.

Here is a proposed scheme to manage access to the different features. Each feature will be individually associated an open mode flag set. Three flags may be specified in any combination:

F_REQUIRED If this flag is set and the feature is not available at this time (with the constraints set by the other features), an error is returned. If the feature is revoked later due to a higher-prio client override and this flag is set, the whole connection to this Wiimote is closed with an error. Otherwise, while a feature is not available, a notification is sent to the client, but it is still kept open and pending, and the feature and data may be made available at a later time.
F_FORCE If this feature cannot be granted due to other clients, we are willing to force lower-prio clients into closing or disabling features (depending on the status of their F_REQUIRED flag). This won't work with higher-prio clients of course.
F_EXCLUSIVE We require to be the only users of the feature. The effects of this depend on the prior two flags. If F_FORCE is set, we might force lower-prio clients to pause or stop connections on this feature. If F_REQUIRED is not set, we don't get data even if it would be available, as long as other (lower-prio) clients are using the feature.

Features would be things such as F_BUTTONS, F_MOTION, F_IR_STD, F_IR_EXT, F_IR_FULL, F_FULLSPEED (pseudo-feature that excludes F_IR_FULL since it halves speed - note that F_EXCLUSIVE is meaningless here), F_EXT_BUTTONS, F_EXT_MOTION, F_EXT_ANALOG, etc.

The algorithm for this simplified system should be pretty simple. Just walk along the priority chain of clients, high to low priority, and grant the features as you see them, while pausing or rejecting features that are in conflict.

Ideas for clients:

  • Mouse emulation daemon. Plugs into the kernel via uevent, and sends mouse events to an event device. Buttons mapped onto mouse buttons or keys. This could also be done with an X client using the XTrap extension, instead of going through the event subsystem.
  • Linux generic joystick. Plugs into uevent. Could be merged with the mouse emulation.
  • Gesture recognition, in similarity to mouse gestures and what Nintendo and AiLive are using, LiveMove [1]. Many games use such "gestures" for control. A classifier can be trained to recognize such gestures (based on raw acceleration data). A classifier can be based on hidden Markov models. Alternatively, a clustering technique based on wavelet transforms could also render suitable. Implementing the math is fairly straightforward. There's many examples in academic literature (search for accelerometer, gesture, recognition, classifier, ...).
  • Game engine mod. Say, hack Quake 3 (which is GPL) to use the Wiimote natively.
  • Virtual keyboard tailored to the Wiimote. I'm not talking the stuff we see on the Wii, since that could be done with mouse emulation and xvkbd easily. Instead, experiment with faster typing schemes using the wiimote. I especially like the typing system that Pogoshell / libpogo for the GBA uses. An adaptation of that to the Wiimote would be awesome.
  • beryl / compiz interface. 'nuff said.
  • Media player control
  • Audio player for the Wiimote speaker (don't expect much quality, but could be useful for effects)
  • Calibration application
  • Mii creator with support for saving to the Wiimote to transfer back to the Wii :)

See also

External links

Untitled Document
Powered by vBadvanced CMPS v3.2.3

All times are GMT -7. The time now is 04:41 PM.
Powered by vBulletin Version 3.8.5
Copyright 2000 - 2011, Jelsoft Enterprises Ltd.

Valid CSS!


Applications - Forums - List - Skins - Arcade

Disclaimer - FAQ - Donate

Page generated in 0.11556 seconds.
Copyright © 2004 - 2017
All rights reserved.
No affiliation with Sony Computer Entertainment or Nintendo Company, Ltd.