winft / disman

Qt/C++ display management library
GNU Lesser General Public License v2.1
2 stars 1 forks source link

Chromium based apps can't go past 60FPS on KWinFT 5.20.0 #33

Closed romangg closed 7 months ago

romangg commented 3 years ago

In GitLab by @TheLich132 on Oct 14, 2020, 12:49

After updating KWinFT to version 5.20.0 I have noticed, that chromium based apps that I use (Vivaldi, Discord) are locked at 60FPS.

On version 5.19.1 they were working correctly at my screen refresh rate and downgrading to that previous version has fixed this issue for me.

I am using only one display which is 165Hz and I have Nvidia GPU.

romangg commented 3 years ago

What distro/packages are you using? Would you be able to compile a patch for your installation to test it out?

romangg commented 3 years ago

In GitLab by @TheLich132 on Oct 14, 2020, 14:08

I am using Manjaro on unstable branch. And I am not sure if I would be able to create a patch. Honestly, I don't even know where to begin with that. I have only applied some patches made by other for some software, but never made one myself.

romangg commented 3 years ago

Oh, I actually meant to compile a patch I have here or to be more specific one of the commits in kwinft!47. Maybe you can even directly apply the commit I mean: https://gitlab.com/kwinft/kwinft/-/merge_requests/47/diffs?commit_id=8c3b2a39c211068042c231d897371fc222d45456

The MR also has another commit about adding a synthetic swap event for Nvidia cards. But the synthetic swap event does not yet work correctly.

romangg commented 3 years ago

In GitLab by @TheLich132 on Oct 14, 2020, 14:22

I have tried some combinations with different versions and I have discovered that only kdisplay on version 5.20.0 is making this issue. When kwinft, wrapland and disman are on version 5.20.0 and kdisplay is on version 5.19.0 chromium based apps are working correctly at my refresh rate.

romangg commented 3 years ago

Ah, that's a good info. So the issue is not in the compositor but in how the outputs are configured.

With the problem being observable (i.e. everything at 5.20) what is the output of xrandr? What resolution and refresh rate is shown in KDisplay?

romangg commented 3 years ago

In GitLab by @TheLich132 on Oct 14, 2020, 14:34

xrandr.txt

And KDisplay technically doesn't even load when on version 5.19, when the rest is on 5.20. In the settings Displays tab gives message "Shared library unavailable".

But when KDisplay was on 5.20 it was showing correct values, that is resolution was on Auto and it was 1920x1080, and refresh rate was selected by me on 144Hz, but I also have tried on auto and it didn't fixed the issue.

romangg commented 3 years ago

In GitLab by @TheLich132 on Oct 14, 2020, 14:52

Sorry, I just read your question again and I have realized you were asking about results when the problem is there. Here are the data with KDisplay on version 5.20

KDisplay

xrandr_KDisplay5.20.txt

romangg commented 3 years ago

In GitLab by @TheLich132 on Oct 14, 2020, 14:59

I think I fixed it. I have noticed "primary" was missing in output of xrandr when KDisplay was on 5.20, so I have used xrandr --output DP-4 --primary and then kwin_x11 --replace, then I have restarted browser and vsynctester.com was showing correct values, that is 144FPS!

Is there any way so the "primary" option was setting automatically on boot?

romangg commented 3 years ago

Likely that's a bug in Disman. On X11 with only one output connected it must set this one to being the primary one.

romangg commented 3 years ago

Since the problem likely is in Disman I'm moving the issue to there.

romangg commented 3 years ago

moved from kwinft#84

romangg commented 3 years ago

I can reproduce here with an AMD card and one output that this output is not set as primary.

romangg commented 3 years ago

In GitLab by @TheLich132 on Oct 14, 2020, 15:21

I have made a temporary fix for this issue. I have created script with xrandr setting primary display and I've set in .bashrc to execute this script on startup.

Thanks for your time and help! Looking forward for the fix!

romangg commented 3 years ago

In GitLab by @Kodehawa on Oct 15, 2020, 16:48

@TheLich132 Can you test this patch? 0001-fix-lib-only-apply-primary-output-when-the-config-su.patch (ignore the patch name lol, I rebased both of the commits into one to create a single patch)

It's probably not the actual way to fix it, but I can't reproduce it anymore after testing that patch. If you use arch, use this PKGBUILD: disman-kwinft.tar.gz

Please report back!

P.S.: Remember to disable your script before :p

romangg commented 3 years ago

In GitLab by @TheLich132 on Oct 15, 2020, 16:51

I can test it. Give me a minute and I'll send a report.

romangg commented 3 years ago

In GitLab by @TheLich132 on Oct 15, 2020, 17:04

Installed it with PKGBUILD and xrandr still didn't set primary to my display and Vivaldi is locked at 60FPS.

romangg commented 3 years ago

In GitLab by @Kodehawa on Oct 15, 2020, 17:04

Okie, good to know. Odd that I can't repro it anymore, but that ticks one thing off the list :p

EDIT: I removed the ~/.local/share/disman folder before testing it, could you try that (back it up before) and re-log?

If that works, I'd be interested on the contents of that folder.

romangg commented 3 years ago

In GitLab by @TheLich132 on Oct 15, 2020, 17:07

Don't need to reinstall disman?

romangg commented 3 years ago

In GitLab by @Kodehawa on Oct 15, 2020, 17:08

No need if you already installed it with the PKGBUILD. That folder just has the config files.

Back it up before, in case we need to see the contents!

romangg commented 3 years ago

In GitLab by @TheLich132 on Oct 15, 2020, 17:12

It's working now! Xrandr has set primary option on my display, and Vivaldi now works at higher frame rates!

romangg commented 3 years ago

In GitLab by @Kodehawa on Oct 15, 2020, 17:12

Send your old config to check just in case. I'll submit the PR.

romangg commented 3 years ago

In GitLab by @TheLich132 on Oct 15, 2020, 17:14

So yeah, about that I've made a little mistake and deleted old config too fast... I'm so sorry...

romangg commented 3 years ago

In GitLab by @Kodehawa on Oct 15, 2020, 17:16

No worries. I know what was written to it by mistake before :p

Was just to confirm!

Thanks though. Give me a few hours and I'll submit the PR. Bug fix should be in a point release I guess. Will see if I can put this patch on the PKGBUILD for arch so it gets backported.

Waiting for @romangg to test it aswell, though.

romangg commented 3 years ago

mentioned in commit 475301966fb29d635ec28e1402dece7e64f7cd4f