libretro / RetroArch

Cross-platform, sophisticated frontend for the libretro API. Licensed GPLv3.
http://www.libretro.com
GNU General Public License v3.0
10.06k stars 1.81k forks source link

CrtSwitchres not working 1.9.1 #12244

Open Redemp opened 3 years ago

Redemp commented 3 years ago

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

Kopert commented 3 years ago

@alphanu1 thanks for the clarification; I was just worried about the functionality not being there anymore, since it was mostly working the first time you asked me to test it. I understand now that there's still a lot of work to integrate SR2 properly into RA.

I did a pull, make clean and make on both MME_SR2 and switchres, then a make install on switchres, copied the new switchres.ini into /etc; I left the preset as arcade_15 and changed dotclock_min to 25.0. super_width is at 2560.

Let me know whenever you'd like more tests done, or if you want me to test something more specific.

alphanu1 commented 3 years ago

hey @Kopert,

I am sure there will be more development or at least custom monitor presets coming. If you look at the monitor presets page you will see values as follows.

The last four number are the min and max values supported. min/max progressive lines and the min/max interlaced lines. At some point we will get profiles allowing as low as 144. but just not yet. I get the normal 288p resolution when I run GB

crt_range0 15625-15750, 49.50-65.00, 2.000, 4.700, 8.000, 0.064, 0.192, 1.024, 0, 0, 192, 288, 448, 576

The min dot clock set a min value for it. which mean the width will be calculated on a native width scale. Like my old dynamic version. meaning pixel perfect scaling.

If you want to force 2560 you need to edit the usermode and add the following value 2560x0 however this is not always going to be an exact integer scale.

The menu is an issue and will be worked on eventually.

Are you sure you pulled the latest? I had to git reset --hard origin/master followed by./configure and then make after I rebased and clean all my git commits.

Kopert commented 3 years ago

Hey @alphanu1, great job on everything so far. I'm starting to understand your systems better now, I believe.

The menu is an issue and will be worked on eventually.

Understood. When you look at this, could you also take a look at the resolution the screen is set to when closing content? It seems to be based on the resolution of the content that was just closed, and it'd be better if it was set to the same resolution RA started with. But this is just a nice-to-have if you have the time.

Are you sure you pulled the latest? I had to git reset --hard origin/master followed by./configure and then make after I rebased and clean all my git commits.

Yes, I did all of that. Had to do a rebase myself, but I'm sure than I'm using your latest.

Now for testing...

I had set the dotclock_min to 25.0 before, like I mentioned, and superresolutions seemed to be working fine. I understand they're not set strictly to 2560 so you can have exact integer scaling.

I created a custom crt_range0, based on arcade_15, and changed the minimum progressive lines to 144. Game Boy games work ok (the aspect ratio seems to be off). GBA games do work, but, when closing the content, RetroArch got sent to my primary monitor. I had to close and restart RA for it to go back to my TV.

Then I tried changing user_mode to 2560x0 as you suggested and RetroArch no longer gets sent to my main monitor when closing GBA content. In my particular use case, forcing the superresolutions to 2560 is better than having exact integer scaling horizontally. I can expand on my case if you'd like but I don't think it's relevant as an edge use case, but having this option to force 2560x0 on switchres.ini is awesome for me.

Setting 2560x0 also means I don't have to change the dotclock_min anymore since I'd not be using your dynamic scaling for exact integer scaling... it makes sense to me now. Still, for other users, it'd be necessary to look into the issue of RA being sent to another display when closing GBA content. No idea why that happens.

I also took this opportunity to change the max refresh rate from 65hz to 60hz and now Atari Lynx and WonderSwan games also run on my TV without sending it into an unsupported resolution.

I don't know how many of these options you intend to bring to RA's interface, if any, but right now, with proper configuring of the switchres.ini file, I can get everything (save for menu issues) working properly. Which, along with everything else, leads me to believe that moving to SR2 is indeed the best solution as you proposed, since it allows users to fix their specific issues manually if necessary.

alphanu1 commented 3 years ago

@Kopert Monitor preset options 15/31KHz now active. Added new meu option.

Monitor presets can now be chosen from the RA UI. 15KHz and 31KHz will set arcade_15 and aracde_31 respectively. New option INI, if this is chosen your monitor preset will be selected from your switchres.ini file.

Hard set super resolutions now work from the UI too. 1920,2560 and 3840.

You will need to build and reinstall switchres make && make libswitchres && sudo make install

Kopert commented 3 years ago

@alphanu1 I have tested your new code with no switchres.ini file, with a super resolution of 2560 and 15khz set on the RA options. Everything works fine except for GB/GBA and handhelds that operate above 60hz.

Then I copied a new default switchres.ini file and changed the custom monitor (based on generic_15) to 144 minimum progressive lines and maximum 60hz (my TV can do from 50hz to 60hz). Then I changed the option on RA to INI. Everything is working. Super resolutions from the UI are indeed working as well, so no manual user_mode is necessary anymore.

So, everything is working with your changes and some .ini editing, like before. Less editing than before, which is great.

I'll leave a suggestion below but please, feel free to ignore it. I don't know if it would be useful to other users. Its only purpose would be to avoid using the switchres.ini file at all.

But basically, for me, it'd be interesting if there was a new preset - called tv_15 or something - that went like this

crt_range0 15625-15750, 49.50-60.00, 2.000, 4.700, 8.000, 0.064, 0.192, 1.024, 0, 0, 144, 288, 448, 576

Same as generic_15, but with a minimum progressive lines of 144 and a maximum refresh rate of 60hz. And then have all the monitor presets exposed on the RA UI, so I could pick it directly from there.

alphanu1 commented 3 years ago

Some NTSC games (most) run at around 59hz -61hz can you try the following and let me know how you get on?

crt_range0 15625-15750, 49.50-61.00, 2.000, 4.700, 8.000, 0.064, 0.192, 1.024, 0, 0, 144, 288, 448, 576

LarsenDX commented 3 years ago

I have several BVMs and PVMs and enjoy playing on them and I do see the same behavior here. CRTSwitchRes works beautifully on 1.9.0. Broken since, on 1.9.1 and 1.9.2 . RA doesn't switch at all. Fetched the 1.9.0 binary from my bacula backups and using 1.9.0 for now. I guess nobody is using CRTSwitchRes or libretro would take way more flack for pushing new "stable" releases with the CRTSwitchRes feature completely broken like this.

Kopert commented 3 years ago

Some NTSC games (most) run at around 59hz -61hz can you try the following and let me know how you get on?

crt_range0 15625-15750, 49.50-61.00, 2.000, 4.700, 8.000, 0.064, 0.192, 1.024, 0, 0, 144, 288, 448, 576

@alphanu1 had no problem running handheld games at 61hz. In fact, I kept trying increasing the maximum refresh rate and managed to get it working up to 64hz before my TV started crapping out. I don't know about other TVs out there, so maybe pushing all the way to 64hz might be a stretch.

I'll see if I can pull out another CRT TV I have around to test some more.

alphanu1 commented 3 years ago

@Kopert fantastic. Let me know how you get on?

Kopert commented 3 years ago

@Kopert fantastic. Let me know how you get on?

@alphanu1 So I managed to plug in my backup CRT, it is an older model that looks like crap. But, much to my surprise, I was able to push it all the way up to 70hz before it gave me any problems.

I only have these two test cases with me, unfortunately... among them, the highest I can go is 64hz with my main TV.

LarsenDX commented 3 years ago

@alphanu1 Thanks for breaking this in stable. Stay in your forks with your experimental code.

Kopert commented 3 years ago

@alphanu1 I saw your commits and the menu is fixed now. It's better than before, even, because the resolution it reverts to is more "constant" than before. Great job, I can actually switch to your version as my main driver from now on.

I have a question, however, just curious. I tested some PAL Amiga content that runs at 288p 50hz but switchres sent it to 576 interlaced. Relevant line is:

Switchres: normal (720x288@49.920128)->(2560x576@49.920128)

I was just wondering, would it be possible to keep it at 288p? I assume my TV would support that, but I'm not sure. Is that something I can change in the .ini file? Like I said, just curious.

Edit: I changed interlace on the .ini file from 1 to 0 and the content runs at 288p just fine, looks really good. Of course, that breaks regular interlaced content. I guess I'm just wondering how it decides to use interlaced instead of progressive; 288 lines should stay progressive, in my opinion, if the monitor preset allows it (it does).

alphanu1 commented 3 years ago

@Kopert fry changing the mas progressive from 288 to 290

Kopert commented 3 years ago

@Kopert fry changing the mas progressive from 288 to 290

@alphanu1 that was actually the first thing I tried, thinking it might be a off-by-one issue. After your suggestion, I tried increasing the value one by one. The resolution stays on interlaced until the max progressive lines is at 298; it reverts back to progressive when the max progressive lines is set to 299.

So setting max progressive lines to 299 fixes the issue in my case.

Edit: however, setting it to that value causes a RA crash on some Master System content that runs at 256x192@60hz with the message "could not find a video mode that meets your specs" followed by "Floating point exception (core dumped)". Never seen anything like it.

alphanu1 commented 3 years ago

@Kopert That's fine. I used to set 300 as my hard set Hight before interlace trigger.

FYI, latest version the menu should be sorted.

Kopert commented 3 years ago

@alphanu1 I'm getting some RA crashes on resolution changes. Even had one going back to the menu. This is the log of when it happens:

Inside sr_switch_to_mode(2560x240@49.920128)
Switchres: Calculating best video mode for 2560x240@49.920128 orientation: normal

Switchres: [1024]x[ 768]_[60=60.003722Hz] - locked

Switchres: [ 800]x[ 600]_[60=60.315287Hz] - locked

Switchres: [ 800]x[ 600]_[56=56.249600Hz] - locked

Switchres: [ 848]x[ 480]_[60=60.000000Hz] - locked

Switchres: [ 640]x[ 480]_[59=59.939048Hz] - locked

Switchres: [2560]x[ 240]_[60=60.000000Hz]

Switchres: [ 320]x[ 240]_[60=60.000000Hz] - locked

Switchres: [2560]x[ 480]_[60=60.000000Hz]

Switchres: [ 640]x[ 480]_[60=60.000000Hz] - locked

Switchres: [2560]x[ 240]_[60=60.095785Hz]

Switchres: [ 700]x[ 480]_[59=59.939962Hz] - locked

Switchres: [2560]x[ 224]_[59=59.919540Hz]

Switchres: [2560]x[ 144]_[59=59.919540Hz]

Switchres: [2560]x[ 240]_[59=59.919540Hz]

Switchres: (   0)x(   0)_(0=0.000000Hz)
[INFO] Switchres: could not find a video mode that meets your specs
[INFO] sr_switch_to_mode: switching not required
[INFO] [CRT]: Setting Video Screen Size to: 0x0 
[INFO] [CRT]: Setting Aspect Ratio: -nan 
[INFO] [CRT]: SR scaled  X:0 Y:0 
Floating point exception (core dumped)
alphanu1 commented 3 years ago

@Kopert should be fixed now

Kopert commented 3 years ago

@alphanu1 I'm sorry, but it is still crashing for me if I keep the maximum progressive lines to 300.

I did, on both switchres and MME_SR2 repos, a full set of git pull, git reset --hard, make clean, configure, make, make install (for switchres first) to make sure it's all up to date.

I'm using a custom monitor range with the INI option with these settings:

15625-15750, 49.50-64.00, 2.000, 4.700, 8.000, 0.064, 0.192, 1.024, 0, 0, 144, 300, 448, 576

And I'm starting RA with a resolution of 2560x240 60hz, with timings provided by switchres.

RetroArch starts fine, the menu is perfect. However, it crashes when trying to start any SNES, SMS or GBA game (I haven't tested any others). It does not crash if I start some PAL Amiga game that runs at 720x288@49.92. Edit: but it does still output "could not find a video mode that meets your specs", it just doesn't crash. Resolution is actually not changed from the menu resolution.

If I switch it back to 288 max progressive lines it no longer crashes, but the PAL Amiga game reverts to interlaced. If I set "interlace" to "0" then it runs correctly at 288p. Disabling super resolution and having it on NATIVE or DYNAMIC also works.

Edit 2: issue also happens if I try to set a minimum progressive lines below 128... even when loading content that is 239p.

Kopert commented 3 years ago

@alphanu1 I built everything anew after your 0.2 rebase. Here's a list of bugs I was able to find:

I'll let you know if I find anything else.

Kopert commented 3 years ago

@alphanu1 I saw the 0.5 release. Did a full clean, rebase etc.; just to be sure, I removed the installed switchres library from my computer since it is now supposed to be baked into RA. I then proceeded to testing. Here are the testing steps I took and the results:

[INFO] [Core]: Content ran for a total of: 00 hours, 00 minutes, 27 seconds.
[INFO] Saving runtime log file: /redacted.lrtl
[INFO] [CORE]: No content, starting dummy core.
[INFO] [Core]: Content ran for a total of: 00 hours, 00 minutes, 00 seconds.
[INFO] [Core]: Unloading game..
[INFO] [Core]: Unloading core..
[INFO] [Core]: Unloading core symbols..
[INFO] [Core Options]: Saved core options file to "/redacted/retroarch-core-options.cfg"
Segmentation fault (core dumped)
[INFO] [CRT]: Requested Reolution: 160x144@59.727501 
[INFO] [CRT]: SR init 
[INFO] [CRT]: CRT Mode: 4 - Seleted from ini 
[INFO] [CRT]: SR init_disp 
[INFO] SRobj: RA Monitor Index: 1
[INFO] [CRT]: SR Disp Monitor Index: 1  
[INFO] [CRT]: SR rtn 1 
[INFO] Switchres: Modeline "3840x144_59 15.648605KHz 59.727501Hz" 78.039594 3840 3996 4363 4987 144 194 197 262   -hsync -vsync
[ERROR] XRANDR: <2> (add_mode) [WARNING] this screen is managed by <1310731552>
[ERROR] sr_refresh_display: error refreshing display
[INFO] [CRT]: SR failed to switch mode[INFO] [CRT]: Setting Video Screen Size to: 92160x144 
[INFO] [CRT]: Setting Aspect Ratio: 640.000000 
[INFO] [CRT]: SR scaled  X:24 Y:1 
[INFO] [Video]: Setting refresh rate to: 59.728 Hz.
[INFO] [CRT]: Requested Reolution: 160x144@59.727501 
[INFO] [CRT]: SR init 
[INFO] [CRT]: CRT Mode: 4 - Seleted from ini 
[INFO] [CRT]: SR init_disp 
[INFO] SRobj: RA Monitor Index: 1
[INFO] [CRT]: SR Disp Monitor Index: 1  
[INFO] [CRT]: SR rtn 1 
[INFO] Switchres: Modeline "3840x240_59 15.648605KHz 59.727501Hz" 78.039594 3840 3996 4363 4987 240 242 245 262   -hsync -vsync
[INFO] sr_refresh_display: mode was added
[INFO] sr_switch_to_mode: successfully switched to 3840x240@59.727501
[INFO] [CRT]: Setting Video Screen Size to: 46080x240
[INFO] [CRT]: Setting Aspect Ratio: 192.000000 
[INFO] [CRT]: SR scaled  X:12 Y:1 
[INFO] [CRT]: Setting Video Screen Size to: 160x144 
[INFO] [CRT]: Setting Aspect Ratio: 1.111111 
[INFO] [Video]: Setting refresh rate to: 59.728 Hz.
[INFO] [GL]: VSync => OFF
[INFO] [GLX]: glXSwapInterval(0)
[INFO] [GL]: VSync => ON
[INFO] [GLX]: glXSwapInterval(1)
[INFO] [PulseAudio]: Pausing.
[ERROR] XRANDR: <2> (set_timing) [ERROR] width is above allowed maximum (167186432 > 16384)
[ERROR] XRANDR: <2> (set_timing) [ERROR] height is above allowed maximum (22190 > 16384)
free(): invalid pointer
Aborted (core dumped)

I did not test any other options for super resolution, so I don't know if the previous bugs are still present (since most of them did not happen on 3840). I can test those other resolutions again at a later point.

I hope this testing helps. Let me know if I can help in any other way.

Kopert commented 3 years ago

The previsouly reported issues on 0.5 are still present on 0.6

alphanu1 commented 3 years ago

@Kopert some new checks have been put in place to GB and GBA content. Try these using arcade_15 from the RA menu. Also remember you can save core overrides when you want to use INI over a monitor preset. Or different presets per core. More UI presets will be added down the road and ini overrides per core if one should exist systemname_switchres.ini

Thanks for testing and reporting though it does help.

Kopert commented 3 years ago

@alphanu1 I just want to help in any way I can.

I don't think my issues are related to monitor presets. I changed it back to 15khz in the RA menu and the problems persisted.

The crashes and resolutions failing to change only happen if I load different types of content in succession, for example, if I load a SNES game, then close it and load a GBA game... the resolution doesn't change on the second content and if I keep loading different contents it crashes. If I restart RA every time before I start a game, these issues don't happen.

The problem with GB/GBA games being squished horizontally only happens if I'm using a super resolution that is not NATIVE or DYNAMIC. As you can see in the logs, switchres is trying to set the wrong resolution for the game (after successfully changing the display resolution), as in this message: Setting Video Screen Size to: 46080x240 (if you divide 46080 by my super resolution, 3840, you get 12, which is the value shown here: SR scaled X:12 Y:1)

And I'm concerned with your solution for handhelds being based on the name of the core, because, for example, Game Gear games use the same cores used for Master System and Genesis, but that is an issue for another time.

alphanu1 commented 3 years ago

HH workaround is experimental and only for GB and GBA ATM. Can you test a lower super width? say 2560.

This Setting Video Screen Size to: 46080x240 is a very odd situation. It sounds as though 3840 is not hard set and the dot clock min is multiplying it.

Can you send me you current ini settings?

Kopert commented 3 years ago

@alphanu1 the dotclock_min of my .ini file was at 0. You can find my switchres.ini file at https://pastebin.com/qYtAN7vV

For further testing, I removed my switchres.ini file completely and made sure it was set to 15khz on the RA menu. Then I did the following tests, restarting RA before each test:

alphanu1 commented 3 years ago

@Kopert just pushed a fix that should fix the weird video resolution/aspect bug. Please can you confirm this is now fixed for you?

Kopert commented 3 years ago

@alphanu1 Testing with commit 4c390ea, the problem with different contents not switching resolutions and RA crashing seems to be fixed, thanks! I could not reproduce these problems anymore.

Now trying to provide you with more data regarding the GB/GBA issue:

The GB/GBA issue is still present and apparently if I start one of those, close it, then try to start SNES content (without restarting RA), the SNES content ends up squished as well, as if the Aspect Ratio correction from GBA is still active.

The reverse is also true: if I restart RA, run SNES content (it looks fine), close it, then start GBA content, it does not squish horizontally, as the Aspect Ratio correction remains disabled.

Just a suggestion: I know the current handheld handling is an experimental workaround and might end up working completely different, but might I suggest adding an option to the RA UI for SwitchRes, or to the INI file, to disable the Aspect Ratio correction for handheld content? In case some people need/prefer the unaltered resolution.

alphanu1 commented 3 years ago

@Kopert I have now removed the HH code as the GA team also think this will be better handles via the switchres.ini. Hopefully, we can get more options in down the road.

If you can test and let me know if everything is working OK.

And if you don't mind commenting on your testing an latest results over at the PR that would be great.

AlexFolland commented 3 years ago

The pull request has since been merged. Is this working now, leading this ticket to be ready to be closed?

alphanu1 commented 3 years ago

Yes this ticket should be closed now.

alexb3d commented 3 years ago

Tested in the new version 1.9.7. I still have the same problems that I told you before. It works, although on a monitor presents some errors. I have not been able to use it on a TV.

  1. You have to use the advanced menu, activate the option in Basic Menu does not do anything.

  2. You have to activate the scaling video option, because if not, the image is crushed.

  3. When closed, return to the resolution of the desktop correctly. But when it restarts and then closes, it stays at 240

  4. When the game is loaded does not activate 240P, you have to close the game and reload it.

  5. Activating the menu works well without loading a game, when the game and the menu is activated, you can not distinguish.

alphanu1 commented 3 years ago

@alexb3d My assumption here is that you are using windows!? This all leads to the point that you resolution either not setup correctly. Things have changed over to Calamity's Switchres. So resolutions must be installed as dynamic, as you would for GroovyMame. You must have a switchres.ini in you RetroArch working folder and setup with the presets. If you want to you a monitor preset from the ini, you must choose INI as the CRTSwitchres menu. otherwise, choose a preset. Once this is done you also need to select you monitor index, especially if you have more then one monitor connected.

From the first picture it looks a though you have activated 15KHZ. But your FPS suggest you my be using a 31KHz monitor

CRTEmudriver Documentation Make sure you install you resolution as outlined.

New SR2 CRTSwithres Documentaion

I still believe there is a but when in a multiple GPU environment.

alexb3d commented 3 years ago

@alphanu1 I keep using Linux.

In version 1.9.8 continues to pass the same error with the integrated Intel.

Tested with a GeForce GT620 and a Radeon HD 5500. It does not serve, it does not serve the CRT, the program closes or directly the monitor is turned off without the possibility of recovering.

alexb3d commented 3 years ago

I just tried the stable version, 1.9.8 of the PPA and the AppImage. With the GPU the integrated, a GeForce and an ATI. In the 3 it gives me the error:

[Video]: Setting refresh rate to: 0.000 Hz.

I do not want to be a nuisance and I do not know where I can help. If you want I give you remote access to my PC.

log:

[INFO] [Config]: Loading default config.
[INFO] [Config]: Looking for config in: "/home/lex/.config/retroarch/retroarch.cfg".
[INFO] RetroArch 1.9.8 (Git fa5ec2d4b1)
[INFO] === Build =======================================
[INFO] CPU Model Name: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
[INFO] Funcionalidades:  MMX MMXEXT SSE SSE2 SSE3 SSSE3 SSE4 SSE4.2 AES AVX
[INFO] Built: Aug 22 2021
[INFO] Version: 1.9.8
[INFO] Git: fa5ec2d4b1
[INFO] =================================================
[INFO] [Input]: Found input driver: "x".
[INFO] [Environ]: SET_PIXEL_FORMAT: RGB565.
[INFO] Versión de la API libretro: 1
[INFO] API usada en la compilación: 1
[INFO] [Audio]: Set audio input rate to: 48000.00 Hz.
[INFO] [Video]: Video @ fullscreen
[ERROR] [Wayland]: Failed to connect to Wayland server.
[INFO] [GLX]: GLX_EXT_swap_control_tear supported.
[INFO] [GL]: Found GL context: x
[INFO] [GL]: Detecting screen resolution 3200x1080.
[INFO] [GLX]: Window manager is GNOME Shell.
[INFO] [XINERAMA]: Xinerama version: 1.1.
[INFO] [XINERAMA]: Xinerama screens: 2.
[INFO] [GLX]: Using Xinerama on screen #0.
[INFO] [GLX]: X = 0, Y = 0, W = 1280, H = 960.
[INFO] [GLX]: Using windowed fullscreen.
[INFO] [GLX]: Found swap function: glXSwapIntervalEXT.
[INFO] [GL]: Vendor: NVIDIA Corporation, Renderer: GeForce GT 620/PCIe/SSE2.
[INFO] [GL]: Version: 4.6.0 NVIDIA 390.144.
[INFO] [GL]: Using resolution 1280x960
[INFO] [GL]: Default shader backend found: glsl.
[INFO] [Shader driver]: Using GLSL shader backend.
[INFO] [GLSL]: Checking GLSL shader support ...
[WARN] [GL]: Stock GLSL shaders will be used.
[INFO] [GLSL]: Found GLSL vertex shader.
[INFO] [GLSL]: Found GLSL fragment shader.
[INFO] [GLSL]: Linking GLSL program.
[INFO] [GLSL]: Found GLSL vertex shader.
[INFO] [GLSL]: Found GLSL fragment shader.
[INFO] [GLSL]: Linking GLSL program.
[INFO] [GLSL]: Found GLSL vertex shader.
[INFO] [GLSL]: Found GLSL fragment shader.
[INFO] [GLSL]: Linking GLSL program.
[INFO] [GL]: Using 4 textures.
[INFO] [GL]: Loaded 1 program(s).
[INFO] [GL]: Using GL_RGB565 for texture uploads.
[INFO] [udev]: Pad #0 (/dev/input/event8) supports force feedback.
[INFO] [udev]: Pad #0 (/dev/input/event8) supports 16 force feedback effects.
[INFO] [Joypad]: Found joypad driver: "udev".
[INFO] [Font]: Using font rendering backend: freetype.
[INFO] [DBus]: Suspended screensaver via DBus.
[INFO] [Video]: Found display server: x11
[INFO] [PulseAudio]: Requested 24576 bytes buffer, got 18432.
[INFO] [Display]: Found display driver: "gl".
[INFO] [Font]: Using font rendering backend: freetype.
[INFO] [Font]: Using font rendering backend: freetype.
[INFO] [Font]: Using font rendering backend: freetype.
[INFO] [Font]: Using font rendering backend: freetype.
[INFO] [Font]: Using font rendering backend: freetype.
[INFO] [Font]: Using font rendering backend: freetype.
[INFO] [Font]: Using font rendering backend: freetype.
[INFO] [Font]: Using font rendering backend: freetype.
[INFO] [Font]: Using font rendering backend: freetype.
[INFO] [SRAM]: No se guardará la SRAM.
[INFO] [Playlist]: Cargando historial: [/home/lex/.config/retroarch/content_history.lpl].
[INFO] [Playlist]: Cargando historial: [/home/lex/.config/retroarch/content_music_history.lpl].
[INFO] [Playlist]: Cargando historial: [/home/lex/.config/retroarch/content_video_history.lpl].
[INFO] [Playlist]: Cargando historial: [/home/lex/.config/retroarch/content_image_history.lpl].
[INFO] [Playlist]: Cargando favoritos: [/home/lex/.config/retroarch/content_favorites.lpl].
[INFO] [PulseAudio]: Pausing.
[INFO] [GLX]: Resized fullscreen resolution to 1280x960.
[INFO] [CRT]: Requested Reolution: 320x240@60.000000 
[INFO] [CRT]: SR init 
[INFO] [CRT]: CRT Mode: 3 - pc_31_120 
[INFO] [CRT]: SR init_disp 
[INFO] [CRT]: RA Monitor Index Auto: auto
[ERROR] XRANDR: <1> (xrandr_timing) [ERROR] missing X11_LIBRARY library
[INFO] [CRT]: SR Disp Monitor Index Auto: Auto  
[INFO] [CRT]: SR rtn 0 
[INFO] [CRT]: SR failed to init 
[INFO] [CRT]: Setting Aspect Ratio: 1.333333 
[INFO] [CRT]: Setting Video Screen Size to: 320x240 
[INFO] [Video]: Setting refresh rate to: 0.000 Hz.
[INFO] [GLX]: Resized fullscreen resolution to 1280x960.
[INFO] [PulseAudio]: Unpausing.
[INFO] [PulseAudio]: Pausing.
[INFO] [PulseAudio]: Unpausing.
[INFO] [Config]: Se ha guardado una nueva configuración en "/home/lex/.config/retroarch/retroarch.cfg".
[INFO] [Core]: Content ran for a total of: 00 hours, 00 minutes, 00 seconds.
[INFO] [PulseAudio]: Pausing.
[INFO] [Core]: Unloading core..
[INFO] [Core]: Unloading core symbols..
[INFO] [XINERAMA]: Xinerama version: 1.1.
[INFO] [XINERAMA]: Xinerama screens: 2.
[INFO] [XINERAMA]: Saved monitor #0.
[INFO] [Video]: Does not have enough samples for monitor refresh rate estimation. Requires to run for at least 4096 frames.
[INFO] [Video]: Does not have enough samples for monitor refresh rate estimation. Requires to run for at least 4096 frames.
alphanu1 commented 3 years ago

It shows in the Log that you are missing X libraries and SR failed to init

what is your exact setup?

alexb3d commented 3 years ago

I made a new Ubuntu installation only to try the CRT. Before re-install it worked, with the mistakes I told you before.

This is what you need?

OS: Ubuntu 20.04.3 LTS x86_64 
Kernel: 5.11.0-27-generic 
Shell: bash 5.0.17
Resolution: 1024x768 
DE: GNOME 
WM: Mutter 
CPU: Intel i7-3770 (8) @ 3.900GHz 
GPU: Intel HD Graphics 
Memory: 2372MiB / 7637MiB 

What are they called exactly the missing libraries? To see if it works by installing it manually.

alexb3d commented 3 years ago

It still does not work. 1.9.9 Captura de pantalla de 2021-09-08 02-14-37

alphanu1 commented 3 years ago

This is working fine for many other users. It’s all about your OS and setup.

You need to ensure all X11 libraries are installed. You can get more information over on the GrooveyArcade forum

alexb3d commented 3 years ago

The libraries are in the repository. When retroarch is installed does not install the libraries as dependencies. Nobody who use Ubuntu will be able to use this feature if it does not manually install the libraries.

https://askubuntu.com/questions/1344364/i-am-getting-error-about-x11-library

sudo apt-get install libx11-dev libxrandr-dev

They are in the repository, they must be installed by default.

I already have several versions asking for help and could not you tell me this? Lack of consideration friend.

alphanu1 commented 3 years ago

No need to be like that.

Multiple post and responses from myself mention missing X libraries. Without knowing what you do or don’t have installed does not help. Anyway, I am glad you have resolved it.

hizzlekizzle commented 3 years ago

it looks like those libs are not currently installed as runtime dependencies for the PPA packages, but I can change that.

alphanu1 commented 2 years ago

The CRTSwitchRes docs should be updated soon with the new information. Docs PR

alexb3d commented 2 years ago

@alphanu1 Please do not get me wrong. I'm going to tell you what I have in my head.

Ubuntu and its derivatives is the most used distro, by far. When an ordinary user use the CRT and does not work, he is not going to look for all this information. "Generate the log, open reports, search for information on the network that is X11, etc." What he is going to do is say "this does not serve, Retroarch is a shit." That is, bad publicity.

RetroArch is wonderful and the CRTSwicht is simply amazing, it has to work well.

Thank you for all the work you are doing and for your patience.

evelyndooley commented 2 years ago

These libraries are also missing in the Flatpak version. I am running on Fedora and even with the libraries installed through DNF, I am getting this line in my log file.

[ERROR] XRANDR: <4> (xrandr_timing) [ERROR] missing X11_LIBRARY library

Attempting to compile from source on fedora was a nightmare, the resulting build was missing input drivers that worked with any controllers and had some other issues. Is there a way to add these libraries to the flatpak version or am i going to have to switch to ubuntu?

alexb3d commented 2 years ago

@evelyndooley Long, time ago is reported but, it is Flatpak :/

AppImage is a great option, install the libraries "libx11-dev libxrandr-dev" manually from the Fedora repository.

MiltosKoutsokeras commented 2 years ago

Hi all,

I have been bitten also by the error message:

[ERROR] XRANDR: <1> (xrandr_timing) [ERROR] missing X11_LIBRARY library

in Debian 11. I build from sources and the deployment machine is different than the build machine (both Debian 11). The reason why this happens, is the the code is explicitly searching for the X11 library name libX11.so in file deps/switchres/custom_video_xrandr.cpp lines 127, 325:

m_x11_handle = dlopen("libX11.so", RTLD_NOW);

This cannot work on systems that do not have installed the development library and only have the runtime library. The runtime library does not install the symbolic link /usr/lib/x86_64-linux-gnu/libX11.so, so if the machine was not used to build the program with all installed dev dependencies, it will fail to run CRT Switch Res, as the library is opened at runtime with dlopen instead of being linked on build with the same name. Check the linked libraries with this command:

ldd <path/to/your/retroarch/executable>

On my system and configuration it prints the following:

    linux-vdso.so.1 (0x00007ffd1bbe6000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6c63892000)
    libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007f6c6374f000)
    libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x00007f6c6373a000)
    libXxf86vm.so.1 => /lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f6c63534000)
    libXrandr.so.2 => /lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f6c63329000)
    libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x00007f6c632a2000)
    libEGL.so.1 => /lib/x86_64-linux-gnu/libEGL.so.1 (0x00007f6c6328b000)
    libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f6c630be000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6c630b8000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6c62f74000)
    libmvec.so.1 => /lib/x86_64-linux-gnu/libmvec.so.1 (0x00007f6c62f48000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6c62f2e000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6c62d67000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f6c64455000)
    libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f6c62d3c000)
    libXrender.so.1 => /lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f6c62b32000)
    libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f6c62a7a000)
    libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f6c62a46000)
    libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007f6c62a3f000)
    libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f6c62839000)
    libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f6c62822000)
    libmd.so.0 => /lib/x86_64-linux-gnu/libmd.so.0 (0x00007f6c62815000)

As you can see it is linked against libX11.so.6 which is found, but on code it tries to load libX11.so which is missing on systems that did not build the program themselves.

One workaround is to simply install the dev library sudo apt install libx11-dev. But I think for consistency with modern Linux configuration the code of switchres needs to change and load without dlopen since it is a hard dependency on the functionality and not a plugin.

The same applies for libXrandr.so. Take a look below:

Dev Machine

find / -name '*libX11.so*' 2>/dev/null; find / -name '*libXrandr.so*' 2>/dev/null

outputs:

/usr/lib/x86_64-linux-gnu/libX11.so.6
/usr/lib/x86_64-linux-gnu/libX11.so
/usr/lib/x86_64-linux-gnu/libX11.so.6.4.0
/usr/lib/x86_64-linux-gnu/libXrandr.so.2.2.0
/usr/lib/x86_64-linux-gnu/libXrandr.so
/usr/lib/x86_64-linux-gnu/libXrandr.so.2

Deployment Machine

find / -name '*libX11.so*' 2>/dev/null; find / -name '*libXrandr.so*' 2>/dev/null

outputs:

/usr/lib/x86_64-linux-gnu/libX11.so.6.4.0
/usr/lib/x86_64-linux-gnu/libX11.so.6
/usr/lib/x86_64-linux-gnu/libXrandr.so.2.2.0
/usr/lib/x86_64-linux-gnu/libXrandr.so.2
alexb3d commented 2 years ago

@MiltosKoutsokeras Please read the previous message.

MiltosKoutsokeras commented 2 years ago

Yes the installation of the development libraries solved the issue. But you should not expect the runtime machine to have the development libraries when it is using a program. Most Linux distributions have 2 different packages for runtime and development files. If you build in a single machine and copy the built artifacts to multiple, you will encounter the issue.

alexb3d commented 2 years ago

I do not understand anything, you're talking to me in Chinese. :D

He who can answer your doubts is @hunterk

LibretroAdmin commented 2 years ago

@alphanu1 can this issue be closed by now?