Handling multiple displays with different format/modifier combinations after a4ef377

[matt1606]

Comparing two versions here:

• Sway Version: not affected: 1.10-dev up to commit 125c74338ac8bf8c15323a49730352b82d6d51bd

• Sway Version: affected: 1.10-dev up to commit a4ef37752fd6ae9e84d60cbe4eaead07f71f9435

  • with #8095 on top, but just to test if it could bring some improvement

• both built against wlroots 0.18.0-dev commit 3fc66d4525916b9301236a000a6ed03311ed25a7 + wlroots_patches

  • some extra debug logs for the swapchain part
  • patch from wlroots/issues/1823#note_2146862 - I know, not supported DisplayLink evdi driver in use, yet I think this issue is more generic than DisplayLink specific, see in description section.

• Debug Log:

  • not affected: sway-debug.125c743.log, swaymsg-get_outputs.125c743.json, drm_info.125c743.txt
  • affected: sway-debug.a4ef377.log, swaymsg-get_outputs.a4ef377.json, drm_info.a4ef377.txt

• Configuration File:

  • config

• Stack Trace:

  • no crash observed

• Description:

  • since the series of commits between 125c74338ac8bf8c15323a49730352b82d6d51bd and a4ef37752fd6ae9e84d60cbe4eaead07f71f9435 one of the displays, the one connected via the DisplayLink (DVI-I-1), remains disabled (power: off).
  • the DisplayLink connected display uses a different combination of pixel format and the modifier (format AR24 (0x34325241), modifier LINEAR (0x0000000000000000)) than the other two connected displays (format XR24 (0x34325258), modifier Y_TILED_GEN12_RC_CCS_CC (0x0100000000000008)), that scenario was properly handled up to 125c74338ac8bf8c15323a49730352b82d6d51bd
  • for a4ef37752fd6ae9e84d60cbe4eaead07f71f9435 the logs show the following error message: [ERROR] [wlr] [backend/drm/atomic.c:335] Failed to acquire FB for plane 31 the test setup with all 3 displays fails and DVI-I-1 display remains in disabled state.
  • so far by static code analysis I was able to find the faulty path: manager_output_prepare returns true after which manager_test continues with calling wlr_backend_test backend->impl->test which for DRM calls drm_connector_test drm_connector_commit_state drm_commit drm->iface->commit atomic_device_commit atomic_connector_add set_plane_props -> Failed to acquire FB for plane 31
  • by drm_info analysis it looks like some planes switched places, including the one holding the FB for DVI-I-1 with format AR24 (0x34325241), modifier LINEAR (0x0000000000000000), i.e. plane 31 in 125c74338ac8bf8c15323a49730352b82d6d51bd <-> plane 15 in a4ef37752fd6ae9e84d60cbe4eaead07f71f9435
  • what can be done to get the display working again?

Regards
Mateusz

[kennylevinsen]

not affected: sway-debug.125c743.log,

This log does not light up DVI-I-1. Only eDP-1 and HDMI-A-1 gets lit up.

so far by static code analysis I was able to find the faulty path:

This does not look right - drm_connector_test and drm_connector_comit_state is the old path, not the new one.

However, I do suspect we might have a multi-gpu issue with the new backend-wide commits. Specifically, in the per-connector code-path, we skip blit and test of secondary GPUs.

With the new backend-wide wlroots logic, we commit all connectors, but we're still skipping the blit in drm_connector_prepare leading to no primary fb being present when we test all connectors, which fails.

---

As a terrible hack, this seems to work:

diff --git a/backend/drm/atomic.c b/backend/drm/atomic.c
index 9defa7c6..f42ccee6 100644
--- a/backend/drm/atomic.c
+++ b/backend/drm/atomic.c
@@ -333,7 +333,7 @@ static void set_plane_props(struct atomic *atom, struct wlr_drm_backend *drm,

        if (fb == NULL) {
                wlr_log(WLR_ERROR, "Failed to acquire FB for plane %"PRIu32, plane->id);
-               atom->failed = true;
+               // atom->failed = true;
                return;
        }

[kennylevinsen]

Try with this branch: https://gitlab.freedesktop.org/kennylevinsen/wlroots/-/tree/displaylink-hack?ref_type=heads

This combines https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4639 with a better hack for DisplayLink. The old one was broken, leading to additional copies.

[matt1606]

Hi, Tested a fresh build of:

• wlroots 172c8add7dfae2853debe9cd70e41d736059e978 + 2 commits from your branch: 069eca1928acc8e19f9f3e5ce8f5913b892e6af0 and b028b3ba02b629e05fb4bf90916aac1d50eb3c89
• sway bc258a3be2f946c1c93bcbe40735b2db068e0ea8

and it works! - sway-debug.bc258a3.log

I was starting to debug other DisplayLink issues I've seen so far, mostly with the high CPU usage by the DisplayLinkManager process when a window was maximized in the DisplayLink connected display, but that was still in the not affected versions from OP, and was caused by enabling the direct scan-out. Some observations and relevant log parts: high_cpu_usage_when_maximized_window_in_DisplayLink_connected_display.txt

With the patches from your branch, the problem of high CPU usage for the DisplayLinkManager process when a windows is maximized seems to be gone, and the logs show that the direct scan-out doesn't get enabled: sway-debug.DisplayLinkManager_maximized_window.log Of course watching a full screen video via DisplayLink is an overkill, but that's the pitfall of how it's implemented in Linux (the kernel/user space split and the related lack of DMA when using USB):

I'll test it more extensively during next few days and share the results. Big thanks for now!

Regards Mateusz

[Dev-Aligator]

The Displaylink-hack doesn't seem to work with:

• Hyprland v0.41.2
• libliftoff 0.5.0-1

What can be done to get the display working again?

[kennylevinsen]

The Displaylink-hack doesn't seem to work with:

* Hyprland v0.41.2
* libliftoff 0.5.0-1

This is the sway issue tracker. Hyprland discussions belong on the Hyprland issue tracker.