Summary: | Unable to set correct resolution on external display in Wayland session | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | madcatx |
Component: | wayland-generic | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | inkbottle007, kde, nortexoid, xaver.hugl |
Priority: | NOR | ||
Version: | 5.14.90 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
System settings panel
kscreen-doctor screen connected during boot kscreen-doctor screen connected after login systemsettings doing a very strange computation Another weird spontaneous resolution Global scale managed differently on x11 side and on wayland side. |
Description
madcatx
2019-02-08 14:09:16 UTC
> Maximum external resolution: 2560x1600 https://support.lenovo.com/ua/en/solutions/pd015734 (In reply to Vlad Zagorodniy from comment #1) > > Maximum external resolution: 2560x1600 > > https://support.lenovo.com/ua/en/solutions/pd015734 I don't know what is the Lenovo specification based on but it is clearly wrong. 1) I *am* able to set 3840x2160@30 Hz mode in X11 and it works perfectly fine. 2) It actually *is* possible to get the same mode in Wayland session but it is a major hassle, requires unplugging and replugging of the external display at the right time and even then the results are sort of random. I can only conclude that the specs are based on some artificial limitation of the Intel GPU driver for Windows. The hardware itself can do 4K at 30 Hz, it is just KWin in Wayland mode that is having issues here. Sandy Bridge integrated GPU can support up to about 43 Hz at 3840x2160 (389 MHz pixel clock). I suggest to reassign to KScreen developers, because I doubt it is a KWin issue (unless KWin is responsible for setting up the screen modes). kwin is responsible for setting screen modes. I'm curious why kscreen says we're doing something else. Can you provide the output of the following "WAYLAND_DEBUG=1 kscreen-doctor -o" I can get the debug info once I’m back in the office on Monday. Given that there are many things that can happen when the display mode is supposed to change to "4K on external, disabled internal" - anything from garbled display to correct output - is there a specific state that you’d like to have a debug dump for or should I try to capture them all? Created attachment 117982 [details]
kscreen-doctor screen connected during boot
Created attachment 117983 [details]
kscreen-doctor screen connected after login
Here goes the debugging info. First and more typical situation is when the screen is connected to the laptop during boot. This results in a seriously broken session with the Plasma panel and "correct" wallpaper displayed on the external screen but the mouse cursor trapped inside the laptops internal screen. System settings panel looks as if everything was fine, the display layout and resolutions look okay but the ext. display's actual mode is 1280x720@60 Hz. A somewhat reliable workaround is to plug the external display in after the session starts. This usually lets me move the mouse between screens and change display modes. I attached a kscreen-doctor output for a situation when the displays happen to be configured correctly. I should probably stress that it does not work very reliably and I can still get a broken display even if I plug the display in after the session starts. I wish I could tell you something more useful... I've the same issue with my Lenovo Think Vision P24h, which is a 1440p panel, hooked up via HDMI to my laptop. In wayland, the resolution is always wrong at login, often the screen is corrupt so that there is a black portion at the top and it's impossible to interact with anything because where you click doesn't properly correspond to what's drawn on the screen. If I spend enough time tinkering I can sometimes (but not always) set the correct resolution. This is with the laptop display disabled and only the external enabled. I have a very similar issue. No need to say it renders the use of wayland impossible. Most aspects are almost identical as with the initial reporter: 1- the full contraption works perfectly well with x11. 2- laptop is a thinkpad too, x230 i5-3210m. 3- connected with display port, w/o the docking-station. 4- external monitor is almost identical. 5- Perfectly functioning x11 session: ```json // file: ~/.local/share/kscreen/ccf9312b34a5632b2088ba77ae1deca1 [ { "enabled": true, "id": "b22c96618384c6ee61bc5a283a0d5344", "metadata": { "fullname": "xrandr-unknown", "name": "LVDS-1" }, "mode": { "refresh": 60.018943786621094, "size": { "height": 768, "width": 1366 } }, "pos": { "x": 0, "y": 0 }, "primary": false, "rotation": 1, "scale": 1 }, { "enabled": true, "id": "cd786af8018aba645a80a575407bd2bb", "metadata": { "fullname": "xrandr-Dell Inc.-DELL P2715Q-V48W26BSABQL", "name": "DP-1" }, "mode": { "refresh": 29.980602264404297, "size": { "height": 2160, "width": 3840 } }, "pos": { "x": 1366, "y": 0 }, "primary": true, "rotation": 1, "scale": 1 } ] ``` 6- The sort of weird things observed with wayland session. ```json // file: ~/.local/share/kscreen/ab65ed9ee0630b833fef7a5710f399f1 [ { "enabled": true, "id": "LG Display LVDS-1-unknown", "metadata": { "name": "LG Display LVDS-1-unknown" }, "mode": { "refresh": 60.01900100708008, "size": { "height": 768, "width": 1366 } }, "pos": { "x": 1920, "y": 0 }, "primary": false, "rotation": 1, "scale": 1 }, { "enabled": true, "id": "Dell Inc. DP-1-DELL P2715Q/V48W26BSABQL", "metadata": { "name": "Dell Inc. DP-1-DELL P2715Q/V48W26BSABQL" }, "mode": { "refresh": 60.00400161743164, "size": { "height": 768, "width": 1024 } }, "pos": { "x": 0, "y": 0 }, "primary": true, "rotation": 1, "scale": 0.8984 } ] ``` Look at the strange scale of 0.8984; the interface only allows for .5, .75, 1., 1.25, etc. The reality of the experience is much worse than what the file suggests: The screens are partly overlapping, clicking on maximize window on the laptop screen makes the window like 10% larger that the screen itself. Colors on the 4K screen are, depending on luck, like coded on 2 bits. 7- Like with the initial reporter, with a lot of random tinkering, sometimes it works. Results however vanish as soon as you log-out. And are not reproducible. 8- The same configuration was working with wayland, like 6 month ago. However it took several minutes to reconfigure after each login. So I moved back to x11. 9- Weird quotes from initial poster, which I similarly experienced: "It actually *is* possible to get the same mode in Wayland session but it is a major hassle, requires unplugging and replugging of the external display at the right time and even then the results are sort of random." Even though in my case the steps were different and replugging mostly set the external monitor in a sort of dead grey, with the pointer being able to go on a 20% width vertical band on the right of the screen. "System settings panel looks as if everything was fine, the display layout and resolutions look okay but the ext. display's actual mode is 1280x720@60 Hz." Yes, yes, I even took pictures of the systemsetting window at the time it happened: "every thing is perfect", "perfectly good". Even though the screen looks like a C64's 600x400, even the colors are similar. And many other oddities. 10- At the moment, I have the 4K screen at full resolution 30hz, and the laptop screen at 60hz, with x11. So it is not a problem with the GPU being able to take the load. 11- I almost forgot the system specifications: System is Debian Unstable upgraded yesterday. Last install: `apt install plasma-workspace-wayland` ``` Operating System: Debian GNU/Linux KDE Plasma Version: 5.20.4 KDE Frameworks Version: 5.77.0 Qt Version: 5.15.2 Kernel Version: 5.10.0-1-amd64 OS Type: 64-bit Processors: 4 × Intel® Core™ i5-3210M CPU @ 2.50GHz Memory: 7.5 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 4000 ``` Driver is "modesetting". Thanks a lot. Created attachment 134450 [details]
systemsettings doing a very strange computation
Doing log-out/log-in, I can switch between x11 session working perfectly and Wayland working poorly. Here, just after log-in with Wayland, a screenshot of system settings: we can see that with no intervention from the user whatsoever, it is doing a very strange computation resulting in a supposedly display resolution of 1138x853, which of course doesn't exist. More dreadful though, if I set the resolution from the list of available resolutions, to the default monitor resolution, 3840x2160, it results in a resolution of 4267x2400.
Created attachment 134451 [details] Another weird spontaneous resolution I've been doing some other tests. First I removed "force dpi" in systemsettings / fonts, which was set to 144 dpi. It did freeze the computer and I had to do it again after reboot, but it's eventually been accepted. Then I re-did the switch between x11 and wayland, and it resulted in a spontaneous resolution: see attached file. The actual resolution is not at all like systemsettings say it is. I don't know what it really is but it's average to low. What I did then is set the scale to 100%, and the output was a little better, but no 4K for sure. Then I powered down the external monitor and powered it back on again and it did like https://bugs.kde.org/show_bug.cgi?id=393649. Then the whole PC froze and I had to turn the computer off using the power button. Note: the weird resolution is 3840x2160 in the list, with a scale factor of 75%, resulting in a display resolution of 5120x2880, at 30Hz. (That is a hell of a monitor!) Created attachment 134476 [details]
Global scale managed differently on x11 side and on wayland side.
In the systemsettings window, the monitor resolution is reported in two different places. Namely on the thumbnail representation of the monitor, and on the selected item in the drop-down list below. In the x11 case those two numbers are equal, even though as you can see in the attached screenshot, there is a scale factor applied. In the wayland case, the two resolutions are linked to one another by the scale factor.
I've been told that the external monitor is viewed through the driver, and considering the specifications I've already given, ultimately by the kernel. Also, that I could use the command `drm_info` to see how the kernel is seeing the monitor. (freenode/#wayland; https://github.com/ascent12/drm_info.) ``` drm_info -j|jq '[.["/dev/dri/card0"]["connectors"][3]["modes"][0]["hdisplay","vdisplay"],.["/dev/dri/card0"]["crtcs"][1]["mode"]["hdisplay","vdisplay"]]' ``` Always return: ``` [ 3840, 2160, 3840, 2160 ] ``` When invoked from kwin-x11 session. So does it in a `tty`. So does it when invoked after ``` systemctl isolate multi-user.target ``` Also this output is resilient to the turning off and on of the monitor. Also, at boot time, as soon as the console is showing the disk is mounted, the line starting by `sda1`, the laptop display is mirrored on the upper-left part of external monitor, at full 4K resolution, each and every single time. Prior to that, if the laptop lid is opened the display is only working on the laptop display with a 600x400 sort of style. However if the lid is closed, the same data are displayed on the external monitor, old style 600x400 too. Then there is a switch to full 4K resolution. That switch, as described, happens very early in the boot process. And it is always like that. I've also been told to look at the EDID. ``` edid-decode /sys/class/drm/card0-DP-1/edid ``` returns data just as expected for that monitor. Below the data themselves: ``` $ xxd -ps /sys/class/drm/card0-DP-1/edid 00ffffffffffff0010acbd404c514241301a0104a53c22783aee95a3544c 99260f5054a54b00d100d1c0b300a94081808100714f01014dd000a0f070 3e803020350055502100001a000000ff0056343857323642534142514c0a 000000fc0044454c4c205032373135510a20000000fd001d4b1f8c36010a 202020202020015702031df150101f200514041312110302161507060123 091f0783010000a36600a0f0701f803020350055502100001a565e00a0a0 a029503020350055502100001a023a801871382d40582c45005550210000 1e011d007251d01e206e28550055502100001e0000000000000000000000 00000000000000000000000000000013 ``` In contrast, with kwin-wayland, the output of `drm_info` is almost always wrong. So, the way I understand it: the upper layers, viz. kwin-wayland, are interfering with the lower layer, viz. the linux-kernel, modesetting, causing them to return erroneous values. That is a convoluted reasoning, and I, most probably, didn't understand a thing of what I've been told. All that is nevertheless very intriguing. I was thinking that I should see how all that was behaving with GNOME Wayland. I haven't used Gnome for quite a few years now, so it took me a bit of time. ``` apt install gnome-session --no-install-recommends ``` Log-in with GNOME Wayland: screen resolution => Perfect in every aspects. Log-in with PLASMA Wayland: broken: external monitor 1280x720, with wrong color depth, one in two times in black/white. built-in laptop monitor, displaying "over/underscan like". Look, once I've selected the changes-to-be in system-settings, it isn't even possible to click accept, because in fullscreen-mode the window is really larger than the physical display, with the mouse limited to moving inside physical screen boundaries. But I can do accept though, through the dialog pop-up when closing the window. This result in no change at all though. I repeated that a few times, it was perfectly reproducible: GNOME Wayland, perfect. PLASMA Wayland, broken in every aspects. Note: The resolution used by sddm (external monitor), is 1280x720. And the monitor buttons are showing this settings at this moment. When using GNOME Wayland session, resolution is switched to 3840x2160, as it should. With PLASMA Wayland, it remains 1280x720. What is very surprising, is that PLASMA Wayland is unhinging the readings of `drm_info`, which seems quite a feat, since it's supposed to be the kernel doing that. Could you test with KWin master? This sounds a bit like what I fixed with https://invent.kde.org/plasma/kwin/-/merge_requests/538 (In reply to Zamundaaa from comment #16) > Could you test with KWin master? This sounds a bit like what I fixed with > https://invent.kde.org/plasma/kwin/-/merge_requests/538 I've upgraded to KWin 4:5.21.4-1 from Debian/experimental, which I've been told is the only version available from Debian to integrate the commit you referred to, like so: `apt install -t experimental $(dpkg -l | grep 5.20.5 | awk '/^ii/ {print $2}')` Without delving too deeply into it, it doesn't seem the issues I met are showing anymore. Querying `drm_info` is now returning the correct screen resolution. I did a few reboot to verify. The only thing I noticed is that sometimes the color depth of the wallpaper is initially wrong. Just clicking on the wallpaper fixes the colors. As if the wallpaper is the first image displayed, and when it happens, there is still a glitch, and the color depth is wrong. Could this bug be marked as fixed? |