Possible to run an x session through runcommand?
-
So I have been experimenting using
XINIT:
for emulators that dont scale properly on the pi 4 (dosbox, streets of rage remake etc.). From my tests performance seems just as good and I am able to control video mode properly using runcommand or via in game settings! It might be worth usingXINIT:
on the pi 4 for older SDl1 based emulators or other oddball emulators. -
@quicksilver said in Possible to run an x session through runcommand?:
I have closed doom 3 but xinit is still running
yeah, doesn't ring any bells.
-
@quicksilver I planned to make this configurable. Due to time restrictions, I felt it was best to fix up sdl1 apps via dispmanx backend but later add the ability to switch to X. This is still likely to happen, but there's no ETA of course - when I get round to it. But in the meantime you can always add an emulators.cfg entry with another name and use XINIT and it won't get overwritten with updates.
-
@BuZz thanks buzz, that is what I will do. No rush of course, I just wanted to make you guys aware that it seemed to be a good option. Though it looks like you are way ahead of me :). I may recommend this to others as well if the have similar issues as I. Just a quick question. Is xinit already installed in a default retropie image?
-
@quicksilver said in Possible to run an x session through runcommand?:
Is xinit already installed in a default retropie image?
No, I don't think there's a package that installs it automatically in the base image. However, if the configuration will change, it will be added as a dependency to the packages requiring it.
For now, the simplest method to have it installed is to install the desktop. -
@mitu Gotcha. I have been playing with compiling source projects so much I cant remember what I may have installed as a dependency along the way. I havent installed the desktop environment, so I must have installed it at some point over the last few weeks.
-
Yeah it's not. That was another reason why I went the dispmanx route. As it would have required adding X dependencies everywhere and additional logic. When I get around to making it configurable, my plan is to also handle the dependencies aspect. But I also wanted to do more work on this first.
On a code level this would be in a similar fashion to the recently added dependency aliases. This exists already for kernel headers. But it will be expanded. Just simplifies module coding as for example kernel header naming differs between Debian/Ubuntu. A module can now just ask for LINUX-HEADERS and the core code will install the right packages. I wanted this for the X dependencies also - but transparent to the module. The module would specify some flags which would advertise which backends it works on. And the rest would be done automatically.
Rushed explanation, but this is why it's not done yet as it requires some reworking of existing code.
-
I added Doom 3 to my ports section and ran into the same issue. It seems when dhewm3 exits the process goes defunct put persists so it keeps the X session running. I modified the startup script prior to executing runcommand to run a process that watches for "[dhewm3] <defunct>" to appear and then calls killall xinit to shut it down.
-
@russellb Would you be so kind to share it? Your approach is probably the most convenient way. TIA!
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.