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: https://01.org/linuxgraphics/gfx-docs/drm/drm-mode-setting.html 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
Oh, ok. I didn’t think xrandr was usable without an X server running. If it is, I don’t suppose there’s any issue. I guess we can test it out soon enough 
This Is what I have read. You should be able to link the display to xrandr in terminal using the following command.
DISPLAY=:0 xrandr
After this xrandr should be able to control and see your dislay outputs.
2 Likes
I was surprised I hadn’t checked back on this for a moment and ended up downloading the newest nightly for a totally unrelated reason and saw this was implemented. It’s working perfectly now in every scenario! Great work again @Alphanu this is awesome to finally have
3 Likes
Is this 15khz CRT support supposed to work with any video driver (gl, d3d9, d3d11, vulkan…) or is specific driver oriented? I’m asking this because I can’t get it working other than gl driver.
It uses RAs back-end video driver so should work with all. However, having said that windows does have issues with D3D and interlaced resolutions. Myself and @Retrorepair have had it working with D3D but you need to install the latest Directx run-time/SDK. However having said that GL has always given the best results.
There will be Wiki updated soon with all the relevant information for setting things up.
Ok guys this is it. I still need to tidy the code and put it in the correct places before I submit the next PR.
I have super fast Linux switching. Modlines to match and sync odd hz like Mortal Kombat. All this working without the need for VSYNC.
During my lag test I managed to get a huge result of 0.2 frames. This is shown at the end of the video.
@Twinaphex to generate and install these modlines that corretly mimic the original hardware I am having to use the system(); function. This can be changes to say execlp(); if preferred? Let me know so I can ammend anything before submision. Or if these are not allowed I’ll need to go back to the drawing board.
Hi there, let me consult some of the Linux users first on IRC/Discord.
I talked with bparker a little and the reliance on external system()/execlp() was indeed an issue. However, I looked into xrandr itself, and it’s actually a pretty straightforward utility that just hooks into the RandR protocol, so we may be able to just take the handful of functions we actually need and incorporate them directly into RA.
2 Likes
I compiled a version of Retroarch with this functionality for Raspberry Pi. I’m guessing it doesn’t work on that platform?
Where did you get the code? The one in the libretro repository only supports Windows currently, but the Linux support that Alphanu is currently working on should work on RPi.
Well, i was long away due to personal life but i finally had the time to try the latest nightly. I’m very impressed with the results. Everything seems to work perfectly except for one issue, after exiting retroarch, the resolution remains the same. I remember this being fixed in the past, i think. Is this intentional or a bug? Of course this issue causes problems with frontends like hyperspin.
@ilitirit I am currently calking with the guys over at the pi2jamma group https://www.facebook.com/groups/1649021265123737/?ref=bookmarks The RPi is a bit of a special case. It uses fbturbo as its video server which causes issues. The guys here have some resolution switching working using scripts. most arcade game have the correct resolutions but consoles do not. Aslo its all only 240p there are compiling new kernels and testing 480i resolutions but 480i its still a way off yet.
My plan was and still kinda of is be to get RA ported to the RPi properly. Once all the Linux kinks are out of the way. As I would like a RPi in my arcade machine.
@Foxhole You are correct, resolution restore is and should be working. There is a small issue here which will need to be commented on in the documentation. Resolution restore will have detected your windows current resolution. However it does not detect your current screen refresh. You can always create an issue for this on github.
So what does resolution restore do. Simple answer it will set your resolution that you had before running RA but it will only look to set 60hz in that resolution. So if you are running a 50hz desktop resolution to maximize the CRT view it won’t be able to restore it. So I would suggest you have 704x480@60 installed as you desktop resolution.
Now if you are already running a 60hz desktop resolution I am not sure why this does not work for you. In all myself and @Retrorepair 's tests this has been working perfectly since being incorporated.
@hunterk When it comes to xrandr I am aware it uses RandR and I could use X11/Xlib.h and all the other #includes needed to try and set the resolution. Now the only issue here is, that this not all that is happening to set the res. In short I would pretty much need to rewrite xrandr and incorporate it into RA. This is because I need to be able to set the video porches for horizontal and vertical which there are 3 of not including the resolution size. Also I need to set the pixel/dot clock and then resize the video frame buffer. All this is needed to be able to generate the resolutions we require. In this case exact resolutions with perfect refresh rates.
To be fair right now this Linux version is the most accurate to the native machines possible. Most of the cores do not need VSYNC all if you have the right setup. This means the CRTs resolution and hz are nigh-on an exact match to what the original hardware would have switch your CRT to. It is much better and more accurate than the windows version that must have VSYNC on.
The old saying is don’t fix what isn’t broken.
Now if I’m being honest with myself unless we can find a happy middle ground with the devs I’ll have to leave what I have and let someone else take over. I barely have the time to do what I am doing know. So I think the best I can do is hand over my source code and let whoever takes over attempt to incorporate full X11 switching from source. Trying to keep this current accuracy.
@markwkidd Can we sign off this bounty? I have completed what was tasked. Cheers
I’m using 640x480@60hz as the desktop, so that’s not the case. It used to restore the resolution just fine in the older versions. I’m currently using the latest nightly. Can any one else try the latest nightly and check if the resolution is restored?
Are you ready to submit a PR for your Linux work? Even if it needs some amendments regarding xrandr I think it would be a good thing to have that code as a PR
I see you saying at least in terms of rpi that you are planning to keep continuing to work on this which is also a good sign for donors who get asked to sign off on the collection.
I personally do feel that you have met the criteria for the bounty. I will try to check directly with twinaphex and make that argument. It would also be good if you would be willing to stick around and try to help with whatever xrandr decision is made.
But again in terms of the bounty if you will put in the Linux code as a PR then I will personally start making the case that you have completed the criteria. I can tell you have worked hard on this and for more than just the cash value
Yes, understandable. If you can push your existing Linux switching code into a branch, we can work on making it independent from external xrandr.
I am happy to support releasing the funds, as you’ve done everything that was required and more.