initial commit

2026-09-26 17:37:13 +02:00
commit 839bebd8d4
226 changed files with 58701 additions and 0 deletions
@@ -0,0 +1,141 @@
+# Mutter bug report draft
+
+## Where to file
+
+File this in GNOME Mutter:
+
+- https://gitlab.gnome.org/GNOME/mutter/-/work_items/new?type=Issue
+
+This appears to be a Mutter issue because the observed behavior is window-management related on Wayland, not a behavior implemented by this project. This project only configures monitor layout through `gdctl` and does not move third-party windows between monitors in response to pointer focus changes.
+
+## Suggested title
+
+Window moved to lower monitor jumps back to primary upper monitor after clicking the primary monitor
+
+## Report body
+
+### Summary
+
+On a dual-screen vertical layout under GNOME on Wayland, if I move a window to the lower monitor and then click on the upper primary monitor, the moved window is brought back to the upper monitor unexpectedly.
+
+This looks like a Mutter/GNOME window-management issue. I initially suspected my monitor-layout helper, but after reviewing its code path, it only applies monitor topology through `gdctl` and does not contain any logic that moves arbitrary application windows in response to pointer clicks or focus changes.
+
+### Environment
+
+- Hardware: ASUS Zenbook Duo UX8406MA
+- Monitors: two internal displays arranged vertically
+- Layout: upper display is primary, lower display is positioned below it
+- Session: GNOME on Wayland
+- Distro: Ubuntu
+- GNOME Shell version: `<fill in output of gnome-shell --version>`
+- Mutter package version: `<fill in output of apt policy mutter mutter-common-bin | sed -n '1,12p'>`
+- Kernel: `<fill in output of uname -r>`
+- GPU: `<fill in output of lspci | grep -iE 'vga|3d|display'>`
+
+### Steps to reproduce
+
+1. Use a GNOME Wayland session with two displays in a vertical stack.
+2. Set the upper display as the primary monitor.
+3. Set the lower display below the primary monitor.
+4. Open a normal application window.
+5. Move that window to the lower monitor.
+6. Click somewhere on the upper primary monitor.
+
+### Actual result
+
+The window that was moved to the lower monitor is brought back to the upper primary monitor.
+
+### Expected result
+
+Clicking the primary monitor should change focus only. It should not move a window from the lower monitor back to the primary monitor unless the user explicitly requested a move.
+
+### Frequency
+
+- `<always / often / intermittent>`
+
+### Scope
+
+- Affects Wayland-native apps: `<yes/no>`
+- Affects Xwayland apps: `<yes/no>`
+- Reproduces with GNOME extensions disabled: `<yes/no>`
+- Reproduces after stopping local Zenbook helper services: `<yes/no>`
+
+### Why I believe this belongs in Mutter
+
+- The behavior is specifically about window placement after focus interaction across monitors.
+- My local helper only applies monitor configuration via `gdctl set` when layout changes are requested or when hardware/lifecycle state changes.
+- It does not contain code that repositions other apps' windows on pointer clicks.
+- If the issue still reproduces after stopping local helper services, that further isolates it to GNOME/Mutter.
+
+### Diagnostics
+
+Please let me know if you want Mutter debug logs from a nested session, but here is the basic information I can provide immediately.
+
+#### Display layout
+
+```text
+<paste output of: gdctl show>
+```
+
+#### GNOME and package versions
+
+```text
+gnome-shell --version
+apt policy mutter mutter-common-bin gnome-shell
+uname -a
+```
+
+#### GPU details
+
+```text
+lspci | grep -iE 'vga|3d|display'
+```
+
+#### Session details
+
+```text
+echo "$XDG_SESSION_TYPE"
+echo "$XDG_CURRENT_DESKTOP"
+loginctl show-session "$XDG_SESSION_ID" -p Type -p Desktop -p Name
+```
+
+#### Check whether helper services are involved
+
+```text
+systemctl --user stop zenbook-duo-session-agent.service
+sudo systemctl stop zenbook-duo-rust-daemon.service zenbook-duo-rust-lifecycle.service
+```
+
+Then retry the reproduction and note whether the issue still happens.
+
+#### Journal logs around the reproduction
+
+```text
+journalctl --user -b --no-pager | grep -iE 'gnome-shell|mutter|zenbook'
+journalctl -b --no-pager | grep -iE 'gnome-shell|mutter|zenbook'
+```
+
+### Additional notes
+
+- The lower monitor is layout-wise below the primary monitor, not to the side.
+- The key symptom is not just focus transfer; the window is actually re-homed to the primary monitor.
+- If needed, I can test whether this depends on maximized state, tiled state, or whether the app is Wayland-native vs Xwayland.
+
+## Suggested duplicate search terms
+
+Before filing, search Mutter issues for:
+
+- `window jumps back to primary monitor`
+- `window moved to second monitor returns to primary`
+- `wayland vertical monitor layout focus moves window`
+- `Zenbook Duo monitor click moves window`
+
+## Local evidence from the Zenbook Duo project
+
+Relevant code paths reviewed:
+
+- [ui-tauri-react/src-tauri/src/runtime/session_agent.rs](ui-tauri-react/src-tauri/src/runtime/session_agent.rs) only applies GNOME display layout through `gdctl`, including `--below` placement for the second internal display.
+- [ui-tauri-react/src-tauri/src/runtime/daemon.rs](ui-tauri-react/src-tauri/src/runtime/daemon.rs) only triggers display replays on lifecycle, lid, session registration, or hardware policy changes.
+- [ui-tauri-react/src-tauri/src/lib.rs](ui-tauri-react/src-tauri/src/lib.rs) only focuses the Zenbook Duo app window itself from tray or single-instance flows.
+
+These paths do not implement generic cross-monitor window moves for arbitrary applications.