Thanks Tolga. It looks like the root cause of the issue on your machine is a lack of display bandwidth when trying to drive 2 screens through the same cable:
May 11 21:08:51 messier32 kernel: i915 0000:00:02.0: [drm:intel_dp_mst_compute_config [i915]] Trying to find VCPI slots in DSC mode
May 11 21:08:51 messier32 kernel: i915 0000:00:02.0: [drm:intel_dp_mst_compute_config [i915]] DSC Source supported min bpp 18 max bpp 24
May 11 21:08:51 messier32 kernel: i915 0000:00:02.0: [drm:intel_dp_mst_compute_config [i915]] DSC Sink supported min bpp 0 max bpp 0
May 11 21:08:51 messier32 kernel: i915 0000:00:02.0: [drm:intel_dp_mst_find_vcpi_slots_for_bpp.constprop.0.isra.0 [i915]] failed finding vcpi slots:-22
May 11 21:08:51 messier32 kernel: i915 0000:00:02.0: [drm:intel_atomic_check [i915]] [ENCODER:106:DP-MST C] config failure: -22
I'm not sure if that's an "expected" or "normal" error which we should expect to see on some setups forever, or if it's a kernel bug. If it's "expected" then ideally mutter/gnome-shell should fail more gracefully but I don't know how that's possible given how limited the atomic API is. You can never find out _what_ failed, only that something failed. I hate atomic KMS.
Thanks Tolga. It looks like the root cause of the issue on your machine is a lack of display bandwidth when trying to drive 2 screens through the same cable:
May 11 21:08:51 messier32 kernel: i915 0000:00:02.0: [drm:intel_ dp_mst_ compute_ config [i915]] Trying to find VCPI slots in DSC mode dp_mst_ compute_ config [i915]] DSC Source supported min bpp 18 max bpp 24 dp_mst_ compute_ config [i915]] DSC Sink supported min bpp 0 max bpp 0 dp_mst_ find_vcpi_ slots_for_ bpp.constprop. 0.isra. 0 [i915]] failed finding vcpi slots:-22 atomic_ check [i915]] [ENCODER:106:DP-MST C] config failure: -22
May 11 21:08:51 messier32 kernel: i915 0000:00:02.0: [drm:intel_
May 11 21:08:51 messier32 kernel: i915 0000:00:02.0: [drm:intel_
May 11 21:08:51 messier32 kernel: i915 0000:00:02.0: [drm:intel_
May 11 21:08:51 messier32 kernel: i915 0000:00:02.0: [drm:intel_
I'm not sure if that's an "expected" or "normal" error which we should expect to see on some setups forever, or if it's a kernel bug. If it's "expected" then ideally mutter/gnome-shell should fail more gracefully but I don't know how that's possible given how limited the atomic API is. You can never find out _what_ failed, only that something failed. I hate atomic KMS.
Did the workaround work for you?
MUTTER_ DEBUG_ENABLE_ ATOMIC_ KMS=0 DEBUG_FORCE_ KMS_MODE= simple
MUTTER_
in /etc/environment