Bug 477451 - Outputs freeze on multi-screen when hardware cursors are not supported
Summary: Outputs freeze on multi-screen when hardware cursors are not supported
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: platform-drm (show other bugs)
Version: 5.27.9
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-11-24 09:13 UTC by Asahi Lina
Modified: 2023-12-16 05:13 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In: 6.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Asahi Lina 2023-11-24 09:13:40 UTC
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
Comment 1 Nate Graham 2023-11-29 21:39:01 UTC
Are you by any chance able to test with Plasma 6 to see if it's already been fixed?
Comment 2 Neal Gompa 2023-11-29 23:30:12 UTC
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
Comment 3 Bug Janitor Service 2023-12-07 13:43:11 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/4765
Comment 4 Zamundaaa 2023-12-07 13:44:31 UTC
Afaict, Plasma 6 should already be unaffected by this bug. It would be good if you could test it to verify that though
Comment 5 Zamundaaa 2023-12-13 15:54:00 UTC
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