Summary: | After disabling the laptop screen while an external screen is connected, disconnecting the external screen doesn't re-activate the laptop screen | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Nate Graham <nate> |
Component: | multi-screen | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | grave | CC: | sitter, xaver.hugl |
Priority: | NOR | Keywords: | multiscreen, qt6, wayland |
Version: | master | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
See Also: |
https://bugs.kde.org/show_bug.cgi?id=476341 https://bugs.kde.org/show_bug.cgi?id=476342 https://bugs.kde.org/show_bug.cgi?id=437520 https://bugs.kde.org/show_bug.cgi?id=476412 |
||
Latest Commit: | https://invent.kde.org/plasma/kwin/-/commit/c1312a555169c801b2c116a7b333443730092e07 | Version Fixed In: | |
Sentry Crash Report: |
Description
Nate Graham
2023-10-30 20:53:14 UTC
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 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 |