ModChips | HDD | Online | Miscellaneous | Exploits | Tutorials | Media Players | Launchers | SwapMagic Tools | Emulators
(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.
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!
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
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.
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
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:
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.