| Summary: | Outputs freeze on multi-screen when hardware cursors are not supported | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Asahi Lina <lina> |
| Component: | platform-drm | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | fanzhuyifan, kaktus9news, m.kurz, nate, ngompa13, vlad.zahorodnii, xaver.hugl |
| Priority: | NOR | ||
| Version First Reported In: | 5.27.9 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/kwin/-/commit/5b7183c77a2be9c3c26f9f209e783cb1a34118e0 | Version Fixed In: | 6.0 |
| Sentry Crash Report: | |||
Are you by any chance able to test with Plasma 6 to see if it's already been fixed? It may be possible to test this with the latest Rawhide Fedora Asahi Remix KDE builds, since they have Plasma 6 alpha now: https://fedora-asahi-remix.org/builds.html A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/4765 Afaict, Plasma 6 should already be unaffected by this bug. It would be good if you could test it to verify that though Git commit 5b7183c77a2be9c3c26f9f209e783cb1a34118e0 by Xaver Hugl. Committed on 13/12/2023 at 16:44. Pushed by zamundaaa into branch 'Plasma/5.27'. backends/drm: commit m_next state properly Without this, atomic test failures might restore state that's out of date. M +1 -2 src/backends/drm/drm_pipeline.cpp https://invent.kde.org/plasma/kwin/-/commit/5b7183c77a2be9c3c26f9f209e783cb1a34118e0 |
SUMMARY When using multiple screens with the DRM backend on a machine that does not support hardware cursors, sometimes all rendering freezes when the cursor icon is about to change. `KWIN_FORCE_SW_CURSOR=1` works around the issue, so it's not a problem with software cursors themselves. The problem seems to be that failed hardware cursor updates inadvertently revert the pipeline state. This hack works around the issue: ``` diff --git a/src/backends/drm/drm_pipeline.cpp b/src/backends/drm/drm_pipeline.cpp index e0e0b2f01958..083b810f79fe 100644 --- a/src/backends/drm/drm_pipeline.cpp +++ b/src/backends/drm/drm_pipeline.cpp @@ -461,7 +461,7 @@ bool DrmPipeline::setCursor(const QPoint &hotspot) if (result) { m_next = m_pending; } else { - m_pending = m_next; + //m_pending = m_next; } return result; } @@ -481,7 +481,7 @@ bool DrmPipeline::moveCursor() m_output->renderLoop()->scheduleRepaint(); } } else { - m_pending = m_next; + //m_pending = m_next; } return result; } ``` I don't know why the steps to reproduce this are so specific. It doesn't seem to happen when an external secondary screen is first connected, only if you them trigger a mode change or a powerdown/powerup (and a re-hotplug clears the issue). Maybe there is some other underlying weirdness here... STEPS TO REPRODUCE 1. Run kwin_wayland on a machine with multiple outputs, and no legacy hardware cursor nor cursor plane support. 2. Connect a secondary output 3. In System Settings, change the resolution or refresh rate of the secondary output 4. Move the mouse cursor around, hovering over text items or window edges (where it would change) OBSERVED RESULT The entire screen freezes until the mouse is moved to the other screen (some other events/apps running can also unjam it) EXPECTED RESULT No freezes SOFTWARE/OS VERSIONS Operating System: Fedora Linux Asahi Remix 39 KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.111.0 Qt Version: 5.15.11 Kernel Version: 6.6.0-asahi-00861-g9b58b16aa50d (64-bit) Graphics Platform: Wayland Processors: 12 Memory: 54.5 GiB of RAM Graphics Processor: Apple M2 Max Product Name: Apple MacBook Pro (16-inch, M2 Max, 2023) ADDITIONAL INFORMATION