The next step in getting the controller to work as a RetroPie controller is writing a driver so the console interprets the serial data coming in from the Bluetooth module the same way it would interpret a USB controller.

I got this idea from petRockBlog who mapped their custom, two-player joystick to two separate virtual controllers in RetroPie.  Their code is available on GitHub.  After a quick review, I saw that their code is using a C user input emulation library called uinput.  In the interest of simplicity I found a Python uinput library and decided to use that to emulate my controller driver.

Below is a full snippet of the code from the GitHub repository followed by an explanation of how it works:

This is the definition of the Controller class.  A static variable called NumButtons is used to show the maximum number of buttons a Controller has.  A Controller instance is initialized with a path to the Bluetooth serial device which it then connects to.  The initialization also creates a uinput Device that it will use to simulate a virtual controller for providing input to the console.

An array of keys is created to represent the possible input keys that will be passed into the system.  Right now I’m just using the letters of the alphabet.  RetroPie offers full controller customization so the actual keys used don’t really matter.  I still plan on changing the controller driver to emulate a joystick with analog controls, however, so this method will need to be updated in the future.

This array will store the device names for all of the Bluetooth serial consoles.  At some point I’d like to autodetect all of the serial consoles from the controllers but for now a hardcoded array will work.

The program creates a controller for each serial console in the ControllerNames array and stores them in the Controllers array.  It also resets the serial input buffer so old input data doesn’t bog down the driver and it can start processing the most current data.

My driver operates on button transitions (unpressed->pressed and pressed->unpressed) rather than operating on the button state.  This is to be consistent with keyboards which work in the same way.  Because of this transition-based processing, the previous input packet needs to be stored so the previous packet can be compared to the current packet and differences between the two can be detected.  Here the previous packet is instantiated as a dictionary and is initialized to a known, totally unpressed state.

This is just an infinite loop which iterates over the list of controllers and processes each of them.

A line is read from the serial port and split at the colon.  The left side will be the key character which reflects the type of data and the right side will be the data itself.

This if statement detects which key is seen and executes the appropriate code.

This is the code for the key ‘K’ which is the only type of data I currently have.  It iterates over each character in the eight bytes of data and compares it against the data from the previous packet.  If the value went to ‘1’ from ‘0’ it emits an event to signal that the key was pressed and if the value went to ‘0’ from ‘1’ it emits an event to signal the opposite.