Using RetroPie 2.2 with GPIO no longer works

[Wilstorm]

I just finished building a home arcade kit called Porta-Pi that runs RetroPie 1.9.1 and uses Retrogame as the input. It works wonderfully and is a great alternative to buying a dedicated input device. Not to mention I actually learned something working on something I love to do! :)

I recently tried to upgrade RetroPie to version 2.2 and it longer works. After some searching the programmer of RetroPie/EmulationStation posted this on a forum:

"I have the same problem as you. I asked Aloshi (creator of EmulationStation) on the Raspberry Pi Forums and this is what he said:

This probably has to do with the change from SDL 1.2 to SDL 2. SDL2 uses evdev for input handling (in the console in the Pi). I don’t remember what SDL 1.2 uses. Not much I can do about this, sorry."

I don't know anything about programming but I have learned a lot about Unix just doing this project and really enjoyed it. Is there any chance in a future version this could possibly incorporated into retrogame.c. It's a fantastic piece of software and I really appreciate all the work put in to it.

Also I use to use an older version that didn't require downloading ncurses and expat(?) but after rebuilding my SD card I had to download the newer version and also download the additional software. Is there a repository or link you might share to download the older version without the new additions?

Thank you and have a great morning!

[ladyada]

Hi there, thank you for the issue request! It sounds like something that the Porta-Pi seller can/should be helping with since they bundled this (handy but free and unsupported) software. We use retrogame mostly for our CupCade project and it works swimmingly there :) Do you have their email address? Are they on Github? Thank you!

[Wilstorm]

Ok, I appreciate the quick reply. I don't believe he is on Github nor do I think he is programmer type guy that would be able to handle this challenge. I looked at the code and had to back up my bus as I think it's going to take someone with knowledge and experience to make the type of changes required to make it work again with SDL2 and keep the backwards compatibility with SDL1.2. I do appreciate the feedback though and have a great day! ;)

[ladyada]

Hmm, not sure what to say - we don't know how to adapt this to evdev input. We'll check it out some day in the future. You may want to ask him to hire a programmer to do the adaptation for his customers - sounds like it would be appreciated! :)

[Wilstorm]

I think you said it well! I figured if it wasn't an "easy" change or it couldn't be adapted now maybe in the future. I was definitely going to contact the vendor and at least share some of the information and get some feedback. I think he's a one man operation working out of his apartment but it can't hurt to at least try!

Do I just close this...I see a 'close and comment' button? I have to say I just signed up and this is my first post.

[ladyada]

Nope you can leave it open, we or some enterprising other person may be able to fix & close :)

[CrazySpence]

I just ported OpenParsec to the Pi quite literally yesterday and I have hit the same problem as it uses SDL2 as well. This conflicts with my goal of having a gaming box with arcade controls only and no keyboard so you can bet your ass I'll work something out or die trying!

Stay tuned.

[ladyada]

watch out, crazy spence is gonna go EVDEV CRAZY!!!

[Wilstorm]

lol...that made my day!! Thanks LadyAda and Crazy Spence I will keep an ear to the ground...I think that's the saying! :)

[CrazySpence]

evtest picks up retrogame no problem so this should work one would think.... unless it is missing something in the initial configuration that is causing sdl2 to ignore it. Comparing retrogame to an actual input device there does appear to be some config values that differ significantly (using udevadm and evtest to check). Also the way the kernel stores it may be playing in whether SDL ignores it perhaps...(/devices/virtual/input# for retro game vs /devices/platorm/bcm_somthing/usb/blah/blah/input# for real hardware) I will continue to look into this. I've been upto my eyeballs in udev and evdev docs, forums, source all afternoon now. I'm taking a break

[Wilstorm]

Ok, I would not pretend to fully understand that but if there's anything I can do or to test it just let me know and have a great evening!

[CrazySpence]

seems SDL2 is very specific in the properties it looks for in udev devices, ID_INPUT_MOUSE and ID_INPUT_KEYBOARD, ID_INPUT_JOYSTICK. Which makes it kind of annoying for any user made uniput devices as all the tutorials and docs i've come across show types ID_INPUT_KEY, ID_INPUT_REL and ID_INPUT_ABS (keyboard, mouse, mouse) so I would bet even a basic uinput mouse wouldn't get along with SDL2 until they were altered to be more specific in their identification. anything that doesn't fit those 3 properties is dropped from SDL2's internal device list.

[CrazySpence]

I just added a case for ID_INPUT_KEY to SDL_udev.c and blammo, retrogame works. blasted SDL folks.

[CrazySpence]

if you rebuild your SDL2 with the changed SDL_udev.c file I have put in my fork https://github.com/CrazySpence/Adafruit-Retrogame it will work. I'm going to ask the SDL folks why they decided to ignore ID_INPUT_KEY in the meantime

[Wilstorm]

That's awesome! Thanks CrazySpence!! I have a beginner question. So do I replace the file SDL_udev.c file to the specified directory and then run "make clean all" with the existing retrogame.c or download the whole fork?

I made a change before and when I would run the command "make" it would say everything is up to date or something to that effect. That's when I found the "make clean all" command OR "make clean" and "make all" in a forum and that seemed to work. I don't know if there's a difference.

Also in your retrogame-arcadegame.c is the Vulcan Nerve Pinch for Enter KEY_LEFTALT + KEY_X? Is that how you read "const unsigned long enterMask = (1L << 6) | (1L << 12);" 6 and 12 being the 6th and 12th item in the structure(?). The description above refers to the Cupcade pinout so it's a bit confusing for us amateurs. ;)

Lastly another HUGE thank you for updating this! I really appreciate it and I hope you have a wonderful weekend!! :)

[CrazySpence]

no what you need to do is go to the SDL2 source tree and put that SDL_udev.c file in src/core/linux in the SDL2 source tree and then just type make and it will rebuild that one file then make install it. That's all I had to do. You dont need to rebuild or restart retrogame and you probably don't want to use my retrogame files because I have hacked them to the high hills. You only want the SDL_udev.c file for your SDL2-2.0.3 source tree directory

[CrazySpence]

I've also filed a bug with SDL2 if we're lucky they'll just include this in a future SDL2 release...but in the mean time you'll have to do some trickyness.

[Wilstorm]

Ok, perfect! I will test it tonight! Thank you for the explanation as I would have done that all wrong trying to figure it out. I have learned a lot about the Pi just trying to recreate the nostalgia of the old arcade experience of the "golden age" of arcades. If they do include the change or you figure why they ignore the ID_INPUT_KEY would you let us know or is if safe to always use the modified file for a while?

[Wilstorm]

Hey Spence, I can't seem to find src/core/linux on the Retropie image so I downloaded the newest Raspian image and still can't find it in the home/pi or the /root directory. Could you help direct me to the correct location?

[CrazySpence]

When I say SDL2 source tree I mean you need to download the SDL2 source and build it.

The other option is creating a udev rule which I haven't tried yet but was suggested by someone from SDL.

On Jul 19, 2014, at 6:50 PM, Wilstorm notifications@github.com wrote:

Hey Spence, I can't seem to find src/core/linux on the Retropie image so I downloaded the newest Raspian image and still can't find it in the home/pi or the /root directory. Could you help direct me to the correct location?

— Reply to this email directly or view it on GitHub.

[Wilstorm]

Sorry Spence, I know I sound like a complete git but when I search for SDL, SDL2, I seem to get tons of results and I am not quite sure which one it is, would it be possible to get the link or is there an apt-get command I could run?

[Wilstorm]

I downloaded the file SDL2-2.0.3.tar.gz from http://www.libsdl.org/download-2.0.php (I am not sure if it's the correct one) but I ran "./configure; make; make install' and it runs for about an hour and then it fails with several pages of warnings and a few errors like:

Errors: /home/pi/SDL2-2.0.3/src/core/linux/SDL_udev.c:1042:70082 stray '#' in program /home/pi/SDL2-2.0.3/src/core/linux/SDL_udev.c:1085:18: error: expected identifier or '(' before numeric constant

Warnings: 'character constant to long for its type [enabled by default]' 'multi-character character constant [-Wmultichar]

All of them in SDL_udev.c.

[Wilstorm]

I tried putting back the original file and running the command "./configure; make; make install" and it failed with permissions errors. Then I ran "sudo su" and ran the command again and it did run to completion with no errors!

I think it doesn't like the change in the SDL_udev.c and I think I have downloaded the correct SDL2.0.3 package.

[kagedmonkey40]

CrazySpence, Wildstorm

I just built one of these retro mame stations as described on Adafruit and ran into this issue. This Raspberry Pi is my first linux project so I am a complete noob- I was able to burn the disk image to my SD card and then make retrogame.c with my inputs and get it running but that is as far as my skills/knowledge can take me. I would be massively grateful for more information/instructions on what to do to get retrogame.c working on my raspberry pi w/ retro pie and emulation station. I'm sure the folks at adafruit would appreciate it as well as in searching for a solution I see many people have taken the path directed by adafruit and are hitting the same wall as I am.

[kagedmonkey40]

Ladyada, I built my machine as per the instructions on adafruit, using all parts I purchased from adafruit and using all software and links provided on adafruit. I feel a bit taken now since it doesn't work and adafruit is not wanting to fix their instructions or take them down all together. I've spent a good part of the past 2 weeks dreaming about making this mini retro arcade game machine and now I am frankly wishing I could send all the parts back.

[CrazySpence]

To use my SDL2 work around, that was made by me and not affiliated with Adafruit at all as I just follow them around github and twitter all the time cause they're awesome.....

You need to do the following:

1 download sdl 2.0.3 https://www.libsdl.org/release/SDL2-2.0.3.tar.gz 2 extract SDL via command line "tar zxvf SDL2-2.0.3.tar.gz" 3 get my copy of SDL_udev.c with "git clone http://github.com/CrazySpence/Adafruit-Retrogame" on the command line (if you copy/paste it or anything through the web browser it may get changed to CRLF and that breaks stuff) 4 cd into the SDL2 directory, probably "cd SDL2-2.0.3" 5 ./configure

6. wait forever until it's done then back out with "cd .." 7 copy the changed file I made "cp Adafruit-Retrogame/SDL2.0.3/src/core/linux/SDL_udev.c SDL2-2.0.3/src/core/linux/" 8 cd back into the sdl directory "cd SDL2-2.0.3" 9 make 10 wait forever 11 sudo make install

If you run into any problems where it says there's funny characters in the file then somehow it got converted to CRLF instead of LF you can "apt-get install dos2unix" and run it against the SDL_udev.c file "dos2unix SDL_udev.c" to fix it

If you run into any dependency problems, missing programs or libraries SDL needs, distribution problems (retropie just changed something that makes this harder I heard) , compiler problems etc please consult your nearest linux pal as it has been confirmed to work by myself and others and unfortunately I can only take you so far.

I am looking into easier solutions but for now ^ there it is

[CrazySpence]

you can jump on my bugzilla thread with SDL, maybe if more than just me are on it they'll come back with something better than "make a udev rule" https://bugzilla.libsdl.org/show_bug.cgi?id=2654

[ladyada]

@kagedmonkey40 - right now we don't have an immediate fix because there's layers & layers of underlying stuff that need to be fixed. If we can get the SDL team to fix this odd bug, thats the ideal situation!

Our tutorial does not use retropie, we recommend installing the emulators like MAME4ALL directly https://learn.adafruit.com/retro-gaming-with-raspberry-pi/emulators Can you clarify which ones of those don't work? If so we can label which ones do and don't work. We labeled RetroPie 2+ as not working (we never tried RetroPie to start with)

If you can get retropie 1.9.1 image, you can use that, since that was the last known working (see OP).

Or - If you feel like this project is not working out for you, email support@adafruit and they will arrange a refund on the parts!

[PaintYourDragon]

kagedmonkey40: is this with the Cupcade kit and corresponding pre-configured SD card image? Or are you referring to the prior retro gaming guide, the one with the standalone Pi using an HDMI monitor?

[kagedmonkey40]

This was for https://learn.adafruit.com/retro-gaming-with-raspberry-pi/overview The difference with my project is I put it all into a mini iarcadie cabinet w/ a 2.5 inch screen so I have an arcade cabinet that is just 6 inches tall.

On Wed, Jul 23, 2014 at 3:23 PM, Paint Your Dragon <notifications@github.com

wrote:

kagedmonkey40: is this with the Cupcade kit and corresponding pre-configured SD card image? Or are you referring to the prior retro gaming guide, the one with the standalone Pi using an HDMI monitor?

— Reply to this email directly or view it on GitHub https://github.com/adafruit/Adafruit-Retrogame/issues/5#issuecomment-49944552 .

[kagedmonkey40]

Thanks for the response.

I had to go with retropie/emulationstation on mine as I needed a front end that would be visible on a 2.5 inch screen. I have put the entire project into a arcadie cabinet (http://www.arcadie-arcade.com/home.php the iPhone one). I tried to find a retropie 1.9 image that would also have the old emulationstation on it but could not locate one.

I cant return the parts as I have already soldered everything together and even removed the RCA jack on my Pi in order to wire directly to the 2.5 inch monitor (no space in the case for the RCA plug. I saw a few other solutions on the web for wiring into a usb keyboard controller but I just do not have space in this tiny cabinet for anything else.

On Wed, Jul 23, 2014 at 3:13 PM, ladyada notifications@github.com wrote:

@kagedmonkey40 https://github.com/kagedmonkey40 - right now we don't have an immediate fix because there's layers & layers of underlying stuff that need to be fixed. If we can get the SDL team to fix this odd bug, thats the ideal situation!

Our tutorial does not use retropie, we recommend installing the emulators like MAME4ALL directly https://learn.adafruit.com/retro-gaming-with-raspberry-pi/emulators Can you clarify which ones of those don't work? If so we can label which ones do and don't work as of 4 days ago.

If you can get retropie 1.9.1 image, you can use that, since that was the last known working (see OP).

Or - If you feel like this project is not working out for you, email support@adafruit and they will arrange a refund on the parts!

— Reply to this email directly or view it on GitHub https://github.com/adafruit/Adafruit-Retrogame/issues/5#issuecomment-49943601 .

[ptorrone]

we do not sell or promise anything with retropie, we have no tutorial for retropie. this is outside what we sell/support, thank you! closing issue now.

[PaintYourDragon]

pt -- nono, I screwed this up. My sincerest apologies to kagedmonkey40 and everyone else here.

For some reason this clicked in my walnut-brain as "folks trying alternate bleeding-edge stuff on the Cupcade; the rest of us are using the stock SD image and it's not a pressing concern until if/when we burn a new SD for that." Turns out it's NOT on the Cupcade at all...seems the walkthrough provided by our prior Pi retro gaming guide no longer works as described.

I've got another short guide to wrap up tonight, might take an hour or so. After that I'm 100% focused on fixing the explanation in the guide and/or the retrogame code, whatever it takes to get this back in working order ASAP.

[Wilstorm]

@kagedmonkey40 - This also works with Retropie v1.10 which is located right on their site. I just completed a setup last night and works really well.

I think the issue is strictly with Emulationstation 2.x which is incorporated into RetroPie 2.x as it's written with SDL 2 whereas Emulationstation 1.x incorporated into RetroPie 1.x which is written with SDL 1.2. The creator of RetroPie basically said take a hike which isn't in the spirit of things but well within his rights!

But even running RetroPie 2.x GPIO input will still work with the emulators themselves, such as Mame4all. The issue is starting RetroPie which loads Emulationstation and then the GPIO inputs stop working. If you use a keyboard to start the emulator such as Mame4all then GPIO input works again. Then when you exit the emulator back to Emulationstation it stops working. So basically it's Emulationstation written WITH SDL2 is the challenge. It pretty much defeats the purpose of using a multi-emulator frontend like RetroPie 2.x until retrogame.c is usable again but each emulator on it's own works fine.

I suppose the progression will be to move to SDL 2.x over time so we might have to be patient. Adafruit doesn't support the RetroPie project so it's not their challenge to take on. If they do make it work in the future or as 1.2 is phased out that's just a bonus for us as so many multi-emulator front-end projects like RetroPie, PiPlay, etc. use Adafruit's retrogame.c when using GPIO as the input.

As for CrazySpence he has no affiliation with Adafruit at all and is helping us as he has his own vested personal interest in it working BUT that by no means obligates him to help us so once again it's a BIG bonus for us that he is trying to provide a workaround to us and the community.

@CrazySpence - I tried a few times and failed last weekend BUT with your new set of instructions I plan to try again as I was just plain copying things around using WinSCP so I will you let you know how it goes. We have a family vacation coming up this next week to take our youngest to FL to spend time with her grandpa and grandma...they are getting old and my other half has deemed we shall go forth and make our presence known in the great state of FL, whether I like it or not...in-laws...aaargh! ;)

And as always thank you very kindly CrazySpence, LadyAda and PaintYourDragon. I think retrogame.c is so widely used in so many projects that in time it will work again but you guys have been awesome and patient, thank you! :)

[tdicola]

I took a look and think I have a udev rule that's easier to setup than compiling SDL2 with a custom patch. This rule should find the retrogame keyboard device and assign the ID_INPUT_KEYBOARD=1 property that SDL2 seems to require (and what the patch posted earlier changes). I tested it out with buttons wired up according to the guide (at https://learn.adafruit.com/retro-gaming-with-raspberry-pi/buttons ) and it seems to work with emulation station and the latest retro pie v2.3. When I press up/down/left/right etc the frontend navigation works as expected. Can folks here give the udev rule a shot to see if it helps and confirm it works?

To apply the rule, connect to your pi in a terminal/SSH session and create a new file /etc/udev/rules.d/10-retrogame.rules by running the nano text editor. Execute:

sudo nano /etc/udev/rules.d/10-retrogame.rules

Nano should open to a blank file, then copy in this line exactly:

SUBSYSTEM=="input", ATTRS{name}=="retrogame", ENV{ID_INPUT_KEYBOARD}="1"

Press Ctrl-O and then enter to save the file, then press Ctrl-X to exit. Restart your raspberry pi, then make sure retrogame is running (either explicitly run it, or let it run automatically if configured to do so in your rc.local file). Load up emulation station or other frontends that use SDL2 and try pressing the buttons that retrogame is listening to, hopefully you'll see the key presses occur as expected. Let me know if this works for folks here.

[PaintYourDragon]

If you have a moment please test the following. Back out any udev rule changes or whatnot; work from a "vanilla" system on which you have the retrogame source.

Edit retrogame.c, look for this line: if((fd = open("/dev/uinput", O_WRONLY | O_NONBLOCK)) < 0) change to: if((fd = open("/dev/input/event0", O_WRONLY | O_NONBLOCK)) < 0) then disable the 19 lines that follow, i.e.:

if 0

    if(ioctl(fd, UI_SET_EVBIT, EV_KEY) < 0)
            err("Can't SET_EVBIT");
    for(i=0; i<IOLEN; i++) {
            if(io[i].key != GND) {
                    if(ioctl(fd, UI_SET_KEYBIT, io[i].key) < 0)
                            err("Can't SET_KEYBIT");
            }
    }
    if(ioctl(fd, UI_SET_KEYBIT, vulcanKey) < 0) err("Can't SET_KEYBIT");
    memset(&uidev, 0, sizeof(uidev));
    snprintf(uidev.name, UINPUT_MAX_NAME_SIZE, "retrogame");
    uidev.id.bustype = BUS_USB;
    uidev.id.vendor  = 0x1;
    uidev.id.product = 0x1;
    uidev.id.version = 1;
    if(write(fd, &uidev, sizeof(uidev)) < 0)
            err("write failed");
    if(ioctl(fd, UI_DEV_CREATE) < 0)
            err("DEV_CREATE failed");

endif

Save changes, exit editor, recompile: make retrogame Move retrogame to wherever you keep yours (/usr/local/bin or whatnot). Then either reboot system or hunt down the current retrogame process, kill it and start a fresh one in the background.

Test emulator(s) of choice; Mame4all, emulationstation, etc. Any improvement?

[Wilstorm]

@Tdicola - That worked perfectly! Is that a typo RetroPie 2.3 as I could only find RetroPie 2.2. I downloaded a fresh copy of the RetroPie 2.2 image and only had Retrogame installed and everything worked perfectly for assigning keys and navigating Emulationstation.

@PaintYourDragon - While I am out and about for lunch this afternoon I am going to swing by the house to do a quick test and will let you know this afternoon. Can I disable the whole block with a start and end command/characters or should I put a # in front of each line?

EDIT: @PaintYourDragon - I apologize, I see how you commented out the block.

Thanks you sirs, you are true gentlemen and scholars! ;)

[Wilstorm]

@PaintYourDragon - when I run 'make clean all' with suggested changes I received this warning:

retrogame.c: In function âmainâ: retrogame.c:233:25: warning: unused variable âuidevâ [-Wunused-variable]

[tdicola]

Here's where I saw the RetroPie 2.3 image: http://blog.petrockblock.com/retropie/retropie-downloads/

That warning should be ok to ignore for now, it's just the compiler being extra strict about unused variables.

[Wilstorm]

@tdicola - Gosh am I completely missing it?? I only see a direct image download, mirror and torrent for v2.2 with v1.10 image download also at that link.

Of note I did do several other tweaks after running 'make clean all' with the modifications but after a reboot I was completely locked up (black screen). That warning shouldn't have caused that, should it? I did a cold reboot several times before reloading the image and starting from scratch.

[PaintYourDragon]

The warning can be ignored. This is just a quick patch to the code, and if it works then I can clean it up so it won't complain like that.

The retrogame changes shouldn't cause a black screen; it's not even loaded until later in the boot process. If you're getting -nothing- at boot, the SD card might be corrupted. Have another you can test booting from?

[Wilstorm]

@PaintYourDragon - That worked perfectly too!! :) It recognized GPIO inputs as keyboard strokes. I was able to configure Emulationstation, start Mame4all, and exit out with no issues. Will you be posting revised code for the program? Also would this work with SDL 1.x also or do we keep an older version around just in case for projects that don't support SDL 2.x? I suppose we'll some of both for a while?

[PaintYourDragon]

@Wilstorm - if it works across the board, then yes, it will be incorporated into the mainline code (maybe I'll leave The Old Method there with an #ifdef around it just in case).

Not sure about SDL 1.X compatibility, but I assume so...I think that's what MAME4all is using. If anyone can test/confirm, would be much appreciated.

[Wilstorm]

@PaintYourDragon +1 for mame4all. I just finished testing mame4all-rpi and it does work well. Why is that? I figured it wouldn't but I was playing Metal Slug fine. I don't know how to confirm the version but it does play with no issues.

[PaintYourDragon]

Couldn't tell you why. This gets into some low-level geeky stuff over my head. Near as I can tell, /dev/input/event* is a newer and shinier events API than /dev/uinput. Supporting both in SDL may have been a drain on the developers' time and resources or something.

[CrazySpence]

They (SDL) are too specific in their udev block on what they look for. This is a very clever work around I look forward to adapting my branch and trying it out. I still hope they (SDL) fix the udev block to include ID INPUT KEY as this also affects python input scripts and some gaming keyboards that let you rearrange the layout

Good work.

[PaintYourDragon]

Okay, I've put the SDL2 fix into the mainline code, but IT IS NOT ENABLED BY DEFAULT. The change was not compatible with Cupcade or PiGRRL, which take precedence since they're the Adafruit projects this was really intended for (and does in fact work with the version of mame4all_pi as documented in the Adafruit tutorial). If it's useful in other projects, awesome, have fun with it, it's an easy switch in the code to enable the SDL2-compatible case and recompile. If it's not, at this point I must mention that bit in the BSD license about "merchantability and fitness for a particular purpose."

[kagedmonkey40]

I actually ended up dismantling an old USB keyboard that had a board in it small enough to fit inside my tiny case and I wired my controls straight to this board and soldered the wires from it directly to the USB power and D+/- lines on the bottom of the PI. This way I'll never have to worry about code changing somewhere and my machine quit working. IT would be cool if someone made a really tiny (quarter sized) configurable USB encoder type component. I found something called "Kade" but it looks as if it would have been too big to fit in my case.

On Sat, Jul 26, 2014 at 12:46 AM, Paint Your Dragon < notifications@github.com> wrote:

Okay, I've put the SDL2 fix into the mainline code, but IT IS NOT ENABLED BY DEFAULT. The change was not compatible with Cupcade or PiGRRL, which take precedence since they're the Adafruit projects this was really intended for (and does in fact work with the version of mame4all_pi as documented in the Adafruit tutorial). If it's useful in other projects, awesome, have fun with it, it's an easy switch in the code to enable the SDL2-compatible case and recompile. If it's not, at this point I must mention that bit in the BSD license about "merchantability and fitness for a particular purpose."

— Reply to this email directly or view it on GitHub https://github.com/adafruit/Adafruit-Retrogame/issues/5#issuecomment-50226354 .

[Wilstorm]

@PaintYourDragon - Is there any changes required to use the new retrogame.c? I mean does anything need to be un-commented or can it be used as is? It looked like it's detecting it automatically with the else-if? Possibly the changes are used in conjunction with creating the file 10-retrogame.rules or do you use one or the other?

The reason I ask is I am still using the quick changes you made but I am going to upgrade to the "official" change.

EDIT: Ok I see to use the new retrogame.c I need to change the "#if 1" to "#if 0". My only question would be do I make that change and also create the 10-retrogame.rules file or just one or the other? I know both worked in testing but now that it's official I was just trying to get some clarification.

[PaintYourDragon]

@Wilstorm - for most users it'll just be compile & install. There are two cases where editing the source is still necessary:

1. Any changes from the default GPIO-pin-to-key mapping. Edit either the ioTFT[] table (if using an Adafruit PiTFT display) or ioStandard[](if using an HDMI or composite monitor).
2. For SDL2 compatibility, look for the block starting around line 355 ("Set up uinput" comment) and change "#if 1" to "#if 0".

make; sudo make install; sudo reboot

[Wilstorm]

@PaintYourDragon - Ok that makes perfect sense, thank you. Just one more question for clarification if that's ok. I will be using SDL2 should I also in addition create the file (10-retrogame.rules) you explain in the description? Is it two ways to fix the same issue and only one is needed at a time?