RetroArch - Native CRT Support


oy, what a drag. Can you pastebin a log?


I have the bios files in the main Ra folder and in ~./config/retroarch/system. I have set the retroarch.cfg to ~./config/retroarch/system for the system directory.

Here is the pastebin


What distro is recommended to use with RA? So we can download from the online updater


[ERROR] Error(s): /home/mme/.config/retroarch/cores/ cannot open shared object file: No such file or directory

That’s weird.

The newer LTS release, Xenial, should work, as well as anything newer.


That’s what I thought. I have checked and the file is in that directory. I’m going to upgrade to 16 and see how things go.


Yeah, all working fine on Ubuntu 16.


I’m getting some odd behavior when trying to load RetroArch through a frontend (Attract-mode). The game loads, but the resolution switching doesn’t seem to function. It will output to whatever resolution the desktop is set to.


I’ve not done any testing from different front ends. Does it work if you load Retroarch normally? I know with frontends you have the options to load a config file, is attract-mode loading the retroarch.cfg? this is were the settings are for the switching. Frontends load Retroarch in CLI mode so you will have to make sure the correct arguments are being added.

Once you’ve loaded a game in attract-mode can you press F1 and check in the menu if crt switching is enabled.


I’ve got it working now. It seems Attract-mode handles formatting the commands kinda strangely and was reverting to an earlier working config? I really don’t know why it was partially working to be honest, but putting quotations around the RetroArch path (it was working without them before) seems to have fixed it up nicely. I’ll chalk it up to user error.


Attract Mode is a launcher, not a frontend. Retroarch is still the frontend in this scenario


It is now merged. So if you download the latest nightly it will all be there.



There’s a wiki post here on the forum where we can make some documentation for the feature. We need some text explaining what it is and how it works (layman’s terms is good enough; doesn’t need to be very technical) and then some steps explaining how to set it up on a new blank-slate system:


Nice I’ll get @Retrorepair to help out with this as well.


I’m working on this now


OK guys, big update for Linux here. I have now included a modeline generator into RetroArch. So there will be no need to create custom resolution for Linux. Also with this modeline generator it set the exact hz needed for the core. In turn there is now no need for VSYN making in put lag non-existent.

Currently switching is a bit jarring, but I need to clean the method and move some of the method around which will help smooth this out.


@markwkidd any news from the devs?


That linux switching is looking awesome!

The Windows switching is merged and Twinaphex has been going through cleaning up the little quibbles. That was really the biggest hurdle, and the linux switching should get merged pretty quickly.


Has the linux switching been tested outside of X (DRM/KMS), or is it still dependent on xrandr?


ATM I am not sure how you can setup a custom resolutions as low as 192, 224 or 240p outside of xrandr. If any one has some knowledge in this and what’s to help out I’ll add other methods.


I think it should be just like normal DRM/KMS but you’ll use the functions from here: to create the modelines using the CVT algorithm, then add them and atomically switch to them as needed.


I am not using CVT, this is because it does not acuratly set the refresh rate. So instead I have created my own modeline generator within RA. This guarantees that the correct hz will be set, matching the core and no need for VSYNC.

If I can I would be happy to use my generated lines with drm. I have a lot going on at the moment but if some one wants to create a barebones drm fuction for switching I’ll add it in.

With drm can we add and remove resolutions on the fly, this is need as some cores are in the same resolution but a different hz. Hence the need to continuously add and remove them.

I’ve read that xrandr works with kms as long as you are on or above kernal 3.2