How did you determine it's set to 48Hz?
Please attach the output of
> kscreen-doctor -o
and
> drm_info
while the display is set to 60Hz

(In reply to Zamundaaa from comment #1)
> How did you determine it's set to 48Hz?
> Please attach the output of
> > kscreen-doctor -o
> and
> > drm_info
> while the display is set to 60Hz

I determined it with opening an opengl application with mangohud and observing the fps, moving the mouse cursor around showed even spacing which made it clear it was a denominator of 144, 48 in this case
the output of kscreen-doctor -o is
```
        enabled
        connected
        priority 1
        Panel
        Modes:  1:1920x1080@144!  2:1920x1080@120  3:1680x1050@144  4:1280x1024@144  5:1440x900@144  6:1280x800@144  7:1280x720@144  8:1024x768@144  9:800x600@144  10:640x480@144  11:1280x1024@60  12:1024x768@60  13:1280x800@60  14:1920x1080@60*  15:1600x900@60  16:1368x768@60  17:1280x720@60 
        Geometry: 0,0 1920x1080
        Scale: 1
        Rotation: 1
        Overscan: 0
        Vrr: incapable
        RgbRange: unknown
        HDR: incapable
        Wide Color Gamut: incapable
        ICC profile: none
        Color profile source: sRGB
        Brightness control: supported, set to 0%
``` 
and the output of drm_info will be provided in a text file in attachments

weird thing is that hyprland and KDE X11 work properly and currently i am using an edid hack to implement 120hz and that works out fine but the 60hz option is still broken in KDE wayland, maybe kde is trying to implement its own 60hz (which overrides the edid too) and fails at that

Created attachment 177333 [details]
output of drm_info

> moving the mouse cursor around showed even spacing
That happens with every refresh rate.

To make actually sure, please install and run weston-presentation-shm, let it run for a second and then attach its output here

> maybe kde is trying to implement its own 60hz (which overrides the edid too) and fails at that
Yes, the 60Hz mode is generated by libxcvt. I don't think there's anything we could be doing wrong here though, the mode is actually 60Hz according to drm_info. Maybe the driver is doing some weird stuff to make the mode work.

> Yes, the 60Hz mode is generated by libxcvt. I don't think there's anything
> we could be doing wrong here though, the mode is actually 60Hz according to
> drm_info. Maybe the driver is doing some weird stuff to make the mode work.
hyprland just grabs the 60hz mode from the edid without question, maybe kde could do the same
and this is also why we need kscreen to implement custom modelines

There is no 60Hz mode from the kernel...

(In reply to Zamundaaa from comment #6)
> There is no 60Hz mode from the kernel...

i never said anything about the kernel, i said the EDID!!! EDID is something provided by the display firmware and contains display data and more importantly modelines for use for the display.

The kernel parses the EDID to populate the list. Hyprland most definitely does not do this by itself.

hmm, I wonder if this could be triggered by
> "scaling mode": enum {None, Full, Center, Full aspect} = Full aspect
which afaik other compositors don't set.
It's supposed to only be about scaling non-native modes and not about refresh rates, but perhaps the driver implementation is different.

Could you test a patch (for KWin 6.2) to check if it's the case?

.

(In reply to Zamundaaa from comment #9)
> Could you test a patch (for KWin 6.2) to check if it's the case?

how would i go about it?

🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!

Created attachment 178148 [details]
pkgbuild for the patch

Created attachment 178149 [details]
patch

To build it,
git clone https://gitlab.archlinux.org/archlinux/packaging/packages/kwin.git
replace the PKGBUILD with the one I attached, and put the patch in the same folder.
makepkg -si
will build and install the package, and whenever you update kwin from your system, the change will be reverted.

tested the patch and it works and i get 60fps compositing so there is 1 problem fixed, but there is another problem, it still generates its own modeline with gtf presumably for 1920x1080@60 instead of grabbing from the edid firmware so the whole screen freaks out because my display is driven in a weird way

i reckon whatever logic you disabled that scaled the FPS is needed for proper function of these types of wacky displays
how about instead if removing it we modify it so it doesn't just hold a certain amount of frames per compositing frame (like how it holds 3 frames each time to fake 48hz) but dynamically times the frames to fake 60hz (like 2 2 3 2 3, 2 2 3 2 3 whch comes from taking 2.4 steps and rounding down)

This bug is happedme, I will to try the PKG fix.

(In reply to Zamundaaa from comment #13)
> Created attachment 178148 [details]
> pkgbuild for the patch

Well, I compiled this path but with kwin 6.3 and didn't not work. :/

(In reply to Mahbod Karamoozian from comment #15)
> tested the patch and it works and i get 60fps compositing so there is 1
> problem fixed, but there is another problem, it still generates its own
> modeline with gtf presumably for 1920x1080@60 instead of grabbing from the
> edid firmware so the whole screen freaks out because my display is driven in
> a weird way
Well, that can't really be fixed. If the screen can't work at 60Hz, then it just can't.

Maybe different options for generating the mode could make it work, which bug 456697 tracks.

(In reply to Mahbod Karamoozian from comment #16)
> i reckon whatever logic you disabled that scaled the FPS is needed for
> proper function of these types of wacky displays
There is no such logic in KWin. We just tell the driver to drive the screen with the given mode, and it does whatever.

> how about instead if removing it we modify it so it doesn't just hold a
> certain amount of frames per compositing frame (like how it holds 3 frames
> each time to fake 48hz) but dynamically times the frames to fake 60hz (like
> 2 2 3 2 3, 2 2 3 2 3 whch comes from taking 2.4 steps and rounding down)
A stuttering logic like that is not something I'm interested in supporting, sorry. It would make a lot of things very complicated.

*** This bug has been marked as a duplicate of bug 456697 ***

(In reply to Zamundaaa from comment #19)
> (In reply to Mahbod Karamoozian from comment #15)
> There is no such logic in KWin. We just tell the driver to drive the screen
> with the given mode, and it does whatever.

I would like to object to that, there IS such logic and i have proof that it's being done like that
If you switch ttys and the modeline changes you will see a brief flash on the screen so the display can adjust itself or else (if an in tree driver is used with the kms hook) it will switch instantaneously
so i put hyprland in 1080p@144hz mode and kwin in the supposed 60hz-but-actually-48hz mode and when switching them there seems to be no flashing indicating that it is using the 144hz modeline but fakes 60hz and fails because there isn't a denominator of 144 equal to 60 so by making this logic a little smarter you could achieve 60hz on such wacky screens

If I tell you that there is no such logic, then there isn't. What the driver is doing under the hood is something we have no control over.

*** This bug has been marked as a duplicate of bug 456697 ***

In a different bug report, I managed to narrow this down more. With scaling mode set, amdgpu just doesn't switch the refresh rate at all, while claiming that the mode was successfully changed. That bug was already tracked here (and I forgot about it): https://gitlab.freedesktop.org/drm/amd/-/issues/2501

so it seems that this was a completely wrong place to look for this mess and it's amdgpu itself
weird but it seems that this page can now be crossed off

@zamundaaa a question, the patch created for kwin 6.2 will work on 6.3 and upstream? I have the same initial problem, wayland stuck me at 48FPS when my screen is set to 60hz.

*** Bug 500096 has been marked as a duplicate of this bug. ***

No, the patch was just for testing. We won't disable this option upstream, as it's needed to make the mode work at all on some laptops.