FPS set to 60 when Fullscreen on a 165hz monitor (Arch Linux + i3wm)

[vuln]

Hi there.

I am using Arch Linux with the window manager i3wm (X11) and have a 165hz monitor.

The issue that I am facing here is that when the window is set to fullscreen, the refresh rate of my monitor is set to 60hz.
(I can see that it changes the refresh rate of my monitor because the screen goes black for a couple of seconds and the cursor does not move smoothly)

sf::RenderWindow window(sf::VideoMode(SCREEN_WIDTH, SCREEN_HEIGHT), "App", sf::Style::Fullscreen);

If I enable v-sync, which should set the window FPS to my monitor refreshrate (in my case 165) but instead it sets the fps to 60.

window.setVerticalSyncEnabled(true);

If I disable v-sync, the FPS is as big as it can be regardless of monitor refresh rate but the mouse cursor does not feel smooth and so does everything on the screen.

However if I don't set the window to fullscreen, the fps/refresh rate is 165 when v-sync is enabled or as big as is can when v-sync is off.

sf::RenderWindow window(sf::VideoMode(SCREEN_WIDTH, SCREEN_HEIGHT), "App");

I built SFML 2.6.0 from source.

Thank you for your time.

[eXpl0it3r]

Do you have multiple monitors? Is one of those a 60Hz monitor? I found some post about X11 not being able to properly handle this.

Either way it sounds like some issue between X11, xrandr, i3wm and your GPU.
Have you tried any other OpenGL games? Do they run at the correct refresh rate in fullscreen mode?

[vuln]

No I only have one monitor

I have tried several OpenGL games (like CS2, Noita or hacknet) and had no issue at all

edit: I also tried to launch the app in KDE Plasma, Checked my drivers and my graphics card is new so it cant be failing

[eXpl0it3r]

Are you running them in true fullscreen mode or just borderless window fullscreen mode?

Looking around a bit on the web it seems quite a common issue that games lock at 60Hz in fullscreen mode instead of the monitor refresh rate. Some seem to get it fixed with changing GPU settings, but I've mostly seen this for Windows, not sure what's the case on Linux.

[vuln]

I believe I am using true fullscreen.
I set it to fullscreen by using sf::Style::Fullscreen when creating the window.

I have messed around with the GPU settngs (nvidia-settings) and set my resolution to 1080p 165hz (I have a 1440p monitor) and the hz of my monitor was not changed when opening the app (no black screen for 5 sec when launching or closing the window).

When i set it to 1440p 165hz (what i normally use) the issue occurs.

[eXpl0it3r]

I believe I am using true fullscreen.
I set it to fullscreen by using sf::Style::Fullscreen when creating the window.

Ah, I meant for the other games you tried.

[vuln]

On games I trieed:
CS2 and Hacknet: Fullscreen
Noita: Fullscreen (real)
Reassembly: Fullscreen: True fullscreen

every game listed here uses Opengl

[vuln]

I have found the issue.

I used this to set up my screen:

sf::RenderWindow window(sf::VideoMode(SCREEN_WIDTH, SCREEN_HEIGHT), "App", sf::Style::Fullscreen);

This works fine but I set the Screen size manually and in some way it changes some things resulting in the monitor hz getting set to 60 (probably default) or gets the video mode with the resolution of 1920x1080 60hz.

however if I use this:

sf::VideoMode videoMode = sf::VideoMode::getDesktopMode();
sf::RenderWindow window(videoMode, "App", sf::Style::Fullscreen);

The VideoMode gets the screen size and information about the graphics driver / monitor and sets the video mode to the best one that is supported.

Here is the function in VideoMode.hpp:

static VideoMode getDesktopMode();

////////////////////////////////////////////////////////////
/// \brief Retrieve all the video modes supported in fullscreen mode
///
/// When creating a fullscreen window, the video mode is restricted
/// to be compatible with what the graphics driver and monitor
/// support. This function returns the complete list of all video
/// modes that can be used in fullscreen mode.
/// The returned array is sorted from best to worst, so that
/// the first element will always give the best mode (higher
/// width, height and bits-per-pixel).
///
/// \return Array containing all the supported fullscreen modes
///
////////////////////////////////////////////////////////////

Thank you for your time

[Hapax]

It should be noted that the method descriptions above the declarations so the description for "getDesktopMode()" is:

    ////////////////////////////////////////////////////////////
    /// \brief Get the current desktop video mode
    ///
    /// \return Current desktop video mode
    ///
    ////////////////////////////////////////////////////////////

whereas the description you quoted is for the following method (getFullscreenModes())

It's worth noting that if you create a video mode without providing a bit depth, it will use a default value (32-bit) and this might not match the current desktop's bit depth and therefore the video mode doesn't match.

getDesktopMode() should always match the current mode automatically (size and bit depth/bits per pixel).

With that said, the first item in the getFullscreenModes() vector is likely to be the best (highest) candidate for a fullscreen app.

It's also worth noting that your monitor might be switching to 60Hz rather than your app/graphics card working at 60Hz but sending that information to your monitor at 165Hz.

So, in conclusion, I would suppose it's possible that the 32-bit bit depth is a mode that your monitor likes to be at 60Hz?

[vuln]

It should be noted that the method descriptions above the declarations so the description for "getDesktopMode()" is:

    ////////////////////////////////////////////////////////////
    /// \brief Get the current desktop video mode
    ///
    /// \return Current desktop video mode
    ///
    ////////////////////////////////////////////////////////////

oops

Anyways, it seems like my monitor (Lenovo G27q-30) likes to be at 60hz when using 32bit depth (I suppose) but out of my curiosity I wanted to know at what bit depth the "getDesktopMode()" VideoMode was:

std::cout << sf::VideoMode::getDesktopMode().bitsPerPixel << "\n";

output: 24

So it seems like my monitor likes 24bit depth when at 165hz?
I don't really get it why it's doing this, because no other app does this (change hz or resolution of my monitor).

[Hapax]

I suppose that your monitor has a maximum bit depth for 165Hz (or maximum frequency for 32-bit bit depth).

Do other apps try to set it to 32-bit bit depth even though your desktop is set to 24-bit (I presume since getDesktop clearly gets 24-bit)

You likely don't need 32-bit anyway as its only transparency that's the improvement from 24-bit.

Have you tried to open a fullscreen window with manual values (width and height) as well as manual 24-bit bit depth and does that work as expected?

[vuln]

Do other apps try to set it to 32-bit bit depth even though your desktop is set to 24-bit (I presume since getDesktop clearly gets 24-bit)

It doesnt seem like it. (my monitor does not change refresh rate when opening/closing the apps)

You likely don't need 32-bit anyway as its only transparency that's the improvement from 24-bit.

How big is actually the difference. (And why does it say on Lenovo's website ( https://www.lenovo.com/il/en/monitors/G27q-30) say that it has a color depth of 8-bit (6+FRC) color depth. maybe bits per color channel?)
And why can I set the bit depth to 32 (windowed) and not make the monitor switch hz?

Have you tried to open a fullscreen window with manual values (width and height) as well as manual 24-bit bit depth and does that work as expected?

yes I tried and everything behaved as it should like it did when using getDesktop().

[Hapax]

It looks to me like your monitor restricts 32-bit bit depth to 60Hz. As to why, you would have to ask Lenovo, I guess!

Looking at your link to your monitor, I see that it supports 16.7 billion colours. That is 24-bit colour.

The 8-bit colour depth, then, is likely per channel.

It also mentions FRC (Frame Rate Control) that "flickers" colours to create more shades so maybe this could be a reason the frequency is affected - it's using the frequency to mix colours.


In conclusion, the fact that the getting the desktop mode, setting the best mode manually with the correct bit-depth and other apps likely not attempting to switch to 32-bit mode suggests that it's just a monitor design and you need to pick the right mode, which, it seems for you, is best at 24-bit colour.


As an aside, you may want to make sure FreeSync technology is switched off when doing frequency tests.

[vuln]

Thank you for the information and your time.