[Resolved] Limited to 60 hz, but only on Linux (nvidia, nouveau, sway)

Hubro · 2023-01-05 11:29:41

I just had Windows running on this PC with the monitor running at 3840x2160 @ 144 hz.

I installed Arch linux on it today, using the open source driver (nouveau) and Sway. Now my monitor is capped at 3840x2160 @ 60 Hz:

➜ swaymsg -t get_outputs
Output DP-1 'GIGA-BYTE TECHNOLOGY CO., LTD. M28U 22120B003932' (focused)
  Current mode: 3840x2160 @ 60.000 Hz
  Position: 0,0
  Scale factor: 2.000000
  Scale filter: nearest
  Subpixel hinting: unknown
  Transform: normal
  Workspace: 1
  Max render time: off
  Adaptive sync: disabled
  Available modes:
    3840x2160 @ 60.000 Hz
    3840x2160 @ 60.000 Hz
    3840x2160 @ 59.940 Hz
    3840x2160 @ 24.000 Hz
    3840x2160 @ 23.976 Hz
    2560x1440 @ 143.856 Hz
    2560x1440 @ 119.879 Hz
    2560x1440 @ 59.940 Hz
    1920x1080 @ 143.853 Hz
    1920x1080 @ 120.000 Hz
    1920x1080 @ 119.880 Hz
...

This was just working at 3840x2160 144 hz on Windows on the exact same PC, ports, cables and monitor.

Does anybody have any ideas as to what the reason might be? Where do I even start looking?

---

I tried installing the proprietary driver (the "nvidia" package) but was then unable to even launch Sway, giving me an error message about "skipping gpu, no kms" then "no gpu found"...

Last edited by Hubro (2023-01-07 18:50:17)

d.ALT · 2023-01-05 12:04:25

First: nouveau is a no-go, especially with new GPUs!

Second:

Hubro wrote:

about "skipping gpu, no kms" then "no gpu found"...

You'll need to enable both Early KMS start and Late KMS start!

Head_on_a_Stick · 2023-01-05 14:32:50

Hubro wrote:

I tried installing the proprietary driver (the "nvidia" package) but was then unable to even launch Sway, giving me an error message about "skipping gpu, no kms" then "no gpu found"...

Did you try the --unsupported-gpu option? I think that should get it working. But perhaps not very well. Bloody NVIDIA.

seth · 2023-01-05 14:39:53

You should™ use early kms, but you you can't use early and late kms at the same time

Most importantly, add "nvidia-drm.modeset=1" (this is also a prerequisite to get wayland running) to the kernel parameters and post the EDID

edid-decode /sys/class/drm/card0-DP-1/edid

https://aur.archlinux.org/packages/edid-decode-git

And also post a complete system journal after supposingly installing the nvidia driver and setting the modesetting parameter

sudo journalctl -b | curl -F 'file=@-' 0x0.st

Windows running on this PC with the monitor running at 3840x2160 @ 144 hz

Are we absofuckinglutely sure about that?
Because there's a modeline for 2560x1440…

d.ALT · 2023-01-05 16:57:30

<EDIT>

seth wrote:

You should™ use early kms, but you you can't use early and late kms at the same time

seth... So... nvidia_drm.modeset=1 OR you can add nvidia, nvidia_modeset, nvidia_uvm and nvidia_drm to the initramfs???
</EDIT>

seth wrote:

Windows running on this PC with the monitor running at 3840x2160 @ 144 hz
Are we absofuckinglutely sure about that?
Because there's a modeline for 2560x1440…

On my 4K Samsung TV (HDMI), nuoveau (GTX1660S) cannot even get to 1440p, neither 4K@60 (tested on: Arch (installation), Debian (installation), Fedora (live), *buntu(live)).

Last edited by d.ALT (2023-01-05 17:22:34)

Hubro · 2023-01-05 18:10:59

seth wrote:

You should™ use early kms, but you you can't use early and late kms at the same time
Most importantly, add "nvidia-drm.modeset=1" (this is also a prerequisite to get wayland running) to the kernel parameters and post the EDID
edid-decode /sys/class/drm/card0-DP-1/edid
https://aur.archlinux.org/packages/edid-decode-git
And also post a complete system journal after supposingly installing the nvidia driver and setting the modesetting parameter
sudo journalctl -b | curl -F 'file=@-' 0x0.st
Windows running on this PC with the monitor running at 3840x2160 @ 144 hz
Are we absofuckinglutely sure about that?
Because there's a modeline for 2560x1440…

Hey, that did something! Now I’m no longer getting that error, instead I’m getting this error: https://i.imgur.com/iIwlqcP.jpg

Uploaded the complete system journal here: http://0x0.st/oRUO.txt

If it matters, I’m using a GTX 1060: https://i.imgur.com/FumeQS7.jpg

And yes I’m 100% completely sure I ran the monitor at 4K 144hz on Windows

alnick · 2023-01-05 19:31:55

I suspect that this is precisely because of the monitor firmware manufactured by GIGABYTE. I have a monitor of the same manufacturer M32UC with a resolution of 3840x2160_144. In windows, via displayport 1.4, it quietly accelerates to 165 Hz. The arch has only 60 Hz.Yes, the video card is 6800XT.

seth · 2023-01-05 21:47:29

https://wiki.archlinux.org/title/Variable_refresh_rate ?

@Hubro, please try to provide the EDID
The journal you posted seems to have some GUI session running (and vivaldi crash)?
Does weston work (instead of sway)?

Hubro · 2023-01-06 00:03:28

seth wrote:

https://wiki.archlinux.org/title/Variable_refresh_rate ?
@Hubro, please try to provide the EDID
The journal you posted seems to have some GUI session running (and vivaldi crash)?
Does weston work (instead of sway)?

Weston does indeed work! That’s interesting.

Here is the edid-decode output: http://0x0.st/oRGt.txt

I disabled variable sync both on the monitor and in my Sway config, but it didn’t make any difference. However, I also tried launching Sway without any configuration, and that seems to work as well…

—-

After a long process of elimination, it turns out the variable «WLR_DRM_NO_MODIFIERS» is what was causing Sway to fail to launch, which I’ve had in my launch script for months (maybe years? See https://github.com/swaywm/sway/issues/5008).

After launching Sway, I was able to set the mode to 3840x2160@144.000Hz! And it works. Things are smooth as butter.

Some strange issues still remaining though. For some reason, the screen flickers pretty badly: https://streamable.com/ykk7mb This happens no matter which resolution or refresh rate I pick, could it be down to an issue with the EDID? Is there some way for me to tweak it?

And also, the cursor disappeared (as you can see in the video above.) I can still move it around and click stuff, but it’s completely invisible, making things pretty difficult It was visible when I used nouveau.

Last edited by Hubro (2023-01-06 00:08:18)

Hubro · 2023-01-06 00:12:45

Here's the output of "swaymsg -t get_output" now:

Output DP-3 'GIGA-BYTE TECHNOLOGY CO., LTD. M28U 22120B003932' (focused)
  Current mode: 3840x2160 @ 60.000 Hz
  Position: 0,0
  Scale factor: 1.000000
  Scale filter: nearest
  Subpixel hinting: unknown
  Transform: normal
  Workspace: 1
  Max render time: off
  Adaptive sync: disabled
  Available modes:
    3840x2160 @ 60.000 Hz
    3840x2160 @ 144.000 Hz
    3840x2160 @ 119.880 Hz
    3840x2160 @ 119.999 Hz
    3840x2160 @ 59.940 Hz
    3840x2160 @ 23.976 Hz
    2560x1440 @ 143.856 Hz
    2560x1440 @ 119.879 Hz
    2560x1440 @ 59.940 Hz
    1920x1080 @ 143.853 Hz
    1920x1080 @ 119.879 Hz
    1920x1080 @ 60.000 Hz
    1920x1080 @ 59.939 Hz
    1920x1080 @ 23.977 Hz
    1680x1050 @ 59.954 Hz
    1280x1024 @ 60.020 Hz
    1440x900 @ 59.887 Hz
    1280x720 @ 119.879 Hz
    1280x720 @ 59.943 Hz
    1024x768 @ 75.029 Hz
    1024x768 @ 60.004 Hz
    800x600 @ 75.000 Hz
    800x600 @ 60.317 Hz
    720x480 @ 59.940 Hz
    640x480 @ 75.000 Hz
    640x480 @ 59.940 Hz

One interesting fact is that the current mode always says 60 Hz, no matter which mode I pick, even though I can clearly tell it's 144 Hz.

seth · 2023-01-06 08:36:45

Things are smooth as butter … For some reason, the screen flickers pretty badly

Butter doesn't flicker.

The video is only 30fps and still picks up the flicker, so whatever flowery "smoothness" you may "feel", you're probably only rendering at 60FPS (and incidentally sway suggests 60Hz)
The flicker artifact looks like some garbled texture (black text on white background?) but not like some proper window content, so it would seem like some uninitialized buffer makes it to the scanout.

Searching for "flicker" in sway issues yields plenty of results, eg.
https://github.com/swaywm/sway/issues/7177
https://github.com/swaywm/sway/issues/7089
https://github.com/swaywm/sway/issues/7087
https://github.com/swaywm/sway/issues/6473
https://github.com/swaywm/sway/issues/6408

So try
- one output only
- at 1920x1080 @ 60.000 Hz
- w/o running firefox (any browser, probably)
=> Still flicker?

Hubro · 2023-01-06 09:57:00

seth wrote:

Things are smooth as butter … For some reason, the screen flickers pretty badly
Butter doesn't flicker.
The video is only 30fps and still picks up the flicker, so whatever flowery "smoothness" you may "feel", you're probably only rendering at 60FPS (and incidentally sway suggests 60Hz)
The flicker artifact looks like some garbled texture (black text on white background?) but not like some proper window content, so it would seem like some uninitialized buffer makes it to the scanout.
Searching for "flicker" in sway issues yields plenty of results, eg.
https://github.com/swaywm/sway/issues/7177
https://github.com/swaywm/sway/issues/7089
https://github.com/swaywm/sway/issues/7087
https://github.com/swaywm/sway/issues/6473
https://github.com/swaywm/sway/issues/6408
So try
- one output only
- at 1920x1080 @ 60.000 Hz
- w/o running firefox (any browser, probably)
=> Still flicker?

True, perhaps flicker was a poor choice of words. The monitor is *definitely* operating at 144 hz. There's a night and day difference between 60 hz and 144 hz, both in motion smoothness and input delay. So I don't mean that it's stuttering, everything is moving super fast and smooth, there's just some weird colors flickering across the screen.

I've tried running the panel at every refresh rate, and both 4K and 1080p, but it doesn't affect the flicker. I also only have one display connected. Interestingly, it seems to matter a lot what I'm doing. If I open a terminal window on top of my browser and move my mouse around (like in the video above) the screen flickers like crazy. However, if I close the terminal and only use the browser, the flicker *almost* disappears. For the duration I've written this post, the screen has flickered maybe once. But as soon as I start scrolling up or down, it starts flickering like crazy again.

After some more testing, it doesn't seem to matter which application I use, only the amount of motion on screen.

However, right now my biggest issue is that I can't see my mouse The mouse is also invisible in Weston, so at first I thought everything was frozen.

There are still some errors in the Sway log: http://0x0.st/oRkv.txt

EDIT: I tried closing all my browsers, and it definitely becomes a lot harder to reproduce the flicker, but I can still do it. If I dump a lot of stuff into a terminal and scroll vigorously, it still flickers.

EDIT: I found this: https://github.com/swaywm/wlroots/issues/3189, setting "WLR_NO_HARDWARE_CURSORS" fixes the cursor being invisible

Last edited by Hubro (2023-01-06 10:07:34)

seth · 2023-01-06 10:31:45

But as soon as I start scrolling up or down, it starts flickering like crazy again.

Is the browser a native wayland instance or does it run on xwayland?
What if you disable hardware acceleration for the browser? (The wiki has entries for FF and Chromium on that)

Semmi-OT, but the emo-talk around this starts to annoy me.
So here's a reality check.

The monitor is *definitely* operating at 144 hz. There's a night and day difference between 60 hz and 144 hz

super fast and smooth

I guess everyone's trying to sell themselves their xmas presents, but I'll state here as well that so far no human being has ever demonstrated to pick up anything > 75Hz in an actually scientific test environemnt and most struggle w/ 60Hz.
What you can pick up and what high-frequency outputs are actually meant to combat are imperfections in the output chain that result in much lower refresh rates (multiple vsync blocks stackign up or the source being unable to produce consistent 60fps which results in output frames being skipped and then oc. 30fps is far more notable than eg. 42fps in the worst case scenario w/ a 144Hz output)

So instead of guessing around, I *highly* recommend that if you want to combat the data from sway, check some other data.
I guess your monitor has an OSD that'll tell you what signal it actually receives.
Your feelings about being maybe a bird-of-prey of sorts are extremely unreliable itr.

Hubro · 2023-01-06 12:23:53

Is the browser a native wayland instance or does it run on xwayland?

Native wayland. I've also tested various terminals, the Nautilus file explorer and Telegram, which I believe is a native QT application, and I can reproduce the flickering everywhere, but with differing intensity. It's definitely *by far* worst while scrolling in a web browser.

What if you disable hardware acceleration for the browser? (The wiki has entries for FF and Chromium on that)

I disabled "Use hardware acceleration when available" and restarted the browser, "chrome://gpu" confirms that hardware acceleration is disabled. Doesn't seem to affect the flickering at all, unfortunately.

I will test Weston and see if I can reproduce the flickering there, or if it's just in Sway. It's a bit challenging as I've never used Weston before, and currently I'm not even sure how I start an application But I'll figure it out.

So here's a reality check.

Counter reality check! It may be true that it's hard to distinguish anything above 75Hz when it comes to video playback, but for computer monitors this notion is absolutely laughable. I don't think anybody who has tried a high refresh rate display would every say something like this. To me it sounds like arguing that the colors "blue" and "green" looks exactly the same. My monitor has been stuck on 60hz the last few days while using the nouveau driver, and it's been extremely distracting. The mouse felt sluggish and scrolling looked blurry and unresponsive, much like on my 40" 4K 60Hz display, and I even feel a very slight delay when typing text. There's a reason gaming displays keep pushing up the refresh rate ever higher, it's because it makes a big difference in input delay and motion clarity. Getting the monitor to output at 144 hz feels so nice that I'm definitely keeping it this way, in spite of the flickering.

Mind you, my daily driver the last year has been a 1440p 240hz display, so I've gotten very used to high refresh rates. I bought this 4K monitor because I want sharper text for work (I'm a software developer.) but I absolutely can't stand using 60hz displays. I think anybody who has gotten used to high refresh rate displays feels the same way, it doesn't take a bird of prey.

Although I can understand that for somebody who are used to 60 hz displays, I might sound like an absolute promadonna bitching about nothing.

I guess your monitor has an OSD that'll tell you what signal it actually receives.

Oh yeah, true. Interestingly, as I'm taking screenshots, it seems the "swaymsg -t get_outputs" output has resolved itself since yesterday somehow, and it now correctly shows the mode I'm on:

https://i.imgur.com/Qctp2zl.jpg
https://i.imgur.com/I91HRSA.jpg

Last edited by Hubro (2023-01-06 12:25:48)

Hubro · 2023-01-06 12:45:13

Alright, after a little configuration I now have Vivaldi running in Weston at 3840x2160@144, and there's absolutely no flickering! So at least that tells me for sure that there's no inherent hardware issue here, it's all in the software.

seth · 2023-01-06 16:22:58

So at least that tells me for sure that there's no inherent hardware issue here, it's all in the software.

Do you use sth. like https://aur.archlinux.org/packages/weston-eglstream or just the regular weston from the repos?
sway historically had special support for nvidia's eglstream protocol, but since nvidia now supports GBM, that's not necessary and deprecated - but sway might have special code paths in place, leading to the wrong buffers. Or it's just one of the previously listed bugs

I don't think anybody who has tried a high refresh rate display would every say something like this.

The point is that what you're perceiving are always artifacts that limit the actual FPS way below 60Hz.
This is important to understand and keep in mind, because those artifacts can have various causes and you need to then address those.
One aspect of wayland is to eliminate various indirections that can promote those artifacts.

There've been numerous tests and a lot of self declared elite-level gam0rz with hypervision™ skillz were able to tell apart the refresh rates with all the precision of a coin flip.
Nobody. No. Body. Has ever demonstrated anything beyond 75fps recognition.
If you think you can, talk to some neurologist, get tested - we'll read about you in international news.
Or you fail just as much as everybody else.

Your latest screenshots acutally nicely illustrate how swaywm (the signal generator) and your monitor (the signal receiver) agree on the refresh rate, so when you previously had sway tell you that you were running at 60Hz, you *were* running at 60Hz and just "felt" that it's 144Hz, because you were likely not facing any of those artifacts.
You cannot trust your perception itr. At all.

Hubro · 2023-01-07 14:51:12

After a bit of browsing Sway Reddit, I found a suggestion to try the Vulkan renderer, i.e. "export WLR_RENDERER=vulkan", and it immediately resolved the flickering! So unless any other glaring issues suddenly appear, I seem to be fully up and running.

Nobody. No. Body. Has ever demonstrated anything beyond 75fps recognition.

I have absolutely no idea where you have this from, but it's absolute, completely wrong. To me it sounds like somebody confidently arguing that the ocean is all fresh water, because they read it somewhere. All it does is clearly demonstrate to everybody that you've never been to the ocean.

Just go to a hardware store and try a high refresh rate monitor my guy, they are awesome and you have been missing out.

you *were* running at 60Hz and just "felt" that it's 144Hz

I can promise you with 100% confidence that there is *no* chance I would *ever* mistake 60hz for 144hz even just moving the mouse around It's about as obvious as 420p vs 2160p at close range, maybe even more. There is absolutely no chance.

seth · 2023-01-07 15:14:29

I found a suggestion to try the Vulkan renderer, i.e. "export WLR_RENDERER=vulkan", and it immediately resolved the flickering!

\o/

Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

---

Off topic:
------------
I *have* a high frequency output and I know how it works, what it does and why that has a visible impact in certain scenarios (specifically: it mitigates flaws up the chain) and why that does not mean that you're a bird.
Again: see a neurologist, get tested, stunn the world. I'd be excited to hear about that, but I'll believe it when I see it.

I can promise you with 100% confidence that there is *no* chance I would *ever* mistake 60hz for 144hz even just moving the mouse around smile It's about as obvious as 420p vs 2160p at close range, maybe even more. There is absolutely no chance.

So I have your faith and the system data. Unless you can show why the system data was wrong and/or provide prove of your super-human abilities, I'll go with the system data.

Arch Linux

#1 2023-01-05 11:29:41

[Resolved] Limited to 60 hz, but only on Linux (nvidia, nouveau, sway)

#2 2023-01-05 12:04:25

Re: [Resolved] Limited to 60 hz, but only on Linux (nvidia, nouveau, sway)

#3 2023-01-05 14:32:50

Re: [Resolved] Limited to 60 hz, but only on Linux (nvidia, nouveau, sway)

#4 2023-01-05 14:39:53

Re: [Resolved] Limited to 60 hz, but only on Linux (nvidia, nouveau, sway)

#5 2023-01-05 16:57:30

Re: [Resolved] Limited to 60 hz, but only on Linux (nvidia, nouveau, sway)

#6 2023-01-05 18:10:59

Re: [Resolved] Limited to 60 hz, but only on Linux (nvidia, nouveau, sway)

#7 2023-01-05 19:31:55

Re: [Resolved] Limited to 60 hz, but only on Linux (nvidia, nouveau, sway)

#8 2023-01-05 21:47:29

Re: [Resolved] Limited to 60 hz, but only on Linux (nvidia, nouveau, sway)

#9 2023-01-06 00:03:28

Re: [Resolved] Limited to 60 hz, but only on Linux (nvidia, nouveau, sway)

#10 2023-01-06 00:12:45

Re: [Resolved] Limited to 60 hz, but only on Linux (nvidia, nouveau, sway)

#11 2023-01-06 08:36:45

Re: [Resolved] Limited to 60 hz, but only on Linux (nvidia, nouveau, sway)

#12 2023-01-06 09:57:00

Re: [Resolved] Limited to 60 hz, but only on Linux (nvidia, nouveau, sway)

#13 2023-01-06 10:31:45

Re: [Resolved] Limited to 60 hz, but only on Linux (nvidia, nouveau, sway)

#14 2023-01-06 12:23:53

Re: [Resolved] Limited to 60 hz, but only on Linux (nvidia, nouveau, sway)

#15 2023-01-06 12:45:13

Re: [Resolved] Limited to 60 hz, but only on Linux (nvidia, nouveau, sway)

#16 2023-01-06 16:22:58

Re: [Resolved] Limited to 60 hz, but only on Linux (nvidia, nouveau, sway)

#17 2023-01-07 14:51:12

Re: [Resolved] Limited to 60 hz, but only on Linux (nvidia, nouveau, sway)

#18 2023-01-07 15:14:29

Re: [Resolved] Limited to 60 hz, but only on Linux (nvidia, nouveau, sway)

Board footer