Bug 445253

Summary: Unable to set maximum resolution on HiDPI after suspend, goes back to lower resolution (Wayland, after suspend, persists after several reboots)
Product: [Plasma] KScreen Reporter: phrxmd <philipp.reichmuth>
Component: commonAssignee: kscreen-bugs-null <kscreen-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: a.key, nate, xaver.hugl
Priority: NOR Keywords: wayland
Version: 5.23.2   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: drm_info output for 3840x2160
drm_info output when the screen is stuck at 2560x1440
xrandr output with external monitors enabled
drm_info output with external monitors enabled
kscreen screenshot

Description phrxmd 2021-11-10 08:00:02 UTC
SUMMARY
I have a 3840x2160 screen attached to a Thunderbolt dock. 
However, since waking up from suspend this morning, KWin fails to set any more than 2560x1440, even though I see a 3840x2160 option in System settings. I can select 3840x2160 and apply the setting, and System settings will show that the resolution is 3840x2160, but the monitor actually goes to 2560x1440 as seen from the monitor's HUD. The next time I open the Display settings KCM, it will  again show the monitor at 2560x1440.

KWin has supported 3840x2160 until this morning, and I made no changes to the configuration. The laptop was on suspend. I would be happy if I had a way to get to yesterday's state before suspending the notebook to the night. But now it will not go to this resolution even after several reboots, unplugging and replugging the Thunderbolt dock, and power cycling the dock and monitor.

STEPS TO REPRODUCE
1. Boot up system
2. Log into KDE Wayland session (the monitor HUD shows it correctly running at 3840x2160 in SDDM)
3. KWin comes up with the monitor in 2560x1440. 
4. Open System Settings, set resolution to 3840x2160, click Apply.

OBSERVED RESULT
The monitor goes to 2560x1440, even though the Display settings KCM shows it at 3840x2160.
If I open a different KCM in System settings and then go back to Display settings, the monitor is shown at 2560x1440 again.

EXPECTED RESULT
The monitor should go to 3840x2160.

SOFTWARE/OS VERSIONS
Operating System: openSUSE Tumbleweed 20211107
KDE Plasma Version: 5.23.2
KDE Frameworks Version: 5.87.0
Qt Version: 5.15.2
Kernel Version: 5.14.14-1-default (64-bit)
Graphics Platform: Wayland

ADDITIONAL INFORMATION
Upon unplugging and replugging the Thunderbolt dock, I once got the crash reported under #445249.
Comment 1 phrxmd 2021-11-10 10:54:08 UTC
I now get the crash reported under bug 445249 reproducibly whenever I unplug and replug my dock.
Comment 2 phrxmd 2021-11-13 15:30:00 UTC
After some time the issue went away, so I'm setting this to WORKSFORME for the time being. Will report in more detail if/when it comes back.
Comment 3 phrxmd 2021-11-18 09:19:02 UTC
Similar scaling issues were reported in bug 445680.
Comment 4 phrxmd 2021-12-06 09:57:22 UTC
It's back. Last thing I did was to put the laptop to sleep by closing the lid. 

Before suspend, the external screen was set to 3840x2160.
Upon wakeup, it came up at 2560x1440 and nothing I I would change in the display settings KCM would actually set the monitor to anything else but 2560x1440. It's as if KWin refused to change the physical resolution. I could change scaling settings and they would get applied to 2560x1440, no matter what resolution I actually selected. Windows came up as if the size was still 3840x2160 (i.e. with the outer controls outside the screen margins).

I managed to restore it to normal was to unplug the monitor's power cable. This led to a crash in Plasmashell (bug 438839) and Akonadi (bug 445249), but when Plasmashell came up again on the external monitor it was at 3840x2160. 

System information:
Operating System: openSUSE Tumbleweed 20211202
KDE Plasma Version: 5.23.4
KDE Frameworks Version: 5.88.0
Qt Version: 5.15.2
Kernel Version: 5.15.5-1-default (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-8550U CPU @ 1.80GHz
Memory: 15.5 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 620
Comment 5 Zamundaaa 2021-12-07 09:43:02 UTC
Please attach the output of drm_info, once while everything is working normally, and once while the issue is visible.
Comment 6 phrxmd 2021-12-07 10:29:24 UTC
Where do I find this command? Currently I get the following:

# drm_info
Wenn 'drm_info' kein Tippfehler ist, können Sie command-not-found benutzen, um das Paket zu finden, das den Befehl enthält, z. B.:
    cnf drm_info
# cnf drm_info
 drm_info: Befehl nicht gefunden
Comment 7 Zamundaaa 2021-12-07 11:52:43 UTC
You can compile it from source if OpenSuse doesn't have it: https://github.com/ascent12/drm_info
Comment 8 phrxmd 2021-12-07 16:30:24 UTC
Created attachment 144308 [details]
drm_info output for 3840x2160

Attached is the drm_info output when things are working fine at 3840x2160. Will wait for the problem to occur again and post again
Comment 9 phrxmd 2021-12-21 21:07:14 UTC
Created attachment 144765 [details]
drm_info output when the screen is stuck at 2560x1440

It's happened again, now my external screen is stuck at 2560x1440. 
I can set it to a larger resolution, but the physical resolution of the screen does not change - there seems to be a larger screen buffer of which I see only the bottom left corner. 

What I did was to unplug an USB device (a Brother QL-700 label printer, if it matters) from one of the USB ports on my laptop. At that moment the screen went black. In order to bring it back up again, I deactivated it in System Settings (resulting in a Plasmashell crash). When I reactivated it, it came up at 2560x1440 and has been stuck at the resolution since.

Attached is the drm_info output for the case when it's stuck at 2560x1440.
Comment 10 phrxmd 2021-12-21 21:11:00 UTC
Addendum: 2560x1440 (the resolution the external screen is stuck at) is also the physical resolution of the internal screen of my laptop, I'm not sure if that matters.
Comment 11 a.key 2022-01-12 09:15:47 UTC
Same problem here.
I have a ThinkPad X1 Carbon connected to a Thundrebolt 3 dock to which there are 2 Apple Cinema HD screens connected:
Configuring the screens in extended mode sets up the external monitors with incorrect resolutions and everything looks really bad. You cannot click on anything because the display is set to incorrect resolution but the the Plasma thinks it's correct.
Attached screenshots from kscreen and drm_info when both external monitors are enabled but with incorrect resolution.

$ kscreen-doctor -o
Output: 1 unknown eDP-1-unknown enabled connected  Panel Modes: 0:1920x1080@48 1:1920x1080@60*! Geometry: 0,0 1920x1080 Scale: 1 Rotation: 1 Overscan: 0 Vrr: incapable RgbRange: Automatic 
Output: 2 Apple Computer Inc Cinema HD
/CY73902UXMP enabled connected  Unknown Modes: 0:1280x800@60 1:2560x1600@60*! Geometry: 1920,0 2560x1600 Scale: 1 Rotation: 1 Overscan: 0 Vrr: incapable RgbRange: Automatic 
Output: 3 Apple Computer Inc Cinema HD
/CY7231DVXMP enabled connected primary Unknown Modes: 0:1280x800@60 1:2560x1600@60*! Geometry: 4480,0 2560x1600 Scale: 1 Rotation: 1 Overscan: 0 Vrr: incapable RgbRange: Automatic primary
Comment 12 a.key 2022-01-12 09:17:49 UTC
Created attachment 145354 [details]
xrandr output with external monitors enabled

xrandr "thinks" the resolution is set to 2560x1600 but in reality it's 1280x800.
Comment 13 a.key 2022-01-12 09:20:55 UTC
Created attachment 145355 [details]
drm_info output with external monitors enabled
Comment 14 a.key 2022-01-12 09:22:39 UTC
Created attachment 145356 [details]
kscreen screenshot
Comment 15 a.key 2022-01-12 09:55:35 UTC
It maybe useful to know that:
The problem of incorrect resolution doesn't appear when:
Laptop is rebooted without the docking station plugged in. In this situation I reboot the laptop, go through the SDDM login and get straight to Plasma Wayland session. Then I plug my docking station and the monitors light up with correct resolution.
Please note that plasma completely crashes when I then unplug the docking station and plug it back in. It simply goes black, crashes and goes back to SDDM.

It may also be useful that my SDDM as well as TTY get incorrect resolution as well. This means that if I boot the laptop (Fedora 35) to runlevel 3 with not X, the laptop built in display will be in it's correct resolution but the two external ones will be at the incorrect ones. When changing runlevel to X where sddm would get started, SDDM also shows incorrect resolution for external displays and depending how well the SDDM theme can handle multiple screen resolutions the login screen can look better or worse. This is of lesser importance.
Logging in to Plasma X11 session is working OK. All screens get their correct resolution but logging into Plasma Wayland is bad as described previously.
Comment 16 Zamundaaa 2022-01-13 16:50:34 UTC
If the tty gets the wrong resolution as well then it could be a deeper driver-level issue; I can't see anything too unusual in the drm_info outputs. The wayland session log may reveal more information about what's going on (cause the bug and attach the output of "grep kwin_wayland_drm ~/.local/share/sddm/wayland-session.log" here afterwards)

Changing modes on the fly in the Wayland session had some caveats with bandwidth constraints though, which often come into play on Intel hardware. With 5.24 those should be fixed, so you might want to test a usb boot of the beta, too.
Comment 17 phrxmd 2022-01-15 07:26:39 UTC
(In reply to Zamundaaa from comment #16)
> If the tty gets the wrong resolution as well then it could be a deeper
> driver-level issue; I can't see anything too unusual in the drm_info
> outputs. The wayland session log may reveal more information about what's
> going on (cause the bug and attach the output of "grep kwin_wayland_drm
> ~/.local/share/sddm/wayland-session.log" here afterwards)

It's very unspectacular, two permission denied errors on setting the cursor:
❯ grep kwin_wayland_drm ~/.local/share/sddm/wayland-session.log
kwin_wayland_drm: Could not set cursor: Keine Berechtigung
kwin_wayland_drm: Could not set cursor: Keine Berechtigung

I'm seeing the wrong resolution in the TTY as well. If it's a driver issue, what would be the place to report it?

I will test with 5.24 /either the beta or the real thing when it comes out/ and if it persists, will report back.
Comment 18 phrxmd 2022-02-11 19:47:49 UTC
I can't reproduce it on 5.24.0 anymore. Closing this for now, will reopen if it happens again.