The ultimate sixaxis emulator

Several input devices (keyboards, mice, wheels, joysticks…), several bluetooth dongles…

Guess what?

I’m thinking to make the sixaxis emulator capable of emulating several sixaxis at the same time, and reading several input devices at the same time (several mice, several keyboards…).

The emuclient process (responsible for grabbing input events) will connect to several emu processes (responsible for connecting and sending data to the PS3).

The bad thing is that the SDL 1.2 is not designed to handle multiple mice/keyboards (unlike joysticks). For mice and keyboards, the origin of an event can’t be known.

With the coming SDL 1.3, it seems that multiple mice can be handled at the same time thanks to the merge of the ManyMouse library.

I looked closer to the source code, and it seems that multiple keyboard can be handled by the SDL 1.3 too!

EDIT 12/06: the multi-mouse / multi-keyboard support has been removed from the trunk of the SDL library. It will be re-added in a near future => the multiple sixaxis emulator is postponed.

15 Replies to “The ultimate sixaxis emulator”

  1. Hello MATLO

    That is awesome.Emulating more than one sixaxis is exactly what I've been wanting to do.Do you plan to do it with the hidemulator also? I've been planning to make an app that uses the hidemulator so I've been reading up on Python since it is said to be a good first programming to learn for beginners.

    I still have ALOT to learn. Im trying to wrap my head around syntax, objects and methods and all that.Then the bluetooth socket programming…

    I did some searching and found that Bluez supports up to 6 dongles simultaneously.I've been searching for a project that uses multiple dongles to study how they wrote the code but I havent had any luck.

    Do you know of any such projects or sample codes?

  2. Hi,

    Unfortunately, I don't plan to come back to the hidemulator because I don't have enough time to do it.

    The sixaxis emulator works great with games (the hidemulator can't be used to play as is), and the code written by Jim Paris was a great start point (I like the client/server architecture).

    The only python code I used with multiple bluetooth devices is in the sixpair-emu customizer source code:

    The read_bdaddrs function tries to open a socket for a device id in range (0,32), and then calls the read_local_bdaddr which reads the bdaddr of the device. The socket probably can be used to open a connection and send data.

  3. I didn't find out how to specify the dongle to be used (even in C code), but I have found a work-around that could be used with pybluez too.

    Assuming that you have two dongles listed as "hci0" and "hci1" by the hciconfig command:

    1- disable hci0: sudo hciconfig hci0 down
    2- launch a first emulator
    3- verify the first connection is using hci1: sudo hcitool -i hci1 con
    4- enable hci0 (sudo hciconfig hci0 up)
    5- launch a second emulator
    6- verify the second connection is using hci0: sudo hcitool -i hci0 con

    Note that it doesn't work "as is", I'm having issues getting the second emulator working.

    Using the sixaxis emulator, the tcp port of the server has to be changed. There is something else to change, and I don't know what for now.

  4. I got a hcidump for each emulator, and it seems the second connection aborts just after being established.

    The trick probably makes the bluez stack bug :[

  5. I already knew it's possible to directly speak with the hci layer, but doing that to handle a l2cap connection, the l2cap layer has to be embedded in the application, and the kernel probably has to be patched (see

    I'd rather patch the bluez stack than the kernel.

    The l2cap example at shows that it is possible to bind a socket to a (bluetooth adapter, port).

    I quickly tried that yesterday but without success. The bind() is mostly called before a listen() (like in the example, on a server side), and I don't know if a bind() can be used before a connect() (on a client side).

    I'll look closer at that bind function. Then, if there's no choice, I'll patch the bluez stack.

  6. The l2ping.c provided with the bluez source code performs a bind before connect so as to specify the local address, so I guess this should work…

  7. According to this kernel code:

    – l2cap_sock_bind, l2cap_sock_connect and l2cap_do_connect functions in l2cap.c

    – hci_get_route function in hci_conn.c

    it seems calling bind before connect should work, I probably did something wrong the time I tested it.

  8. No, I don't think some bt inquiry is performed in background and the problem is probably too old to remain unresolved (2003-10).

    The project you pointed out shows another example of calling bind before connect (see line 844).

    I'll try that ASAP.

  9. Calling bind before connect works perfectly.

    The problem is that if any sixaxis is already connected to the PS3, connecting a sixaxis emulator will fail.

    So I think the trick I tried wasn't making the bluetooth bug.

    The problem is, as it is most of the time, in the applicative layer.

  10. This functionality is postponed (see EDIT at the end of the post).

    I still will investigate the multiple connection.

    I planned to do it this way: using the sixaxis proxy, I will get the hcidump for two real sixaxis and try to figure out what goes wrong with the sixaxis emulator.

  11. I only need the hcidump of the connection, so that I think the kernel patch is not necessary. But I didn't managed to get it work.

Leave a Reply

Your email address will not be published. Required fields are marked *