CrtSwitchres not working 1.9.1

[Redemp]

Description

[Description of the bug] CrtSwitchres not working

Expected behavior

CrtSwitchres should switch resolution

[What you expected to happen]

CrtSwitchres should switch resolution

Actual behavior

[What is actually happening] CrtSwitchres not working in anything except native resolution

Bisect Results

• RetroArch: [version/commit] 1.9.1

  Environment information

  Linux

[inactive123]

hi there @alphanu1 , could you possibly take a look to see if there is an actual problem going on and a regression happened somewhere?

[alphanu1]

@twinaphex I have just span up my Linux testing environment. I can confirm that CRTSwitchRes is working on the latest build. All options are functioning as they should, allowing all types of super resolutions (Native, Dynamic, 1920, 2560 and 3840).

Environment

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.1 LTS"
NAME="Ubuntu"
VERSION="20.04.1 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.1 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

List of resolutions tested with CRTSwitchRes

 CRT1 (0x4ef)  6.139MHz -HSync -VSync
        h: width   320 start  330 end  357 total  392 skew    0 clock  15.66KHz
        v: height  240 start  242 end  245 total  261           clock  60.00Hz
  CRT2 (0x4f1) 31.116MHz -HSync -VSync
        h: width  1600 start 1666 end 1787 total 1987 skew    0 clock  15.66KHz
        v: height  240 start  242 end  245 total  261           clock  60.00Hz
  CRT3 (0x4f2) 37.349MHz -HSync -VSync
        h: width  1920 start 2000 end 2144 total 2385 skew    0 clock  15.66KHz
        v: height  240 start  242 end  245 total  261           clock  60.00Hz
  CRT4 (0x4f5) 49.799MHz -HSync -VSync
        h: width  2560 start 2666 end 2859 total 3180 skew    0 clock  15.66KHz
        v: height  240 start  242 end  245 total  261           clock  60.00Hz
  CRT5 (0x4f6) 74.698MHz -HSync -VSync
        h: width  3840 start 4000 end 4289 total 4770 skew    0 clock  15.66KHz
        v: height  240 start  242 end  245 total  261           clock  60.00Hz

I have seen some comments on the forum about this too. More investigation is needed to confirm why some users are having issues.

@Redemp Please can you give me some more information.

What Linux distribution are you using? Was it working on this same install before? What graphics card are you using, did it work before? Have you deleted your retroarch.cfg so a new one can be generated after upgrading, including core overrides?

[Redemp]

Reinstalled everything and now it works. I think i was using outdated cores but i have no idea. So strange... :man_facepalming:

Wrote on the forum so hopefully someone else reports back so this could be an issue with old installation files aka user error. Sorry to cry wolf for nothing.

[alexb3d]

Currently it does not work for me in any way, sometimes close the program other times the screen goes black and the only way is to force restart. I have deleted the configuration folder and installed the kernels again, the error continues.

Testing with the PPA (stable) and with Flatpak. I use Ubuntu 20.04.2, Core i7 3770 and the integrated HD Graphics 4000

It was working perfect for me with a Monitor, just by activating 31Hz it created all the resolutions I needed, 240p 480i, etc ...

This I wrote 20 days ago in the forum.

[alphanu1]

Discussions ongoing on forum. https://forums.libretro.com/t/new-crtswitchres-update/30087/46

@alexb3d It looks like the resolution has been created and added to an out put. so it seems something is happening just after that process has happened. You would not see CRT1 if it crashed while creating the resolution.

Can you run RA in verbose mode please. Output to a log file and attach it here.

retroarch --menu --verbose >> retroarch.log 2>&1

[Kopert]

I am having the same problem on a Linux (Manjaro) machine where I have been running RetroArch with switchres for the past year with no problems. I just got 1.9.1 today.

Can you run RA in verbose mode please. Output to a log file and attach it here. retroarch --menu --verbose >> retroarch.log 2>&1

Sure, retroarch.log

Relevant part seems to be:

X Error of failed request: BadAccess (attempt to access private resource denied) Major opcode of failed request: 140 (RANDR) Minor opcode of failed request: 19 (RRDeleteOutputMode) Serial number of failed request: 112 Current serial number in output stream: 114

[alphanu1]

@Kopert I have not tested Manjaro yet. But if it worked in the past it should be fine now.

I am in the process of download a Manjaro ISO. However, source forge is running unbelievably slow. 10+ hours ATM.

@alexb3d are you using Ubuntu?

[Kopert]

@Kopert I have not tested Manjaro yet. But if it worked in the past it should be fine now.

I am in the process of download a Manjaro ISO. However, source forge is running unbelievably slow. 10+ hours ATM.

Thank you for taking the time to look into this. If it is of any relevance, I'm using kernel 5.4 (LTS) on Manjaro because the newer kernels (5.10 onward) do not support VGA outputs on AMD cards. It's the same kernel I've used for the past year.

Manjaro has always been good to me for running Retroarch. I had more luck with it than with other distros.

Let me know if there is any way I can help you investigate this.

[Kopert]

Additional info: just to isolate 1.9.1 as the problem, I located the 1.9.0 package (found it in my local pacman cache as retroarch-1.9.0-2-x86_64.pkg.tar.zst), extracted the old retroarch binary and executed it directly, and everything is working as it used to. Re-running 1.9.1 still crashes on startup as before.

[Redemp]

@Kopert I have not tested Manjaro yet. But if it worked in the past it should be fine now. I am in the process of download a Manjaro ISO. However, source forge is running unbelievably slow. 10+ hours ATM.

Thank you for taking the time to look into this. If it is of any relevance, I'm using kernel 5.4 (LTS) on Manjaro because the newer kernels (5.10 onward) do not support VGA outputs on AMD cards. It's the same kernel I've used for the past year.

Manjaro has always been good to me for running Retroarch. I had more luck with it than with other distros.

Let me know if there is any way I can help you investigate this.

You have to compile your own. Look here https://github.com/D0023R/linux_kernel_15khz

[alphanu1]

I will be compiling fresh once I have the Manjaro Environment setup. Please see tests below. I will update this post as I go along.

Tests:

• Ubuntu 20.04 RA 1.9.1 running CRTSwichRes Video Here
• Manjaro 20.2.1 RA 1.9.1 running CRTSwitchRes Video Here

[Kopert]

You have to compile your own. Look here https://github.com/D0023R/linux_kernel_15khz

Oh no, it works on pre-5.10 kernels. The problem is that they added DC support for my GPU on 5.10 but it still does not support VGA outputs as you can see here and here.

I'm staying on 5.4 LTS and it works fine. I'll consider upgrading if/when they manage to get VGA output working.

[alphanu1]

@Kopert are you using a patch kernel then?

[Kopert]

@Kopert are you using a patch kernel then?

No, never used a patch kernel, I'm using everything vanilla on a 5.4 kernel. 1.9.0 still works.

[Redemp]

You have to compile your own. Look here https://github.com/D0023R/linux_kernel_15khz

Oh no, it works on pre-5.10 kernels. The problem is that they added DC support for my GPU on 5.10 but it still does not support VGA outputs as you can see here and here.

I'm staying on 5.4 LTS and it works fine. I'll consider upgrading if/when they manage to get VGA output working.

Just disable DC in kernel command during boot. What type of card do you have? DVI-I port? The go DVI-I to VGA.

[Kopert]

Just disable DC in kernel command during boot

Edit: I tried 5.10 with DC disabled. It works now, but RetroArch behaves the same - 1.9.0 works, 1.9.1 doesn't. Kernel version does not seem to affect the issue at hand.

What type of card do you have? DVI-I port? The go DVI-I to VGA.

The DVI port on my GPU does not have the analog pins, so going DVI->VGA is not possible.

[Kopert]

So I decided to try running kernel 5.10 with DC disabled, and there is no difference in behavior. 1.9.0 works, 1.9.1 doesn't.

I have noticed something that occurred the first time but I hadn't realized before. The first time RetroArch 1.9.1 is run, it freezes during startup with garbage on the screen after setting a super resolution (I use 2560). I can't close it unless I do a kill -9. The error messages from the first log I sent are from trying to run RetroArch again after this first failure.

In case this is relevant, I restarted my computer on kernel 5.4 and ran RetroArch to grab a log from the first time it runs (when it freezes on a garbled screen), here it is. I have to kill -9 it to get it to close.

[Kopert]

I tried switching to "gl" for the video driver (instead of vulkan) and I got image only on a vertical strip on the left side; the rest is a garbled mess. Trying to start a game causes a crash with the error message from my first log. Trying to run 1.9.0 after this still works fine.

[alphanu1]

Manjaro 20.2.1 RA 1.9.1 running CRTSwitchRes Video Here

@Kopert Fresh OS install and fresh RA compile. All working fine

[Kopert]

@alphanu1 I understand, but I'm still getting the problem here. I assume you saw my previous messages with the new log for the first-run freeze.

I tried downloading a brand new AppImage version of RetroArch 1.9.1 with its own fresh settings. Changed the menu driver to rgui, enabled advanced settings and restarted RetroArch. But as soon as I enable switchres all I get is a vertical strip of working video on the left and shimmering garbage on the rest of the screen. If I try to start a game, it crashes; if I switch to Vulkan, it crashes as soon as I turn switchres on.

For now I think we can rule out kernel version (I tried 5.4 and 5.10) and distro (since you can run it on Manjaro). We can also rule out other RetroArch settings/data since I got a fresh AppImage version with fresh settings.

Right now I'm not sure what else I can try to workaround the problem other than just stick to 1.9.0. If you have any other ideas of stuff for me to try I'd appreciate it.

[alphanu1]

@Kopert can you try and compile RA instead of using the APP image?

I am compiling the latest testing build so maybe that has something to do with it

[Kopert]

@alphanu1 I don't think I can do it but I'll try.

[alphanu1]

@kopert Open up a terminal window and follow these commands.

sudo pacman -S base-devel
git clone https://github.com/libretro/RetroArch
cd RetroArch
./configure
make -j2
./retroarch 

While testing every time you want to load RetoArch run ./retroarch within the compiled folder.

[Kopert]

@alphanu1 I followed your instructions. Unfortunately, the behavior is the same - it crashes if I try to use Vulkan, and using OpenGL it only shows the left part of the image, with the rest of the TV flashing some garbled mess (trying to start a game causes a crash).

On the attached screenshot you can see that RetroArch is being cut-off. The TV is to the right of the HDMI monitor.

Edit: I tried moving the TV to the left of the monitor; vulkan still crashes (and starting a game still crashes) but RetroArch is shown fully on the TV - however, part of it is being replicated on the main monitor as well.

Is there a chance that the new switchres code is trying to manage the resolution on my main monitor alongside my TV, and is failing in doing so? Or trying to use both as a single screen? Just spitballing here.

This is how it looks when the TV is changed to be on the left side of the main monitor:

Edit 2: the behavior on this second screenshot also happens on 1.9.0 (if set to the left of the main screen, retroarch extends into it) but it does not prevent anything else from working properly.

Edit 3: disabling the monitor and leaving only the TV connected does not fix the issue. Disabling the main monitor completely, restarting the computer and going into RetroArch in OpenGL works (no cut-off), but crashes as soon as I try to start a game.

[Kopert]

@alphanu1 I'm not sure if this is useful, but I was trying to pinpoint the location of the issue.

If I take the git repository on the most recent version and I do

git checkout daf6843 -- gfx/display_servers/dispserv_x11.c && make && ./retroarch

It works. If I do

git checkout 877408a -- gfx/display_servers/dispserv_x11.c && make && ./retroarch

It crashes on startup. If I do

git checkout b33f0b9 -- gfx/display_servers/dispserv_x11.c && make && ./retroarch

It does not crash on startup, but it does the "vertical-strip-with-garbled-mess" and crashes when starting a game.

Also, with the most recent version of the code, if I delete these lines from gfx/display_servers/dispserv_x11.c, it doesn't crash anymore under any circunstances, but the "vertical-strip-with-garbled-mess" problem continues:

631. XRRDeleteOutputMode(dpy, res->outputs[j], swoldmode->id);
632. XRRDestroyMode(dpy, swoldmode->id);

Edit: Even though the version from commit daf6843 works with no problems, resolution changes take longer and generate more flicker when using Vulkan. Resolution changes with OpenGL are almost instant and the display seems to flicker only once. Of course, since I'm using an older version of dispserv_x11.c with 1.9.1, I don't know if this is relevant.

My current guess is that it is a problem (at least the part about the image being cut-off) related to multiple displays, since alphanu1's videos seem to be running on a single display.

Edit 2: If I remove the lines specified above (so modes don't get deleted), it no longer crashes; if, then, I unplug my main monitor (at HDMI-A-0), leaving only my VGA-0 output connected, then it no longer cuts off horizontally. Resolution changes don't work properly (probably because of the removal of those two lines) and Vulkan still freezes, but this seems to confirm to be some relation to there being multiple displays connected.

Edit 3: Even though it seems to negatively affect multi-display setups, I no longer think they might be the cause. I tried switching the driver to "gl", setting the monitor index to "0", unplugging the HDMI-A-0 device (leaving only the VGA-0 connected) and restarting the computer. RetroArch starts correctly but crashes when starting a game; if I remove the two lines of code it does not crash but resolution changes no longer happen.

[jonnyapps]

@alphanu1 I followed your instructions. Unfortunately, the behavior is the same - it crashes if I try to use Vulkan, and using OpenGL it only shows the left part of the image, with the rest of the TV flashing some garbled mess (trying to start a game causes a crash).

On the attached screenshot you can see that RetroArch is being cut-off. The TV is to the right of the HDMI monitor.

Edit: I tried moving the TV to the left of the monitor; vulkan still crashes (and starting a game still crashes) but RetroArch is shown fully on the TV - however, part of it is being replicated on the main monitor as well.

Is there a chance that the new switchres code is trying to manage the resolution on my main monitor alongside my TV, and is failing in doing so? Or trying to use both as a single screen? Just spitballing here.

This is how it looks when the TV is changed to be on the left side of the main monitor:

Edit 2: the behavior on this second screenshot also happens on 1.9.0 (if set to the left of the main screen, retroarch extends into it) but it does not prevent anything else from working properly.

Edit 3: disabling the monitor and leaving only the TV connected does not fix the issue. Disabling the main monitor completely, restarting the computer and going into RetroArch in OpenGL works (no cut-off), but crashes as soon as I try to start a game.

I'm having the exact same issue as described here. The only difference is I have no idea what I'm doing when it comes to Linux, whereas @kopert does! I do know at least that I'm on Ubuntu 20.10

[Kopert]

I was looking at dispserv_x11.c and I found some references to "HDMI-0", "DVI-0" and such. On my system, however, xrandr identifies my ouputs as "HDMI-A-0", "DVI-D-0" and "VGA-0", in this order, with DVI-D-0 disconnected. I have not changed this in any way nor do I know how to go about changing it. But maybe this difference in naming has something to do with the issue?

It seems I figured out that the crash occurs because the code between lines 616/638 of dispserv_x11.c tries to delete the mode from HDMI-A-0 first. If, instead of letting the code iterate over res->noutput I just set j to 2 (pointing it to my VGA-0 output) it deletes the mode correctly without crashing.

I haven't yet figured out, however, why the resolution is cut-off horizontally. My current guess is that with my HDMI-A-0 at 1920x1080 and my VGA-0 at 2560x240, the total desktop resolution should be 4480x1920; instead it is as 2560x1080, which allows HDMI-A-0 to be fully shown but RetroArch, despite being corretly at 2560x240, and despite my TV being at 2560x240, ends up limited to 640 horizontal pixels (out of 2560) because the desktop is not extending fully to cover the horizontal space on the VGA-0 output (visually it makes sense, the vertical strip takes about 25% of the TV). I have to find where this is calculated and add 1920 to it; the full fix would be iterating through all displays and adding the horizontal resolutions. It is just a guess, though; I'll poke some more around the code to see if I can figure something out.

[alphanu1]

@Kopert That code has not change between 1.9.0 and 1.9.1. As a side not to this. No resolution are deleted until you exit RetroArch. this is done as a clean up process. Also these resolution are only temporarily added to the outputs and do not remain after a system restart.

@twinaphex There are no code changes for CRTSwitchRes between 1.9.0 and 1.9.1. So, this potentially could be a video driver change causing the crash on enabling CRTSwitchRes!?

I have never tested Vulkan and have only ever used OpenGL or DirectX video drivers. So, I would announce that Vulkan is not supported even if it does work in some setups.

I am unable to replicate any of these issues mentioned above on Ubuntu 18 or 20, Lubuntu 18 or 19, Arch or Manjaro. From fresh installs to existing installs. Cloning the latest git into a new folder, compiling and running CRTSwichRes always works.

Note (ToDo List): There is no regression. However, these will be nice to haves.

Desktop restore resolution only restore to a 15kz mode. This will leave a black screen on 31khz mode.

On cleanup resolutions. Check mode exists on output before trying to remove it. (This is only a problem in a multi monitor setup. 
CRTSwitchRes was never designed to fully function in a multi monitor environment.)

[Kopert]

@alphanu1 the mode deletion code does run while RetroArch is running, on resolution changes, that's when it crashes. Deleting those two lines prevents the crashes, changing the code to not iterate the outputs and delete the resolutions directly from my VGA-0 also prevents them. But it does run during normal usage, before exiting RetroArch, otherwise it wouldn't crash during execution or when starting a game.

Regarding the cut-off, I've found that setting the VGA-0 resolution to 2560x480 using xrandr before starting RetroArch solves it. I think that there is a difference between what the xrandr command does (as the old switchres functioned) and the library method the new switches uses.

Also, the new switchres code is causing a lot more flicker than before when switching resolutions. Vulkan is indeed unusable on 1.9.1, but I can understand if you consider it unsupported.

Finally, I have no intention on disagreeing with a contributor that develops code that I've used so much over the past year, and I do not want to sound confrontational. However, I think there are regressions. Reverting the dispserv_x11.c to the previous version allows me to use 1.9.1 the same way I used 1.9.0, with no crashes, no horizontal cut-offs, less flicker, Vulkan support and no problems with multi-monitor setups. I completely understand if you prefer to move forward with this new code, but, for people currently having problems, the old one behaves a lot better.

Of course, since you can't replicate it and it doesn't seem to be a widespread problem then I'll have to settle with compiling the older switchres code in and hoping it doesn't break compatibility in the future.

Thanks for your time and sorry if I couldn't be of more help.

[Kopert]

Specifically regarding the horizontal cut-off, I figured that the reported "Screen 0" size by xrandr is set to 2560x480 if I set to a mode of my own that is 2560 wide; the mode set by RetroArch is 700x480, which causes the cut-off. This is with only the VGA-0 output connected, it isn't a multi-monitor issue. The resolution on the TV is correct and the window size of RetroArch is correct, it's just the screen size that is wrong.

If I start RetroArch after setting my mode that is 2560 wide, it works fine, even when restarting RetroArch. My mode, "gc", is created with:

xrandr --newmode gc 50.797 2560 2666 2859 3180 480 490 496 533 -hsync -vsync interlace

[alphanu1]

@Kopert Sorry you are correct. The clean does happen when RA is running (kind of) RA frontend has to exit to load the core, cleanup will happen at the point.

I have had dispserv_x11.c from 1.9.0 and 1.9.1. There is no change in the create or delete resolutions code. The file has not been changed for 7 months.

Code does need to be changed/implemented to fully support multimonitor. especially with the deletion of modes.

I am not sure what you mean about the horizontal issue? Have you ensured you have enabled core provided aspect ratio?

[Kopert]

I have had dispserv_x11.c from 1.9.0 and 1.9.1. There is no change in the create or delete resolutions code. The file has not been changed for 7 months.

The switchres code in that file has changed between 1.9.0 and 1.9.1, no? While the file has not been changed since September 2020, 1.9.0 - the version that we're comparing to, where eveything worked - is from August 2020. The file has definitely changed between 1.9.0 and 1.9.1. The code to create and delete resolutions has, to my understanding, changed in 1.9.1, as has all the switchres code in that file.

I am not sure what you mean about the horizontal issue? Have you ensured you have enabled core provided aspect ratio?

This is a problem that happens as soon as you start RetroArch, with no cores involved, but yes, that option is enabled, but unrelated. I'll try to explain it as I understand it right now:

When I start RetroArch, the display resolution (the TV connected at VGA-0) is set correctly to a width of 2560 pixels. The application window width is also correctly set to 2560. However, the X Screen 0 uses a smaller width, so it cuts off the screen. I can only see the left portion of the RetroArch window. If I set a custom xrandr resolution, on a console, that is 2560 pixels wide before starting RetroArch, then the X Screen 0 has the correct width and it works fine. All this, mind you, having only VGA-0 connected as to avoid multi monitor issues.

[alphanu1]

@Kopert can you pull the mention pull request and test your end please.

[Kopert]

@alphanu1 thank you for the work.

The crashing problem is fixed, but the incorrect screen size is still an issue, even on a single-monitor setup. The current test results are:

1. Using a multi-monitor setup, crashes are gone. RetroArch no longer crashes on OpenGL. Vulkan is no longer crashing but the screen freezes; I understand that Vulkan is not officially supported and this is not a problem, but if I do the fix described on the problem below, then Vulkan works.
2. I started RetroArch and the image on the TV is messed up: I can see the RetroArch menu on the left side of the screen, sometimes stretched vertically, while about 70% of the screen to the right is just garbled garbage, usually flickering. Loading a game and going through resolution changes flickers the screen as normal, but the issue remains.

Regarding this problem, I tried a few different things to diagnose the issue:

• I can fix it by closing RetroArch after this occurs, using xrandr to set a 2560-pixels-wide resolution, then restarting RetroArch.
• For some reason, however, doing this on startup before running RetroArch causes another problem - RetroArch is only shown on the bottom half of the screen. The fix only seems to work if you set the 2560 resolution after starting RetroArch once and closing it.
• This problem also occurs with a single monitor connected.
• If, after applying the fix successfully I close RetroArch, use xrandr to set the "d_mo" mode (it looks ok) and I start up RetroArch again, the problem returns.

The screenshots below seem show the problem: the first was taken as soon as RetroArch started; the second was taken after a game was loaded. Notice how the screen area ends before the entire RetroArch window is shown.

Edit: difference in the log I managed to find:

When RA fails (on the first RA run after restarting or after setting d_mo mode on xrandr), it shows:

[INFO] [XINERAMA]: Xinerama version: 1.1.
[INFO] [XINERAMA]: Xinerama screens: 2.
[INFO] [GLX]: Using Xinerama on screen #1.
[INFO] [GLX]: X = 1920, Y = 0, W = 700, H = 480.
[INFO] [GLX]: Requesting compositor bypass.
[INFO] [GLX]: Using windowed fullscreen.
[INFO] [GLX]: Found swap function: glXSwapIntervalEXT.
[INFO] [GLX]: glXSwapInterval(0)
[INFO] [GL]: Vendor: AMD, Renderer: AMD Radeon (TM) R9 M375X (VERDE, DRM 3.35.0, 5.4.108-1-MANJARO, LLVM 11.1.0).
[INFO] [GL]: Version: 4.6 (Compatibility Profile) Mesa 21.0.1.
[INFO] [GL]: Using ARB_sync to reduce latency.
[INFO] [GL]: Using resolution 700x480

Width is shown as 700, despite having a superresolution of 2560 set on switchres.

When RA works (after RA failing once, setting a 2560 width mode on xrandr and re-running RA), the same log area shows:

[INFO] [XINERAMA]: Xinerama version: 1.1.
[INFO] [XINERAMA]: Xinerama screens: 2.
[INFO] [GLX]: Using Xinerama on screen #1.
[INFO] [GLX]: X = 1920, Y = 0, W = 2560, H = 480.
[INFO] [GLX]: Requesting compositor bypass.
[INFO] [GLX]: Using windowed fullscreen.
[INFO] [GLX]: Found swap function: glXSwapIntervalEXT.
[INFO] [GLX]: glXSwapInterval(0)
[INFO] [GL]: Vendor: AMD, Renderer: AMD Radeon (TM) R9 M375X (VERDE, DRM 3.35.0, 5.4.108-1-MANJARO, LLVM 11.1.0).
[INFO] [GL]: Version: 4.6 (Compatibility Profile) Mesa 21.0.1.
[INFO] [GL]: Using ARB_sync to reduce latency.
[INFO] [GL]: Using resolution 2560x480

Width is shown as 2560, as expected, and it works.

Weirdly enough, this same difference is also shown in the logs with 1.9.0, but I don't get the issue on that version.

If I try to start RA with "NATIVE" resolution instead of "2560" the entire application is shown as a thin vertical strip in the center of the screen. I think this is caused by the fact that the CRT1-CRT4 resolutions are not being deleted (they still show on xrandr after exiting RA) and I think it's trying to reuse them.

[alphanu1]

@Kopert This last issue should now be fixed. Just waiting for the PR to be merged.

In the mean time you can test from my reop. https://github.com/alphanu1/MME4CRT

[Kopert]

@alphanu1 thanks again for the effort. I'll do more tests, but I initially ran into some problems.

If I run RA from your repo and I have only a single monitor connected, using OpenGL, RetroArch crashes after I get this when trying to start up:

X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  140 (RANDR)
  Minor opcode of failed request:  7 (RRSetScreenSize)
  Serial number of failed request:  21
  Current serial number in output stream:  22

If I try it with two monitors connected (my usual setup), RetroArch crashes after I get this:

X Error of failed request:  BadRRCrtc (invalid Crtc parameter)
  Major opcode of failed request:  140 (RANDR)
  Minor opcode of failed request:  20 (RRGetCrtcInfo)
  Crtc id in failed request: 0x0
  Serial number of failed request:  18
  Current serial number in output stream:  18

Edit: if I change "video_monitor_index" from "2" to "0" and keep to a single monitor, RetroArch starts, but it starts in 480i and does not switch out of it for 240p content. After quitting RetroArch I can see "CRT1" (progressive) and "d_mo" (interlaced) modes still showing on xrandr.

[alphanu1]

@Kopert Going down a different route. This is a full implementation of Clamity's Switchers. Using the new Switchres 2 library by him and the group. I had a little help in it 😃

You need to compile and install the Switchres library. Then try MME_SR2

Off the bat you will notice better resolutions, faster switching and better compatibility. You can edit the switches.ini to setup monitor profiles too.

Let me know how you get on?

[Kopert]

@alphanu1 First of all, thank you so much for still spending your time working on this. It is a very important feature to me. I was just yesterday trying to fiddle with your code but my C is very rusty these days. I think that your approach to using this external library seems to be a great idea to remove most of the boilerplate system-dependent stuff from your plate. It would probably end up being more compatible overwall, I'd wager.

Just running RetroArch on default with your new code causes a completely new behavior: the main display (the LCD screen that I use) gets turned off and only the CRT is on (this behavior is perfectly fine, it's just new). The image on the CRT, however, is wrong: it extends to the left, so I only get the right side of the image, stretched horizontally. Trying to run a game like this left it as a small square on the top left of the screen, still stretched, with most of it extending outside of the CRT, as if my main screen was still on.

If I unplug the LCD screen before running RetroArch, then it mostly works! Results are as follows:

Good results:

• SNES games look normal;
• PlayStation games look normal, including switches between progressive and interlaced;
• Vulkan is working the same as OpenGL;
• Exiting RetroArch restores a normal, usable resolution on the CRT.

Bad results:

• Game Boy games are no longer a small, pixel-perfect square image in the center and, instead, extend to the entire screen;
• Neo Geo Pocket games send the CRT into an unsupported resolution (reported modeline was 7680x456_60i while my superresolution is set to 2560) when they used to run in progressive scan before;
• Game Boy Advance games are presented in 2560x480i instead of the nice 240p they ran at before, being squished vertically; if I set my resolution to "NATIVE" instead of 2560, then it fills the entire screen instead of being pixel perfect (and is still interlaced instead of progressive);
• The main RetroArch menu is now interlaced instead of progressive, which, in my personal opinion, is a downgrade, but I can live with it if there's no way around it.

Having to unplug the LCD before using it is a downside to me - because it is cumbersome and because the Linux interface moves to the CRT TV, causing it to flash on screen between resolution switches - but it is still a much better result than before.

I then tried messing with the switchres.ini file as you suggested. Changing "display" to "VGA-0" made both screens work normally and RetroArch to only be presented on the CRT screen, which is perfect! The remaining issues are the ones I mentioned before - such as specific systems' resolutions and RA's main menu.

With all of this said, I'd suggest the following, if I may:

• Fix the resolution issues with the non-standard systems such as GB, GBA and Neo Geo Pocket;
• Make the RetroArch main menu operate at 240p instead of 480i (or give us a choice);
• Allow the user to have the switchres.ini file at the ~/.config/retroarch directory along with all the other RetroArch config files.

Since I can make my non-supported multi-screen setup work just as before just by setting the correct display on the switchres.ini file, and it works fine if you only have one screen connected, I think these changes would be enough to meet everyone's needs.

Please do let me know if you'd like me to do any more testing or to try anything else on my end. Thanks for your time!

[alphanu1]

@Kopert Thanks.

So, we will be adding monitor index support to switchers 2.0. This means you wont have to set these setting in the switchres.ini.

I have removed the low res hand held work around for now. While we are in the early stages of testing at least anyway. I will work them back in once everything else is working as it should.

There is a lot of conversation about the menu resolution. Some what 240p others want 480i and then also people want 480p. So, I have decided to removed it. The menu will start in whatever you desktop resolution is. This also fixed issues for dual and tri sync monitors.

I have pushed a few changes since you last tested. Please have another go and let me know.

Thanks for doing some of this testing.

Hopefully, the Libretro team will except this when it is time to raise a PR as this now requires an external library. However, this is a much better implementation. More stable and is not limited to just X. The windows / Linux implementation is no longer different. Dynamic modes are now available for windows and so is monitor selection instead of being stuck with primary monitor only.

@twinaphex @hunterk Please could you let me know your thoughts. New Implimentation

[hizzlekizzle]

It's fine by me. Since it's GPLv2+, we could potentially link it in as a vendor-ed dependency, just as we do for, say, lzma.

[Kopert]

@alphanu1

So, we will be adding monitor index support to switchers 2.0. This means you wont have to set these setting in the switchres.ini.

Sounds great. I look forward to testing it.

I have removed the low res hand held work around for now. While we are in the early stages of testing at least anyway. I will work them back in once everything else is working as it should.

I figured this might've been the case. I'll test that extensively once it's implemented.

There is a lot of conversation about the menu resolution. Some what 240p others want 480i and then also people want 480p. So, I have decided to removed it. The menu will start in whatever you desktop resolution is. This also fixed issues for dual and tri sync monitors.

I have pushed a few changes since you last tested. Please have another go and let me know.

So, I was testing this before since I saw you had made a few commits today. Some test results:

• If I have my TV set to 720x480i and I start RetroArch, the main menu only takes half of the screen, both horizontally and vertically, so it is small, centered and not stretched (the on-screen notifications are shown on the correct position, outside of this small interface section, stangely enough);
• If I have my TV set to 320x240p and I start RetroArch, the main menu works as it used to in this resolution;
• If I start a SNES game and return to the main menu, it looks great at 2560x239p; it is strange, but if I set my CRT to 2560x240p before starting RetroArch, the interface is squished horizontally; on-screen notifications are, again, shown "outside" of the squished interface, in the correct location; for some reason, the interface works if coming out of SNES at 2560x239p, but not if I set it manually before starting RetroArch;
• If I start a PlayStation game and quit it while it is at 480i, the resolution stays at 2560x480i and the menu is squished horizontally, the same way as if I started RetroArch while using a superresolution.

I think you need to set a resolution when quitting content because otherwise you're going to keep using the last content's resolution, which might cause issues. If you want to use the original desktop resolution then you'd need to store that at startup so you can set it back whenever running content is closed. This might not be strictly necessary, but I think it would look better if the RetroArch's main menu resolution was consistent even after quitting content.

I understand if you'd rather not mess with the main menu resolution directly and just use whatever is being used by the desktop, as it gives control to the user and makes things easier for your code. I'd be happy with just using 2560x240p as my desktop resolution and have RetroArch use that, but the main menu would have to fill the screen correctly, and RetroArch would need to set this resolution back after closing content, I think.

If these two changes could be made then I'd just use 2560x240p on my desktop and have RetroArch always use it when not running content.

[alphanu1]

@Kopert I have added back in the Handheld check.

Please let me know if this works as well as it used to?

[Kopert]

@alphanu1 test results (at 2560 superresolution):

• Game Boy games seem to look fine. Resolution is at 2560x200#59.73 when it used to be at 2560x144@59.73 on 1.9.0, but they look the same as before.
• Game Boy Advance games are running at the same resolution as before, 2560x200#59.73. They look different, but in a good way: they are smaller horizontally to account for the system's aspect ratio. I used to have a per-system shader adjustment to correct the aspect ratio of some handhelds because most of them were stretched horizontally. So it works better now!
• Game Gear games, like Game Boy games, are at a different resolution (2560x200@59.92 instead of 2560x144_59.92) but otherwise look exactly the same as on 1.9.0. They do not have the same aspect ratio correction present on GBA, so I'm still using my shader to adjust the horizontal size, but this is the same behavior as on 1.9.0.
• Neo Geo Pocket is at the exact same resolution as before - 2560x200@60.25 - and has the aspect ratio correction that I found on the GBA games.
• Atari Lynx games did not work before because they used to be at 2560x240@75, which sends my CRT into an unsupported resolution. They're different now - resolution is set at 2560x200@65 - but that refresh rate is still to high for my TV so its unusable. I don't know if you intend to do something on this front or not (it didn't work before anyway) but just letting you know, since you seem to have limited the refresh rate somewhat, since it's lower than before. If you could lower it further to 60hz it'd probably work here as well.
• Wonderswan is a similar deal to Lynx - originally it would send my TV into 75hz which is unsupported, now it sends it to 65hz, which also doesn't work for me.

Overall, looks like great results so far; I'm really pleased with how the whole things is coming together. I don't know if the aspect ratio fix on GBA and Neo Geo Pocket was intentional or not but, if it was, you could consider applying it to Game Gear and Game Boy games as well. But this would be just a nice-to-have.

Other than that, I still have to set VGA-0 on the .ini file and the main menu interface still does not fill the screen, but I assume you didn't work on those yet.

[alphanu1]

Other than that, I still have to set VGA-0 on the .ini file and the main menu interface still does not fill the screen, but I assume you didn't work on those yet.

Not yet.

• Atari Lynx games did not work before because they used to be at 2560x240@75, which sends my CRT into an unsupported resolution. They're different now - resolution is set at 2560x200@65 - but that refresh rate is still to high for my TV so its unusable. I don't know if you intend to do something on this front or not (it didn't work before anyway) but just letting you know, since you seem to have limited the refresh rate somewhat, since it's lower than before. If you could lower it further to 60hz it'd probably work here as well.
• Wonderswan is a similar deal to Lynx - originally it would send my TV into 75hz which is unsupported, now it sends it to 65hz, which also doesn't work for me.

So Wonderswan and Linx have not worked in the past?

[Kopert]

So Wonderswan and Linx have not worked in the past?

They haven't, unless I turned off switchres.

[alphanu1]

@Kopert At least this is not broken functionality but can be looked into for improvement.

[Kopert]

At least this is not broken functionality but can be looked into for improvement.

Agreed.

[Kopert]

@alphanu1 sorry, I found a new problem that wasn't occurring yesterday. When running a PlayStation game, when it switches from 480i to 240p, the image becomes horizontally squished as if my superresolution wasn't taken into consideration. The problem does not happen if I use NATIVE resolution.

Edit: the same happens if I start RetroArch, open a GBA game, close it, then open it again; on the second run, it is squished horizontally, ignoring the superresolution. Works fine in NATIVE.

[Kopert]

@alphanu1 I saw that you committed v0.1 on your repository for the new SR2 functionality. I tried to test it, but nothing seems to be working; the interface does not fill when starting in 480i, superresolutions are not working, handheld resolutions are not working, if I start RetroArch while a superresolution is set, the interface is heavily squished horizontally...

It has been like this for the past week as I've been following your commits on the MME_SR2 repository, but I thought you were still working on things and that's why nothing seems to be working now, but now that you've committed 0.1 and kind of worried. I have already re-built switchres and I have ran make clean on your repository as well, but nothing seems to work anymore. Am I messing something up on my end?

[alphanu1]

@Kopert The main reason this wont be working is that Switchres has been updated to give RA some more option. This broke compatibility with the old libs. Please clone, make install the latest from Switchres

Monitor index is controlled form RA but all other options are controlled from the switchres.ini. Which can be add to either /ect/ , ./ini or the working folder (RA folder). The dot clock min controls super resolutions which are not locked dynamically integer scaled. if you want super resolutions set this to 25.0. The monitor profile controls KHz.

Switchres Monitor Presets

We are still adding more features which is why this is only Ver 0.1

Let me know how you get on with the above.

P.S still need to work on the RGUI but and starting resolution. When in RGUI it repots a resolution of 4x4@60 lol