| Summary: | kwin_wayland can't see display mode that gnome-shell (on wayland) can | ||
|---|---|---|---|
| Product: | [Plasma] KScreen | Reporter: | Natalie Klestrup Röijezon <nat> |
| Component: | common | Assignee: | kscreen-bugs-null <kscreen-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | nate, xaver.hugl |
| Priority: | NOR | ||
| Version First Reported In: | 6.5.1 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/kscreen/-/commit/7240cd78359037a31640ccc24ccc7786777de078 | Version Fixed/Implemented In: | |
| Sentry Crash Report: | |||
| Attachments: |
EDID of the affected monitor
screenshot of the dropdown on kscreen 6.5.3 screenshot of the dropdown on kscreen 6.5.3 with 7240cd78359037a31640ccc24ccc7786777de078 cherry-picked drm_info.txt kscreen-doctor.txt |
||
|
Description
Natalie Klestrup Röijezon
2025-11-02 20:19:14 UTC
Created attachment 186430 [details]
EDID of the affected monitor
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kscreen/-/merge_requests/433 kscreen!433 is valuable (and should probably be done for kscreen-doctor too), but AFAIU it's not a solution in itself, unless I'm completely misunderstanding kwin's architecture. (Sorry, this should probably be a comment on the MR, but I don't have a GitLab account.) I filed the issue in kwin since, as I understand it, on Wayland then kwin is responsible for parsing EDID and performing the actual modeset, while kscreen "just" presents the options that it is given by kwin, and sends the requested changes back to it. Before filing the issue I tried to patch https://invent.kde.org/plasma/kwin/-/blob/v6.5.1/src/backends/drm/drm_connector.cpp?ref_type=tags#L312 to add debug logging showing all the modes that it found, and the 119.877Hz refresh rate was already missing at that point. Git commit 7240cd78359037a31640ccc24ccc7786777de078 by Xaver Hugl. Committed on 04/12/2025 at 20:43. Pushed by zamundaaa into branch 'master'. kcm: when necessary, show refresh rates with more digits M +15 -2 kcm/output_model.cpp https://invent.kde.org/plasma/kscreen/-/commit/7240cd78359037a31640ccc24ccc7786777de078 https://invent.kde.org/plasma/kscreen/-/commit/7240cd78359037a31640ccc24ccc7786777de078 doesn't appear to fix it, at least not when cherry-picked on top of kscreen 6.5.3. Attaching screenshots comparing the results of the cherry-pick to regular 6.5.3, the only difference *on my system* appears to be the direction of the dropdown menu. (Which aligns with not being able to configure the correct mode manually either...) Created attachment 187340 [details]
screenshot of the dropdown on kscreen 6.5.3
Created attachment 187341 [details]
screenshot of the dropdown on kscreen 6.5.3 with 7240cd78359037a31640ccc24ccc7786777de078 cherry-picked
Hmm, not sure how that could happen. I tested the specific refresh rates by hacking them into a nested session, and they do appear in kscreen. Please attach the output of drm_info and WAYLAND_DEBUG=1 kscreen-doctor -o Created attachment 187363 [details]
drm_info.txt
Sure, here's the output of drm_info, kscreen-doctor is coming in a moment.
One monitor shows up twice in the logs because it's temporarily connected over both HDMI and DP/MST.
Created attachment 187364 [details]
kscreen-doctor.txt
Okay, so these are the~120Hz modes the kernel says your display supports:
> │ │ │ ├───1920×1080@120.00 driver phsync pvsync
> │ │ │ ├───1920×1080@120.00 driver phsync pvsync 16:9
> │ │ │ ├───1920×1080@119.88 driver phsync pvsync 16:9
and kscreen-doctor correctly reports these modes from the list.
I imagine there might be something weird going on with how the actual refresh rate number is calculated. edid-decode doesn't even show *any* 119.88Hz mode in your display's EDID, it only shows two "120.000000" Hz modes...
The best course of action here is imo though not to find more workarounds, but rather find out what exactly makes these two 120Hz modes different and plumb that into the output configuration system, so that both are shown in the list. I can imagine that one of them has reduced blanking (also requiring slightly reduced bandwidth afaik), while the other doesn't.
|