Wiimote/Library

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

Try out an experimental Windows driver, GlovePIE, here.

Download Linux Test Application

Wiimodulator.py 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 wiimodulator.py now!

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.

Problems

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.

Requests

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.

Here is a proposed scheme to manage access to the different features. Each feature will be individually associated an open mode flag. The daemon will either grant complete access to all features requested or grant none, it is up to the program to fall back to less features if needed.

An extra flag allows the open operation to succeed even if the data requested cannot be returned; when using this flag operations always succeed if they are well-formed, but the data will not be returned until conditions can actually be satisfied (e.g. until a higher-prio program closes their exclusive access). This is useful for e.g. lower-priority daemons that may be started in a starved-for-data condition while a higher-prio program is running. This would be a separate flag, not included in the table below. OPEN_DEFAULT If the feature is available without disturbing any other clients, it is opened. The feature may be shared. If it is not available, an error is returned. OPEN_EXCL_LOW No clients with lower (higher numerical) priority may have this feature open. If they do, an error is returned. OPEN_EXCL No clients may have this feature open. If they do, an error is returned. OPEN_FORCE_CONFL If any lower-priority client is using a feature that conflicts with this one, it is temporarily deactivated (no data is returned for that feature), in order to grant us access to the feature we want. OPEN_FORCE_EXCL_LOW If any lower-priority client is using this feature, it is temporarily deactivated (no data is returned for that feature), in order to grant us exclusive access to it. OPEN_FORCE_CONFL_EXCL_LOW A combination of the previous two. OPEN_FORCE_EXCL Same as OPEN_FORCE_EXCL_LOW, plus no higher-priority clients may use this feature either. OPEN_FORCE_CONFL_EXCL Same as OPEN_FORCE_CONFL_EXCL_LOW, plus no higher-priority clients may use this feature either.

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), F_EXT_BUTTONS, F_EXT_MOTION, F_EXT_ANALOG, etc.

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

Wii bluetooth specs

External links

• General information/documentation about Bluetooth
• Specification for the bluetooth HID profile
• Post to bluez-devel regarding driver development
• QJ - Gamer discovery: Wiimote to PC pairing
• High Res Panoramic of Wiimote Top Side PCB
• High res images of the wiimote hardware
• Press release from Analog Devices regarding the Wiimote
• ADXL330 3-axis iMEMS® acceleration sensor
• EE times article mentioning Broadcom BCM2042 wireless sensor with Bluetooth functionality
• BCM2042 Advanced Wireless Keyboard/Mouse Bluetooth® Chip
• WiinRemote, a Japanese implementation similar to the Wiimote driver