The Problem with Output Destruction

Oct 13, 2025 by pinkandtrash.com 119 views

Introduction

When working with Wayland compositors, such as Sway, it's essential to understand the behavior of windows and outputs. In this article, we'll delve into a specific issue where a window disappears when the output is destroyed and recreated. This problem was uncovered during an investigation into a GitHub issue related to the GTK3 version.

Understanding the Issue

The issue arises when the only output is disabled and then re-enabled. In this scenario, the window doesn't come back with the output. This problem is not limited to the GTK3 version, but it's essential to note that there may be additional issues when an app has set an output.

Testing the Issue

To test this issue, you can use the following command in a nested instance of Sway:

export SWAYSOCK="$(ls $XDG_RUNTIME_DIR/sway-ipc.*.sock)" && swaymsg output '*' disable && sleep 0.5; swaymsg output '*' enable

This command disables all outputs and then enables them after a 0.5-second delay. You may need to adjust the SWAYSOCK variable or the delay time to suit your specific setup.

The Problem with Output Destruction

When an output is destroyed and recreated, the window doesn't come back with it. This is because the window is not properly re-attached to the output. This issue can be problematic, especially when working with applications that rely on a specific output.

Why Does this Happen?

The reason behind this issue is due to the way Wayland compositors handle output destruction and recreation. When an output is destroyed, the window is not automatically re-attached to the recreated output. This is because the window's attachment to the output is not properly synchronized.

Workarounds and Solutions

While there is no straightforward solution to this issue, there are a few workarounds that can help mitigate the problem:

Use a different Wayland compositor: If you're experiencing this issue with Sway, you can try using a different Wayland compositor, such as Weston or KWin.
Set an output for the app: If the app has set an output, you can try setting a different output for the app. This may help the window re-attach to the output when it's recreated.
Use a window manager that supports output re-attachment: Some window managers, such as i3, support output re-attachment. You can try using one of these window managers to see if it resolves the issue.

Conclusion

In conclusion, the issue of a window disappearing when the output is destroyed and recreated is a complex problem that requires a deep understanding of Wayland compositors and window management. While there is no straightforward solution to this issue, there are a few workarounds that can help mitigate the problem. By understanding the root cause of this issue and exploring different solutions, you can work towards resolving this problem and ensuring a seamless user experience.

Future Work

To resolve this issue, further investigation is needed to understand the underlying causes of the problem. This may involve:

Improving output destruction and recreation: Wayland compositors can be improved to better handle output destruction and recreation. This may involve implementing a more robust synchronization mechanism for window attachments.
Developing a solution for window re-attachment: A solution can be developed to re-attach windows to the output when it's recreated. This may involve implementing a new protocol or modifying existing protocols to support window re-attachment.
Testing and validation: Thorough testing and validation are necessary to ensure that any proposed solutions work as expected and don't introduce new issues.

Introduction

In our previous article, we explored the issue of a window disappearing when the output is destroyed and recreated. In this article, we'll provide a Q&A section to help answer some of the most frequently asked questions related to this issue.

Q: What is the root cause of this issue?

A: The root cause of this issue is due to the way Wayland compositors handle output destruction and recreation. When an output is destroyed, the window is not automatically re-attached to the recreated output. This is because the window's attachment to the output is not properly synchronized.

Q: Is this issue specific to Sway?

A: No, this issue is not specific to Sway. It can occur with any Wayland compositor that doesn't properly handle output destruction and recreation.

Q: Can I use a different Wayland compositor to resolve this issue?

A: Yes, you can try using a different Wayland compositor, such as Weston or KWin. However, it's essential to note that this may not resolve the issue entirely, and you may still experience problems with window re-attachment.

Q: How can I set an output for the app to resolve this issue?

A: To set an output for the app, you can use the weston-desktop-shell command. For example:

weston-desktop-shell --output=primary

This will set the primary output for the app.

Q: Can I use a window manager that supports output re-attachment?

A: Yes, some window managers, such as i3, support output re-attachment. You can try using one of these window managers to see if it resolves the issue.

Q: Is there a solution to re-attach windows to the output when it's recreated?

A: Yes, a solution can be developed to re-attach windows to the output when it's recreated. This may involve implementing a new protocol or modifying existing protocols to support window re-attachment.

Q: How can I contribute to resolving this issue?

A: You can contribute to resolving this issue by:

Reporting bugs and issues related to this problem
Providing feedback and suggestions for potential solutions
Contributing to the development of new protocols or modifications to existing protocols to support window re-attachment

Q: Where can I find more information about this issue?

A: You can find more information about this issue on the following resources:

GitHub issue: https://github.com/wmww/gtk-layer-shell/issues/135
Wayland documentation: https://wayland.freedesktop.org/docs/html/
Sway documentation: https://swaywm.org/docs/

Conclusion

In conclusion, the issue of a window disappearing when the output is destroyed and recreated is a complex problem that requires a deep understanding of Wayland compositors and window management. By exploring different solutions and contributing to the development of new protocols or modifications to existing protocols, we can work towards resolving this issue and providing a better user experience for those using Wayland compositors.