Bug 404092 - Unable to set correct resolution on external display in Wayland session
Summary: Unable to set correct resolution on external display in Wayland session
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: wayland-generic (show other bugs)
Version: 5.14.90
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-02-08 14:09 UTC by madcatx
Modified: 2021-07-27 02:16 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
System settings panel (111.50 KB, image/png)
2019-02-08 14:09 UTC, madcatx
Details
kscreen-doctor screen connected during boot (24.75 KB, text/plain)
2019-02-11 14:17 UTC, madcatx
Details
kscreen-doctor screen connected after login (23.77 KB, text/plain)
2019-02-11 14:18 UTC, madcatx
Details
systemsettings doing a very strange computation (70.33 KB, image/png)
2021-01-02 04:52 UTC, Chris
Details
Another weird spontaneous resolution (2.32 MB, image/jpeg)
2021-01-02 05:45 UTC, Chris
Details
Global scale managed differently on x11 side and on wayland side. (95.77 KB, image/png)
2021-01-02 15:57 UTC, Chris
Details

Note You need to log in before you can comment on or make changes to this bug.
Description madcatx 2019-02-08 14:09:16 UTC
Created attachment 117925 [details]
System settings panel

I gave KDE Wayland another go with 5.15 beta and I am experiencing this issue with my external 4K display. No matter what I do it is impossible to set the 4K resolution. Sometimes I get a corrupted display that does not respond to user input, other times the display is stuck at lower resolution despite the system settings panel and KScreen config file claiming otherwise.

At the time of writing of this report my looks as follows (see the attachment). Respective KScreen config file contains this:
[
    {
        "enabled": false,
        "id": "B140RW02 V1 LVDS-1-unknown",
        "metadata": {
            "name": "B140RW02 V1 LVDS-1-unknown"
        },
        "pos": {
            "x": 0,
            "y": 1260
        },
        "primary": false,
        "rotation": 1,
        "scale": 1
    },
    {
        "enabled": true,
        "id": "DEL DP-2-DELL P2715Q/V48W275A378L",
        "metadata": {
            "name": "DEL DP-2-DELL P2715Q/V48W275A378L"
        },
        "mode": {
            "refresh": 29.981000900268555,
            "size": {
                "height": 2160,
                "width": 3840
            }
        },
        "pos": {
            "x": 0,
            "y": 0
        },
        "primary": true,
        "rotation": 1,
        "scale": 1
    }
]

Despite this the display's actual mode is 1280x720@60 Hz. The display is a Dell P2715Q panel connected via DisplayPort on a docking station. The laptop is a Lenovo T420 with a Sandy Bridge GPU. I am aware of the SNB GPU hardware limitation that does not allow it to go higher than 30 Hz at 3840x2160 resolution but I have been using 3840x2160@30 Hz for a long time under X11 and it works perfectly fine there.

Relevant software version info:
KWin 5.14.90
Kernel 4.20.6
Mesa 18.3.3
Everything is exactly as packaged by Arch Linux except for KWin which has this (https://phabricator.kde.org/D18307) additional patch applied.


What can I do to help track this down?
Comment 1 Vlad Zahorodnii 2019-02-08 15:05:06 UTC
> Maximum external resolution: 2560x1600

https://support.lenovo.com/ua/en/solutions/pd015734
Comment 2 madcatx 2019-02-08 15:27:49 UTC
(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.
Comment 3 Christoph Feck 2019-02-08 18:01:25 UTC
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).
Comment 4 David Edmundson 2019-02-09 11:54:40 UTC
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"
Comment 5 madcatx 2019-02-09 14:24:38 UTC
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?
Comment 6 madcatx 2019-02-11 14:17:27 UTC
Created attachment 117982 [details]
kscreen-doctor screen connected during boot
Comment 7 madcatx 2019-02-11 14:18:08 UTC
Created attachment 117983 [details]
kscreen-doctor screen connected after login
Comment 8 madcatx 2019-02-11 14:27:47 UTC
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...
Comment 9 Michael D 2019-03-28 08:19:22 UTC
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.
Comment 10 Chris 2021-01-02 01:36:29 UTC
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.
Comment 11 Chris 2021-01-02 04:52:25 UTC
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.
Comment 12 Chris 2021-01-02 05:45:22 UTC
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!)
Comment 13 Chris 2021-01-02 15:57:39 UTC
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.
Comment 14 Chris 2021-01-05 02:01:25 UTC
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.
Comment 15 Chris 2021-01-14 18:17:44 UTC
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.
Comment 16 Zamundaaa 2021-04-10 15:53:26 UTC
Could you test with KWin master? This sounds a bit like what I fixed with https://invent.kde.org/plasma/kwin/-/merge_requests/538
Comment 17 Chris 2021-04-30 22:41:59 UTC
(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.
Comment 18 Chris 2021-07-16 19:36:33 UTC
Could this bug be marked as fixed?