Bug 448177 - Thunderbolt dock 4k screen flickering/going black for a second after "changing many pixels"
Summary: Thunderbolt dock 4k screen flickering/going black for a second after "changin...
Status: RESOLVED UPSTREAM
Alias: None
Product: kwin
Classification: Unclassified
Component: general (show other bugs)
Version: 5.23.5
Platform: Gentoo Packages Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-01-09 19:04 UTC by Lorenz/Qrly
Modified: 2022-01-24 12:17 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.24


Attachments
Wird pixel rendering 4k@60Hz HDMI (327.85 KB, image/jpeg)
2022-01-09 19:04 UTC, Lorenz/Qrly
Details
drm_info_before_starting_plasma (265.68 KB, application/octet-stream)
2022-01-13 17:20 UTC, Lorenz/Qrly
Details
drm_info_when_plasma_started (266.88 KB, application/octet-stream)
2022-01-13 17:21 UTC, Lorenz/Qrly
Details
drm_info_while_bug (266.90 KB, application/octet-stream)
2022-01-13 17:21 UTC, Lorenz/Qrly
Details
drm_info_after_bug (266.90 KB, application/octet-stream)
2022-01-13 17:21 UTC, Lorenz/Qrly
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lorenz/Qrly 2022-01-09 19:04:36 UTC
Created attachment 145279 [details]
Wird pixel rendering 4k@60Hz HDMI

Hello,

first, here is a short video showing the issue: https://www.youtube.com/watch?v=c2sVZwb5mg0.

Basicly, I've got a 4k monitor connected on my Thinkpad thunderbolt 3 gen 2 Workstation dock:
Monitor: https://www.lg.com/us/monitors/lg-32UK550-B-4k-uhd-led-monitor
Dock: https://support.lenovo.com/rs/en/solutions/pd500333-thinkpad-thunderbolt-3-workstation-dock-gen-2-overview-and-service-parts

The screen goes black after "changing to many pixels", for example while fullscreen web browsing, playing a fullscreen video, etc. This only happens while the monitor is running at 4k. 2k and blow is not an Issue.

This isn't a fix (because I tried it):
- Disabling all other monitors 
- Only plugging the monitor Cable into the Dock
- Using another Thunderbolt dock
- Using other 4k Screens
- Using diffrent cables that I know work
- Using Manjaro KDE, KDE neon, endeavouros KDE, all showing the same behavior

How do I know that this is a Plasma specific issue?
Because the screen is working in Xfce and swaywm at 4k@60Hz. 
It could also not be one, because same problem like in kde also exsists in dwm and awesomewm.

Why do I use a docking station?
Because my Laptop (You can find my hardware specs below) only has 1.4b, which after the official hdmi spec only supports 4k@30Hz (" 3840×2160 at 24, 25, and 30 Hz", https://www.hdmi.org/spec/hdmi1_4b) while my Displayport version officially supports 4k@60Hz. My Laptop doesn't have a Displayport Port.

How do I know that this is a bug only appering when using a docking station?
I tried two diffrent docking stations, both showing the same result. (Maby I will have the chance to test other laptops in the next days). While my HDMI version doesn't officially supports 4k@60Hz, whith my HDMI port on my Laptop I am able to achive 4k@60Hz, but with wird rendering(You can find a image showing how the rendering looks in the attachments), thats why I need displayport. 
But, 4k@60Hz on HDMI works without the wird black screen that you get when "changing to many pixels".
Comment 1 Lorenz/Qrly 2022-01-09 19:08:21 UTC
I accidently pressed Enter, submitting the issue, anyways could you give me some ways to debug this problem? I have a lot of time, so please ask questions if you have some or make suggestions how I could fix the problem. 
Thanks very much for your support!
Comment 2 Lorenz/Qrly 2022-01-09 19:10:50 UTC
I fucked up with theming in the Video, but I know and I already fixed it so this is not a issue
Comment 3 Lorenz/Qrly 2022-01-09 19:12:54 UTC
Operating System: Gentoo Linux 2.8
KDE Plasma Version: 5.23.5
KDE Frameworks Version: 5.89.0
Qt Version: 5.15.2
Kernel Version: 5.15.10-gentoo-x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 8 × 11th Gen Intel® Core™ i7-1165G7 @ 2.80GHz
Memory: 15.3 GiB of RAM
Graphics Processor: Mesa Intel® Xe Graphics

Laptop: Thinkpad E15 G2 (Intel)
Comment 4 Lorenz/Qrly 2022-01-09 19:13:56 UTC
The issue is also not specific to Xorg or Wayland.
Comment 5 Lorenz/Qrly 2022-01-09 19:14:49 UTC
Means: The problem exsists in Xorg and Wayland
Comment 6 Zamundaaa 2022-01-13 16:17:42 UTC
Can you attach the output of drm_info, once for when the display is still working and once when it just stopped working?
Comment 7 Lorenz/Qrly 2022-01-13 16:23:47 UTC
Sorry, what do you mean by drm_info? A command? How can I install it or where do I find it?
Comment 8 Zamundaaa 2022-01-13 16:33:15 UTC
Yes, it's a command. If your distro doesn't provide it you can compile it from https://github.com/ascent12/drm_info
Comment 9 Lorenz/Qrly 2022-01-13 17:20:26 UTC
Created attachment 145413 [details]
drm_info_before_starting_plasma
Comment 10 Lorenz/Qrly 2022-01-13 17:21:03 UTC
Created attachment 145414 [details]
drm_info_when_plasma_started
Comment 11 Lorenz/Qrly 2022-01-13 17:21:35 UTC
Created attachment 145415 [details]
drm_info_while_bug
Comment 12 Lorenz/Qrly 2022-01-13 17:21:56 UTC
Created attachment 145416 [details]
drm_info_after_bug
Comment 13 Lorenz/Qrly 2022-01-13 17:22:12 UTC
Ok, I did it. The files are in the attachments
Comment 14 Zamundaaa 2022-01-14 09:17:31 UTC
I can't explain why it would be working on xfce Xorg and not Plasma but Sway is using the link-status property (that your hardware has), which is supposed to prevent some black screen situations when the bandwidth requirements of a connector change too much. Sounds like an exact match.
Comment 15 Bug Janitor Service 2022-01-14 09:23:45 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1878
Comment 16 Zamundaaa 2022-01-14 12:03:00 UTC
Git commit 802d855785d9cecca8c674a0aa61bba44293cbbb by Xaver Hugl.
Committed on 14/01/2022 at 10:31.
Pushed by zamundaaa into branch 'master'.

backends/drm: support link-status

Userspace is expected to do a modeset and set link-status to good again,
if link-status gets bad. This is needed to prevent some black screen situations.

M  +12   -0    src/backends/drm/drm_object_connector.cpp
M  +6    -0    src/backends/drm/drm_object_connector.h
M  +4    -0    src/backends/drm/drm_pipeline.cpp

https://invent.kde.org/plasma/kwin/commit/802d855785d9cecca8c674a0aa61bba44293cbbb
Comment 17 Zamundaaa 2022-01-14 12:06:21 UTC
Git commit 04b51655a16b46be1f77d1539aa450b36e018ed1 by Xaver Hugl.
Committed on 14/01/2022 at 12:06.
Pushed by zamundaaa into branch 'Plasma/5.24'.

backends/drm: support link-status

Userspace is expected to do a modeset and set link-status to good again,
if link-status gets bad. This is needed to prevent some black screen situations.


(cherry picked from commit 802d855785d9cecca8c674a0aa61bba44293cbbb)

M  +12   -0    src/backends/drm/drm_object_connector.cpp
M  +6    -0    src/backends/drm/drm_object_connector.h
M  +4    -0    src/backends/drm/drm_pipeline.cpp

https://invent.kde.org/plasma/kwin/commit/04b51655a16b46be1f77d1539aa450b36e018ed1
Comment 18 Zamundaaa 2022-01-14 12:07:47 UTC
I'm relatively sure that this will fix it but if the issue should still happen with that commit (or 5.24.0) do please re-open the bug report
Comment 19 Lorenz/Qrly 2022-01-14 13:38:04 UTC
Thank you very much!!!
I hope this works, when kde 5.24 was released. 
Sadly, I cannot test if that works, because I cannot apply the patch to kwin-5.23.5 (There was a lot going on, for example moving all the stuff to the backend dir, but also the file was changed a lot).

How can I test if this works? Gentoo doesn't provide a nightly kwin package, can I download the source from gitlab and compile it? 
Or does kwin 5.24 contain breaking changes with the current plasma version?
Comment 20 Zamundaaa 2022-01-14 16:00:39 UTC
You can try but it definitely has some breakages on the build side. You'll at least need KWaylandServer, KDecoration and plasma-wayland-protocols to be up to date, too. If you want to do it you should probably use kdesrc-build, it builds all the dependencies and sets up a dev session for testing: https://community.kde.org/Get_Involved/development#Set_up_kdesrc-build

The easiest way to test though is to wait until KDE Neon unstable rebuilds (one or two days) and then use that as a live boot.
Comment 21 Lorenz/Qrly 2022-01-17 15:15:11 UTC
--- REOPENING ---
So I downloaded the kde neon version yesterday, the filename was "neon-unstable-20220116-0330.iso", so I assume this is the newest build.
The issue is still around: https://www.youtube.com/watch?v=JeI0T_m4-94
Comment 22 Zamundaaa 2022-01-18 19:48:24 UTC
It's not surprising that it doesn't work on X, nothing changed regarding that (and nothing can change from our side). How do things look on Wayland?
Comment 23 Lorenz/Qrly 2022-01-19 18:37:40 UTC
They look the same: https://www.youtube.com/watch?v=VJ-43-2R-EQ

(I mean that 30Hz looks as laggy as 60Hz doas.)
Comment 24 Lorenz/Qrly 2022-01-22 14:39:07 UTC
If you don't have any ideas, please, could you give me some recommendations on how to debug this?
Comment 25 Zamundaaa 2022-01-22 22:59:39 UTC
For the lag you may have been affected by a recently fixed regression in git master. In terms of what to do about the black screen, I have no further ideas on how one could debug it - but you could maybe get more help at https://gitlab.freedesktop.org/drm/intel/-/issues
Comment 26 Vlad Zahorodnii 2022-01-24 12:17:23 UTC
Let's close it until we know for sure that it's kwin's fault and not some hardware or driver issue. Regarding the black screen, I've experienced somewhat similar issue (+ other weird visual artifacts) when I tried to connect a 4k monitor to a video card that couldn't drive it 100% or attaching a fhd monitor with high refresh rate (atomic commits succeeded in both cases even though they shouldn't have).