Plasma 6 Wayland, today's git master. GPU hardware is an Intel 10th gen iGPU; drivers are from Mesa 23.1.9. STEPS TO REPRODUCE 1. Have a laptop (it has a 4k screen normally run at 200% scale) 2. Plug in an external HDMI screen, either directly, or via a DisplayPort dongle (doesn't seem to make a difference) 3. Use the KScreen applet to invoke "Switch to External Screen" mode. The laptop screen correctly turns off. 4. Unplug the external screen OBSERVED RESULT The laptop screen does not turn back on. This is 100% reproducible for me. EXPECTED RESULT It *does* turn back on. ADDITIONAL INFORMATION If I plug in the external screen again, it comes back as expected. If I use the KScreen applet to invoke "Extend to left" or "Extend to right" modes, or if I use the KScreen KCM to manually mark the laptop screen as "Enabled", then it turns on, but it's lost its Plasma containment. All I see on it is the banner in the corner, and right-clicking on the black desktop does nothing. Restarting plasmashell or switching with display is marked as "Primary" does not fix the issue. Probably a separate issue for which I will submit a different bug report. Regardless, it is not clear how to make the laptop display work again. For this reason, I'm marking the bug as Grave.
Missing Plasma containment issue is Bug 476341.
Can reproduce with clean configs, some pre-existing degree of configs will make this not reproducible for some reason though. What appears to happen is that DrmOutput in KWin doesn't get an update with enabled=true so the builtin screen stays disabled. Curiously kscreen does however think the output is enabled, so it seems there is a communication problem between the two.
I was wrong when I said it doesn't get enabled. It's much more complicate.d It apparently gets enabled but it doesn't get applied correctly. That said I think this bug and bug #476342 are actually the same defect. When I VT switch I can force a repaint to get the laptop screen activated; input processing is entirely not working though and only happens when VT switching. Specifically I see https://invent.kde.org/plasma/kwin/-/blob/e3186ae8e66c21be61dc4100c0d0e4fa4dffd201/src/scene/workspacescene.cpp#L230 triggering during the DrmOutput changes which I guess means the time management is broken somehow? After the VT switching I then see KWin::RenderLoop::scheduleRepaint calls as I try to interact with widgets but they appear to never result in DrmOutput::present calls which explains why nothing is happening on screen I guess. I would conclude that the RenderLoop(?) is having trouble. I am as yet unsure why.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/4605
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/4611
Git commit c1312a555169c801b2c116a7b333443730092e07 by Xaver Hugl. Committed on 09/11/2023 at 12:35. Pushed by zamundaaa into branch 'master'. backends/drm: fix pageflip events getting lost when outputs get turned off When a display gets turned off while a pageflip event was still pending, the pending state gets changed immediately, without waiting for the pageflip event to arrive first. When this happens, activePending() returns false, and so the pageflip event gets discarded. This commit changes the logic to only check for activePending() when the pageflip is for a modeset, avoiding that issue. Related: bug 476341, bug 476342, bug 437520, bug 475146 M +10 -2 src/backends/drm/drm_commit.cpp M +2 -0 src/backends/drm/drm_commit.h M +5 -2 src/backends/drm/drm_pipeline.cpp M +2 -1 src/backends/drm/drm_pipeline.h https://invent.kde.org/plasma/kwin/-/commit/c1312a555169c801b2c116a7b333443730092e07