Here’s a summary about what’s needed to integrate the sixaxis support in GNU/Linux systems. Support will be official for GNU/Linux, but Sony won’t officially support us, of course.
Sixaxis needs the following functionality to work out the box on a linux system:
Association can be handled by udev with a userspace helper software.
A proof of concept of the helper program has been provided by pascal at pabr.org:
http://www.pabr.org/sixlinux/sixlinux.en.html
http://www.pabr.org/sixlinux/sixpair.c
An evolution of this software has been developed by Bastien Nocera:
http://thread.gmane.org/gmane.linux.bluez.devel/14354
http://www.spinics.net/lists/linux-usb-devel/msg11300.html
Basically the software gets the bdaddr of the primary BT adapter on the system and sets it in the Sixaxis memory. It will be handy if the helper script compiles and runs even without the BT libraries, letting the user add the bdaddr manually.
The current problem with both these programs is that they require to disconnect the joystick driver in order to do the association. This means that after the script is started the pad will no longer work as a pad until it is re-connected. This is due to a limitation of libusb which is used in the scripts (iirc). The idea is that the script should run each time the device is connected in order to check that the bt address is the correct one, basically breaking the pad↔joystick driver connection each time.
Question: should we keep track of associations to handle the leds setting on the Sixaxis?
...I don’t know very much about that, but in the end the BT subsystem should provide a HID device, and we would need a mechanism to talk to the HID device independently by its transport (USB or Bluetooth).
quoting pascal at pabr.org:
Linux BT already supports HID (e.g. keyboards and mice). However BT HID is not as feature-complete as USB HID (for example BT HID does not support the hidraw interface).
Decoding the data packets is essential to get the accelerometer/gyro data, and battery/charging status. That could be done with a kernel driver, so to expose to userspace the already decoded events. Ideally the data decoding part should be shared between operation via USB and Bluetooth.
Packet format is known thanks to Jim Paris: http://ps3.jim.sh/sixaxis/usb/ and Ranulf Doswell: http://wiki.ps2dev.org/ps3:hardware:sixaxis
The kernel driver could be modeled after the xpad one, even if the latter is USB only: http://lxr.linux.no/linux+v2.6.25.9/drivers/input/joystick/xpad.c
Encoding leds/rumble request could also be handled inside such a driver, maybe with some sysfs interface for custom applications..
At least two way to expose events to userspace should be provided, input event system and joydev interface. A hidraw interface could also be useful for advanced applications, there are patches to make it possible: http://www.pabr.org/sixlinux/sixlinux.en.html#inreqs
There are two main questions about user view:
Comment: Linux input API could do with a serious overhaul. Assuming there aren’t standard codes for that yet, one should think about future configurations that are likely. The Wii has already demonstrated two sets of accelerometers in two separate handheld devices, though neither currently provides full six axis encoding. So, there could be at least 6+6 axes. Future body position encoders could have far more. At a minimum, there should be pitch+roll+yaw+x+y+z for each accelerometer set on each controller. The sony devices appear to send 8 bit data? Other accelerometers provide more bits. At least 16 bits, if not more, should be provided. The application should be advised of scaling to “g” or “degrees” as appropriate for a particular device if scaling isn’t done in the driver. The WiiRemote also has an IR camera position sensor and other devices might use an ultrasound position sensor to deal with accelerometer drift. JS_EVENT_AXIS handles absolute values, like a joystick position, though those may translate to a rate. But if you treated controller tilt data like a joystick input, you would get a derivative instead of the expected tilt. And things would be even weirder if you mixed gyro and accelerometer inputs. The sequence of motions is important. Rotating the controller before translating means something different than translating before rotating. A rotation or translation causes a different change in position depending on the rotations or translations which preceeded it. One approach would be to provide a JS_EVENT_INERTIAL
js_event.number:
0-7: first encoder set
0: Vx - Rate of translation in X direction (V stands for vector, not velocity in USB HID)
1: Vy - Rate of translation in Y direction
2: Vz - Rate of translation in Z direction
3: dRx - Rate of translation about X axis
4: dRy - Rate of translation about Y axis
5: dRz -Rate of translation about Z axis
6:
7:
8-15: second encoder set
...
120-127: sixteenth encoder set
js_event.value: left justify such that full range is -32768 .. 32767
However, this might be 3G (gravities) and 300 degrees/second on one device and 2G and 150 degrees/sec on another so application still must scale.
Or one could continue to use JS_EVENT_AXIS and applications would need to provide their own scaling, integral, derivative, or X,Y,Z,Rx,Ry,Rz options on those inputs. Still it would help if the application could identify the X,Y,Z,Rx,Ry,Rz sets from a common configuration. At least with the JS_EVENT_INERTIAL, there is an implied grouping. But /usr/include/linux won't reflect the new type if the driver is compiled separately from kernel. Thus, in the short term, using JS_EVENT_AXIS plus a permissively licensed SANE style shared library user space API that reads device specific configuration files could be appropriate. Here is a very crude file syntax. // This is joystick on top of a joystick (giving 4 axes), you hold the top part // provides, for example, translation and rotation // handle also has a top_hat, a trigger button, and a top button. // Also has a six axis inertial unit
control LEFT_JOY type analog_joystick {
X=axis(0);
Y=axis(1);
control TILT type articulated analog_joystick {
X=axis(8); // might subtract axis(0) to get tilt relative to room rather than bottom half
Y=axis(9); // might subtract axis(1)
Rz=axis(10); // Top portion can rotate left right.
trigger=button(0);
topbutton=button(1);
control TOPHAT type digital_joystick {
UP=button(2);
DOWN=button(3);
LEFT=button(4);
RIGHT=button(5);
}
}
}
control INERTIAL1 type inertial {
X=axis(2)*1.0; /* allows for expansion to full expression handling later */
Y=axis(3)*1.0;
Z=axis(4)*1.0;
Rx=axis(5)*1.5;
Ry=axis(6)*1.5;
Rz=axis(7)*1.5;
}
Application control mapping would present these to user as:
LEFT_JOY.X, LEFT_JOY.Y, LEFT_JOY.TRIGGER, LEFT_JOY.TOP_BUTTON,
LEFT_JOY.TOPHAT.UP, LEFT_JOY.TOPHAT.DOWN, LEFT_JOY.TOPHAT.LEFT, LEFT_JOY.TOPHAT.RIGHT,
INERTIAL1.RAW.X, INERTIAL1.RAW.Y, INERTIAL1.RAW.Z, INERTIAL1.RAW.Rx, INERTIAL1.RAW.Ry, INERTIAL1.RAW.Rz,
INERTIAL1.PROCESSED.X, INERTIAL1.PROCESSED.Y, INERTIAL1.PROCESED.Z, INERTIAL1.PROCESSED.Rx, INERTIAL1.PROCESSED.Ry, INERTIAL1.PROCESSED.Rz
INERTIAL1.INTEGRATED.X, ....
As well as: LEFT_JOY, INERTIAL1, LEFT_JOY.TILT, TOP_HAT.
Raw values would be rates as they came from the controller, processed values would reflect the position and rotation of the controller in 3D space, and the integrated values would simply be integrated independently. For example, in an etch a sketch game you shake the controller along its Z axis to erase and move it in X and Y to draw and it’s coordinates are relative to controller and not to the room. I.E PROCESSED = room relative motion and INTEGRATED = controller relative motion. If you want to turn a screw by spinning the controller 20 times, you use raw. If you want to activate the variable speed control on a power screw driver to do the same thing with a quarter turn followed by a quarter turn back, you use integrated. You could bind TOPHAT to a joystick function as easily as LEFT_JOY1, using a hierarchical selection list. Thus, you can treat TOPHAT as part of LEFT_JOY1.TILT or independent. You could bind the trigger button to “pause game” if you wanted to. With this, you can unplug one controller and plug in another and the game can use corresponding controls between them or guess at suitable controls. I.E. the trigger button on the flight joystick fires the afterburners and the trigger button on the weapons joystick fires the weapons.
Note that USB HID PID (Physical Input Device) doesn’t define inertial inputs but it does provide for actuators and the axis definitions above are consistent with the form in which those were defined. It also defines physical effects (force feedback) that may be applied to a control based on its position, rate, etc. MS DirectInput also uses X,Y,Z, RX, RY,RZ notation but no accelerometers? Microsoft has a [http://www.microsoft.com/whdc/sensors/ Windows Sensor and Location Platform]. [http://msdn.microsoft.com/en-us/library/cc974578.aspx accellerometers]. They Have SENSOR_CATEGORY_MOTIONwhich includes SENSOR_TYPE_ACCELEROMETER_3D, SENSOR_TYPE_GYROMETER_3D (as well as 1D and 2D), and SENSOR_DATA_TYPE_ACCELERATION_X_G, SENSOR_DATA_TYPE_ACCELERATION_Y_G, SENSOR_DATA_TYPOE_ACCELERATION_Z_G, SENSOR_DATA_TYPE_ANGULAR_ACCELERATION_X_DEGREES_PER_SECOND (per second squared, also _Y_, and _Z_ ). SENSOR_CATEGORY_IRIENTATION includes SENSOR_TYPE_COMPASS_3D, SENSOR_TYPE_DISTANCE_3D, SINSOR_TYPE_INCLINOMETER_3D (as well as 1D and 2D with data types SENSOR_DATA_TYPE_ANGLE_X_DEGREES, SENSOR_DATA_TYPE_DISTANCE_X_METERS, SENSOR_DATA_TYPE_MAGNETIC_HEADING_X_DEGREES (repeat for _Y_ and _Z_). With the crappy docs, it isn’t clear whether the driver scales value (which would necessitate floating point) to those units or whether it provides scaling coefficients to application; however, sensor drivers in windows are user mode drivers. Note that user mode drivers (similar to SANE?) could have an advantage when complicated geometric transforms are involved. Some input devices such as inertial systems, body encoders, and articulated devices such as human skeletons or articulated stylus digitizers could be very complicated. User space drivers could also handle USB/bluetooth transitions.
Also consider that a future controller might have continuous rotation encoder wheels, a trackball, a glide pad, coin changer, GPS and other time of travel absolute position systems, etc. In the case of the Wii Remote, it also has an IR Camera position
sensor.
Comment: since accelerometer based joysticks may be used in large numbers for applications like body position encoding and it is generally bad practice to impose small limits on the number of devices, driver should support at least 16 joysticks. Since there are 4 leds, binary encoding would be necessary to give each a unique visable id. However, binary may be confusing for users with 4 or fewer joysticks so perhaps use LED1, LED2, LED3, and LED4 for the first four then use the remaining 12 binary combinations for other joysticks. Or give an option for simple or binary encoding. ~~~whitis
Devices to consider: * Sony sixaxis * Sony DualShock 3 * DualShock 3 Clones: such as “New For Sony PS3 DualShock SixAxis Wireless Controller” sold by yinyinnewtech on ebay [http://cgi.ebay.com/New-For-Sony-PS3-DualShock-SixAxis-Wireless-Controller_W0QQitemZ260371020736QQcmdZViewItemQQptZVideo_Games_Accessories?hash=item260371020736] * Nintendo Wii Remote - May not use the same driver, but handling of accelerometers should be consistent. * [http://www.andrew.cmu.edu/~agr/pubpg/eWatch_bsn_06.pdf eWatch] Research project, bluetooth watch with accelerometer, etc.