Using MST, only one monitor is able to activate without resetting MST on monitor

[alexmaras]

Note: Things are a little weird with the sequence of events I have to go through here. Please let me know how I can clarify things.

Previously I had the same issue as in #8144 - since that was fixed, I've got this new issue and reloading doesn't resolve this one.

Sway Version:
sway version 1.10
Arch package: sway 1:1.10-1

Debug Log:
The debug logs contain two log files - one where I didn't disable and then re-enable MST (sway.log) and one where I did (sway2.log) in case differences between the two helps.

Here are two more debugs:
start and stop sway before an MST reset
start and stop sway after an MST reset
Each of these is just a sway run and exit. The first is from the broken state and exiting while still broken. The second is a full start and stop after the issue has been fixed using the MST reset. Neither of these logs contain the moment of the fix - that's in sway2.log above.

Configuration File:
https://gist.github.com/alexmaras/5fb9057e4d2f24916d4b375e4580dfa2

Description:
When using MST, after swapping from one device to another, sway is only able to activate one monitor. The other monitor remains blank. Resetting MST in the monitor (turning the MST setting off an back on again) fixes the issue.

1. Use monitor with MST on one computer
2. Shut down first computer and start second computer
3. Start sway

At this point, the secondary monitor (the daisy-chained one) works fine. I can use swaymsg output 'DP-6' power toggle to toggle off that monitor, at which point the primary monitor successfully starts up. Toggling the secondary monitor again turns off the primary. Toggling the primary doesn't do anything.

4. Go into monitor settings
5. Disable MST
6. Enable MST

Now both monitors work as expected. From this point, both monitors continue to work, even across reboots. Connecting my other computer and going through the usual process causes the issue to occur again.

My other computer is also running sway (1.8.1) and doesn't have this issue, though it's also using USB-C and not DisplayPort, so I'm really not sure what part of the equation is causing the problem, there's a few too many variables for me to control. I mainly notice this issue because I use the Sway 1.8.1 computer for work during the day, then turn on my desktop PC (sway 1.10) in the evening and have to go through this little process each time.

I've also tested with WLR_DRM_NO_ATOMIC=1 sway as I'm seeing Atomic commit failed: No space left on device on the runs that fail. When I do that, it just stalls and never carries on and I have to kill it from another TTY. TTYs all have both monitors working correctly all the time.

[alexmaras]

I followed the steps here too and got the outputs: https://github.com/swaywm/wlroots/wiki/DRM-Debugging

dmesg.log
sway.log

I used 0x19 for the debugging bitmask - let me know if I should be using something else or should be directing this bug report to the wlroots repo. Also let me know if it would be helpful to have the equivalent after or during fixing the issue using the MST off/on I have to do in the monitor settings.

I also bought two new DisplayPort cables - both the same DP8K VESA certified cable - to make sure that that wasn't the issue. The problem is identical with the new cables.