SDL2 and retrogame
July 18, 2014
It doesn’t work!
Or does it…
Anyways as usual in my quest for using my Arcade controls to do just about everything I ran into a snag with OpenParsec yesterday…. Turns out it wasn’t accepting my arcade controls.
In a convenient sort of way the main retrogame git had a user pop in complaining of the same problem. Well this just won’t do at all I thought and I jumped into the problem!
I spent a lot of the day in udev and evdev docs and I did evtest and udevadm tests and EVERYTHING says retrogame works with evdev but it wasn’t with SDL2.
After my brains felt melted I took the day off to think about it and went back into it about an hour ago. This time combing through SDL2’s code as my tests earlier proved retrogame was working with evdev as far as Linux itself was concerned.
SDL_udev.c
val = _this->udev_device_get_property_value(dev, "ID_INPUT_KEYBOARD");
if (val != NULL && SDL_strcmp(val, "1") == 0 ) {
devclass |= SDL_UDEV_DEVICE_KEYBOARD;
}
I was reading through this file and came through a case block where it identifies devices. It bases this on whether the udev has the property ID_INPUT_JOYSTICK, ID_INPUT_MOUSE or ID_INPUT_KEYBOARD. Boom there it was. retrogame only identifies as ID_INPUT_KEY but to me it didn’t seem to make sense why they would be so specific when in some cases other devices may identify as ID_INPUT_KEY or ID_INPUT_REL/ABS instead of the obvious KEYBOARD or MOUSE. So anyways I posted my changed file on github and I am going to ask SDL why and see if it was an oversight or had a proper purpose.
If you use retrogame just rebuild your SDL2 with the file I provided and your arcade controls should be working again. Might also fix python and other gpio input scripts with SDL2, let me know!
Categorized as: What's up
Facebook Comments