Sway: Plugging in an external monitor causes all clients to exit

[ggreer]

Steps to reproduce:

• Start sway.
• Plug in external monitor.
• After a few seconds, both internal & external monitors show a gray background.
• Reloading the sway config (cmd + shift + c for me) causes swaybar to show up again.
• All apps have exited.

This is probably something related to restarting xwayland. If I have no apps running, hotplugging monitors works fine (swaybar stays running). If I have a few apps running (such as gnome-terminal), it happens almost 100% of the time.

• Sway Version:

sway version 1.0-rc1-36-gf00fbe68 (Feb 7 2019, branch 'master')

• Debug Log:

This gist contains two logs of the bug. One with verbose logging and one with debug logging.: https://gist.github.com/ggreer/120d530e5b034dcac6fd1f87878ea89e

• Configuration File:

https://github.com/ggreer/dotfiles/blob/master/home/.config/sway/config

Lastly, this used to not be a problem with an earlier version of sway + wlroots. I'm pretty sure the version of both from January 14th worked fine for me on the same hardware.

[emersion]

It seems that all clients exit with

wl_registry@2: error 0: invalid global wl_output (31)

We're probably creating and destroying an output very quickly, which triggers a race with Wayland globals.

Can you start a Wayland client with WAYLAND_DEBUG=client, trigger the bug, and post the trace here?

[prometheanfire]

hmm, might be seeing this on my tb dock at work. will post logs if I can reproduce on rc1

[ggreer]

Gist updated with the output of WAYLAND_DEBUG=client gnome-power-statistics &> wayland-gnome-power-settings.log

https://gist.github.com/ggreer/120d530e5b034dcac6fd1f87878ea89e#file-wayland-gnome-power-settings-log

Another clue: If I start sway with the external monitor plugged in, I can unplug and re-plug in all I want and nothing ever crashes. This is true even if I sleep/wake my laptop.

[emersion]

Relevant race:

[973903.810] [email protected](28, "wl_output", 3)
[973903.820]  -> [email protected](28, "wl_output", 2, new id [unknown]@28)
[973903.838]  -> [email protected](new id wl_callback@29)
[982227.815] [email protected]_remove(28)

[ggreer]

I think https://github.com/swaywm/wlroots/pull/1545 fixed this issue.

I bet the underlying race condition is still there (and could likely be triggered with an appropriately flaky monitor), but I can't seem to reproduce the problem when using wlroots after that version. Also external monitors become usable much quicker now.

[emersion]

I'm not sure we can do anything else. I'd like not to add timers as workarounds.

[ggreer]

Now that https://github.com/swaywm/wlroots/pull/1545 is reverted, this bug is back.

[emersion]

https://github.com/swaywm/sway/pull/3704

[RedSoxFan]

I'm actually able to reproduce this with b57761e833f0198d2bd9ac95b1926cc5b08d6ac3 and wlroots swaywm/wlroots@8600f457be7a538e39914c37b72fee1a933ebe1 with the following (slightly modified version of the original issue):

• Two outputs: $LAPTOP and $HDMI
• Start sway with $HDMI disconnected
• Run swaymsg output \$HDMI disable (this could also just be added to the config)
• Connect $HDMI
• Run swaymsg output \$HDMI enable, output \* disable, output \$LAPTOP enable
• Only swaybg is running. All applications and swaybar are gone.

Obviously, not sure why you would want to do that for anything other than testing things, but it does reproduce 100% of the time so I'm going to reopen this.

Edit: debug log

[ggreer]

After some recent wlroots changes, I can reproduce this issue if sleep/wake and then connect an external monitor. I'll try to collect some useful logs.

[emersion]

Just got an Xwayland crash after undocking. Probably related to this.

[prometheanfire]

Sounds related, I'm not sure I was able to reproduce without xwayland apps running, though the undock'd outputs were disabled. Did it lock up or actually crash? (mine is a lock up)

[emersion]

This issue is about apps exiting (loosing the connection), not about a lockup.

[RedSoxFan]

Related https://gitlab.freedesktop.org/wayland/wayland/issues/10

[emersion]

Firefox logs from @prometheanfire: https://mthode.org/wayland-ff-crash2.log.xz (beware, it seems that reading from multiple threads duplicates logs)

[emersion]

I'm able to reproduce this reliably by having a Chamelium device simulate a bad DisplayPort link and trigger a link training failure. dmesg shows:

[141069.674604] [drm:intel_dp_get_link_train_fallback_values [i915]] *ERROR* Link Training Unsuccessful

and all sway clients exit. I believe the driver triggers one hotplug event to advertise the connection, then another to prune modes.

[emersion]

Opened two related wayland MRs:

• https://gitlab.freedesktop.org/wayland/wayland/merge_requests/28
• https://gitlab.freedesktop.org/wayland/wayland/merge_requests/30

[coderkun]

Any news on this one? The two wayland merge requests have been merged already.

Would you like me to produce a debug log (on sway 1.2) for further investigation?

Edit: I see that you are waiting for a new release of Wayland that includes the merge requests, right?

[emersion]

Still waiting for a new Wayland release.