After setting up the excellent debian bullseye (next stable debian version) on the clockworkpi by using clockworkpi-debian and the forum thread I set out to try to compile EmulationStation on this recent and up to date system.
I’d be happy to. I don’t own a devterm, but if they had the same distribution base, it would be possible.
I would love for the two devices to converge and have a recent, up to date distribution to stand on. For common software, my best bet would be to have a debian packages repository with the customized software. But this would require the community and clockworkpi to get behind it to motivate those involved.
@arthur I have been playing with this too, I did get a version to run on the clockwork-debian binary image released by @Joao_Manoel. but I ran into some issues when building a custom image. I believe I have worked around those issues and possibly improved a bit on the setup a bit. I’m planning on opening up PR’s to @Joao_Manoel 's repo. I was able to get emulationstation up and running with getting emulators to work right, but the system would hang when I exited the emulator.
@arthur, so you just did the Emulationstation from the retropie repo? Just curious because I am attempting the full retropie setup on the GameShell. I ran into a few… issues… mostly revolving around the binary driver requirement in retropie. Might require a patch to that too, but if the mesa lima drivers work ok and I can figure out what is causing the hang, this will seemingly work great.
Ok, so I finally got RetroPie to build on the debian version from @Joao_Manoel with no issues. I started looking at the hanging and it seems like it might be either audio or video related. There are a bunch of links in the past about ES and audio issues exiting emulators, but no solid leads on a fix yet. If I can get around the hang, I can build and publish an image. I did notice there isn’t a good way in the UI yet to setup WiFi. Might need to look into that too.
Been digging some more. It seems emulationstation isn’t re-grabbing the keyboard when it comes back from launching something. I feel like I may be right on the edge of figuring this out, but missing a key point. I don’t think it’s hanging per se, I think the keyboard (or the game pad in the GameShell’s case) is not getting redirected properly back to emulationstation. This may be a problem of the mode flipping on the console. Going to keep trying a few things to see if I am on the right track.
update:
My suspicion has been confirmed. I hooked a usb controller up to the GS when it was “hanging” and was able to move around after exiting a game. So this is a problem with either emulationstation, the linux input system and/or the frame buffer code. More digging tomorrow but I am closer.
update2:
I’m beginning to suspect SDL is the issue. The version that comes with the version of debian we are using is newer than what is built by RetroPie if you let RetroPie handle SDL. The issue with letting RetroPie handle SDL is that other packages (ie. ffmpeg and such) installed by other things (ie. retroarch, and some of the emulators) depend on specific versions of SDL which are not available in the debian repos. This causes apt to break badly. I think I am going to investigate what is going on with the version of SDL in debian and see if I can get ES to do the right thing when it launches and comes back from a game. Looks like you can call SDL_QuitSubSystem() followed by an SDL_InitSubSystem() to do a re-init of the event system. I’m going to wrap the game calls in that and see if it helps/hurts.
Update 3:
Adding those calls did not help. So I went down the path of getting Retropie-Setup to compile and use it’s suggested version of SDL. After some noodling, I got that to compile and you know what… IT WORKED! No hanging. I am currently working on getting this scripted into the image build scripts from @Joao_Manoel so that running one command will build you a debian image with RetroPie for the GameShell. I hope to have something soon, we’ll see how long the test builds take. I have been building it on my GameShell but I think I may have been over exercising my SD card…
@uberlinuxguy congrats on getting retropie’s build scripts to work on clockworkpi-debian ! This is good news. When I did some retropie a few years back I wasn’t a big fan of that script, but it seems to be used by a large community so if it works here, it might gain some traction in this community (and clockwork-debian with it?). Maybe you could start a new thread explaining this approach to get some people involved. I’d be happy to test it out if you have some instructions!
On a side note: I’d love to see the “use SDL version from debian bullseye” approach still be explored as staying as close to debian might help with maintainability, but whatever works for now is good news.
As soon as I get the build system to work well, and run everything, I plan to start a new topic. RetroPie’s script is indeed giving me a bit of trouble. I am still trying to fight through it’s dependency processing and lack of dependency failure code (or at least, my lack of it’s understanding if it exists). Each build takes almost 4 hours, even when built on my desktop and not on the GameShell, so iterating over failures is… difficult.
With bullseye, the stable vs. unstable packages are also giving me trouble, as some of the unstable packages do not play well with the versions that RetroPie needs from the stable repo. I’m not convinced this is going to be a good longterm way of maintaining this, but getting to know RetroPie’s build system is helping to understand how it all works together.
I’m not really sure why the bullseye version of SDL is broken the way it is. That could be a bug that needs to be filed with Debian. I would need to do a lot more debugging to figure out what is going on there. Possibly a code tree comparision with the RetroPie SDL and the version of SDL Packaged in bullseye. Sounds fun, in a tedious “i’m hunting wabbits” Elmer Fud sort of way…
THIS is why i need to stop being lazy and figure out kubernetes. I’m gonna try and give myself a kick in the pants and spin my cluster properly. i got a bunch of pis so that i could offload all kinds of stuff and free my my main rig.
I finally have an image that will flash and work! The build system also will build the image, start to finish, with one command. I can upload a copy of the image tomorrow so others can take a look. Off the top of my head, the following are missing and are needed to make this widely usable:
Some kind of battery monitor overlay display
A better way to setup wireless
A display for wireless signal, overlay similar to battery status
A functioning mass storage gadget or a better way to get files into the file system.
I am also wondering what should be the best way to go about publishing my changes. I could open PRs to the repo, or I could open a new fork.
There are also possible changes to RetroPie that need to be made to make it work.
Right now, the software is a mix of stable and unstable. It’s not clear to me if this is also undesirable. Fixing this would also likely be patches to RetroPie for Debian Bullseye.
It sounds like many of the things you’re missing (battery, wireless, etc.) are a part of this new launcher:
I wonder if there is a reasonable way to combine (and maintain) the two?
Seems like Emulation Station is a stylish and convenient way to launch emulators, while the new shell could offer the configuration options and general purpose device management (including other application access, besides emulators).
That’s definitely a possibility. I guess the base question would be, what should the “base launcher” be? The emulator manager or the device manager? That would be a great thing to poll the community about.
Personally, I would rather have the emulator manager be base and run other stuff from there. Battery and wifi status should be an overlay that is always displayed no matter what is currently open though
@adcockm indeed the new launcher written in godot is very promising. I would argue that choice and diversity would be nice. At the beginning there was a launcher in python and another one in go and you could switch between the two to see which one fits best. A similar mechanism would be nice (making it user friendly is difficult). EmulationStation has a much larger community than the three gameshell specific launchers. The vanilla-retroarch (and it’s patched version for gameshell) are also viable options. I’ll open a thread to discuss this (trying to avoid long threads that diverge from the initial subject).
The GameShell-like launcher UI you’ll see when you first open my launcher is just a modular component that can be easily swapped!
The launcher I’m developing aims to be as much flexible and customizable as possible, should be a breeze to create a simple module to launch EmulationStation as its “main application”, still running the base launcher in the background with always-on widgets etc.
