RA/Wayland : vertical frequency applied internally but no screen mode switch

[bidinou]

Hi ! Trying to minimize latency as much as possible (for cores which are not optimal, like puae, as it doesn't support runahead), I was suggested to switch to Wayland + Vulkan and using a single buffering mode with no VSync.

For some reason, there is no tearing when using single buffering under Wayland. Which means, 20 ms won on 50 Hz cores !

This issue is the following :

- when a core override is set, indicating a custom vertical frequency, it is applied by RA (internal rendering), however it doesn't trigger a monitor mode switch (which remains at the desktop frequency)

(for instance, by default, my monitor is at 144 Hz. I load the UAE core with a 50 Hz freq. override. In the video settings, the current vertical freq. is indeed 50 Hz but the monitor freq. is still 144 Hz)

however, under X, a custom freq. is both applied to RA and triggers a mode switch.

Configuration is : latest SNAP packages, KDE Neon (Ubuntu 20.04 based), Vulkan, AMD GPU, Plasma/Wayland.

[i30817]

I really doubt wayland allows single applications to change your refresh rate, just like it doesn't allow you to change your desktop resolution.

Part of the design goals of wayland was to avoid 'ugly' mode switch from applications not 'authorized' (the gnome settings program can for instance).

They're probably working on something like that for variable refresh rate monitors or though, since it's shiny and new and doesn't require mode switch.

[nfp0]

I was suggested to switch to Wayland + Vulkan and using a single buffering mode with no VSync

@bidinou That is not possible on Wayland for now. It's a work in progress. Who suggested that to you?
I did these tests a while back if you're interested in the best modes for reduced latency:
https://forums.libretro.com/t/an-input-lag-investigation/4407/1006?u=nfp0

Long story short, on Linux, KMS, Uncomposited X and Kwin Wayland on AMDVLK provide you with the smallest possible latency (don't know about other desktops).
The problem is that I have a lot of issues with RetroArch on AMDVLK on my machine. Give it a try on your system and if all else fails, you got KMS.

[i30817]

KMS has a lot of other problems in certain hardware or cores that want to change resolutions.

The problems i encountered were:

1. retroarch eats the VT switch key combinations, so if for any reason retroarch locks up, you're forced to 'power reset' (or kernel software reset, if you can remember the key combinations for your OS/kernel/keyboard), because you can't switch the virtual terminal away from the frozen retroarch. This can damage hard-drives if you don't do the kernel reset.
2. A particular important hardware quirks/compatibility library (libinput) that puts itself between the supposedly 'raw' kernel input interfaces and userland programs only starts up once you're in a graphical environment. So if you have 'naughty' hardware, direct access is often a bad idea. I'm talking about touchpads becoming 'tablet screens' instead of mouse etc etc.
3. And finally what made me give up on kms: the kernel has a lock mechanism to have exclusive access to the graphics card (the so called 'drm master'), that can be 'normally' be called without root if you're on a VT, because switching to a VT dropped the lock from, for instance, X11 or wayland. Since RA doesn't allow you to switch VTs while running in KMS (see 1), this is not a problem (so RA doesn't drop the permission). The problems occur when you have to mode switch because a core wants to change screen resolution from the natural one the menu starts with. This apparently always fails, even if it's rare to happen in emulators (for instance, you can try to change the internal resolution multiplier in beetle.
   I think this happens because a resolution change triggers a gpu mode change and 'something' has to happen, not sure if related to the 'drm master', although i suspect so, since lakka doesn't have this problem (lakka runs with root). Anyway, it crashes retroarch.

If you want to use KMS, it's better to have a dedicated Lakka install I suppose (needless to say, using root with normal retroarch is a recipe for horrible problems and vulnerabilities). And you still have to worry about problem 1&2 (although I never tried lakka so for all i know they fixed those two problems long ago. Kind of doubt it though).

[nfp0]

Yeah, KMS has its own can of worms, no doubt. I've also avoided using it because of some issues with cores. I also noticed the VT changing problems you mention. I worked around it by SSHing from my phone and rebooting the PC, but yeah... not practical at all.
I did not know Lakka ran RetroArch as root. That explains how they can work around some of the issues. Thanks for the explanation! 🙂

[i30817]

What i didn't mention is that for problem number 1 are really easy way to trigger it is to try to search a playlist/menu in KMS. The screen comes up, but without a keyboard focus (or something like that) so you can't dismiss it, and so can't navigate the screens to exit retroarch. Frozen (without a gamepad at the very least).

I refuse to believe that Lakka hasn't fixed this, because it's so horrible and obvious, so i guess someone that cares about KMS on retroarch itself should look up how they're doing it. Maybe it's a permission issue again.

You can reset a 'frozen' linux computer without ssh with the kernel Alt+SysRq REISUB mantra.

[nfp0]

Yeah, that would be a pretty easy situation to get into a lock.

You can reset a 'frozen' linux computer without ssh with the kernel Alt+SysRq REISUB mantra.
Ah yes, thank you! @i30817 I had forgotten about it.

[i30817]

I suppose that there might be good news about on the quirks hardware front, because last time i updated ubuntu 22.04.1 it decided to install 'systemd-hwe-hwdb' which is a pretty telling name and the page for that package tells me it's exactly what i expected it to be (quirks database for udev). Maybe the quirks were moved to a library to start at boot, x11 or wayland, at least for the udev driver.