X11: outer_position() returns different value than what was set via set_outer_position()

[natepiano]

Description

Summary

On X11, after calling set_outer_position(pos), both outer_position() and WindowEvent::Moved report a position offset from what was set. On my system, the Y coordinate is consistently offset by 56 pixels (the title bar height × scale factor 2).

Repro

I've created an example demonstrating this: https://github.com/natepiano/winit/blob/x11-outer-position-frame-mismatch/winit/examples/x11_outer_position_mismatch.rs

WAYLAND_DISPLAY= cargo run --example x11_outer_position_mismatch

Press 'T' to run the test. Output:

=== Test 1 ===
Calling set_outer_position(PhysicalPosition { x: 200, y: 250 })
Moved event reported (200, 306) - Y is offset by 56 pixels from what we set.

Querying positions after the move:
outer_position() = Some(PhysicalPosition { x: 200, y: 306 })
surface_position() = PhysicalPosition { x: 0, y: 0 }

On this system, every set_outer_position/outer_position cycle
adds 56 pixels to Y. With surface_position() returning (0, 0),
there's no way to determine the actual frame position.

Expected behavior

• set_outer_position(pos) sets the window position to pos
• outer_position() returns pos
• WindowEvent::Moved reports pos

Actual behavior

• set_outer_position(pos) moves the window (frame appears at the requested position visually)
• outer_position() returns pos + (0, 56)
• WindowEvent::Moved reports pos + (0, 56)
• surface_position() returns (0, 0)

Impact

Applications cannot reliably read back window positions. Any code that saves a position and later restores it will see the window drift by the title bar height on each cycle.

OS and window mananger

Operating System: Fedora Linux Asahi Remix 42 (Forty Two [Adams])
Kernel: Linux 6.17.12-400.asahi.fc42.aarch64+16k
Architecture: arm64
Window Manager: KWin

Winit version

0.31.0-beta.2

[natepiano]

Update: Root cause identified for our scenario

After debug logging to get_frame_extents_heuristic in winit-x11/src/util/geometry.rs and found the issue affecting our calls:

  [frame_extents_heuristic] window=41943042 child=41943042 is_top_level=Some(true) nested=false
  [frame_extents_heuristic] raw _NET_FRAME_EXTENTS=Some(FrameExtents { left: 0, right: 0, top: 56, bottom: 0 })
  [frame_extents_heuristic] !nested -> zeroing frame_extents
  [frame_extents_heuristic] path=Supported frame_extents=FrameExtents { left: 0, right: 0, top: 0, bottom: 0 }

X11 correctly reports _NET_FRAME_EXTENTS with top: 56, but the heuristic zeros it out because:

1. window == child (both are 41943042)
2. is_top_level(child, root) == Some(true)
3. Therefore nested = !(true || true) = false
4. When !nested, the code zeros out frame_extents

Their is a comment explaining that this is to handle Mutter/GNOME where frame extents are preserved even after decorations are disabled. But on our KWin instance (possibly other WMs?), the window is "not nested" yet still has visible decorations, and _NET_FRAME_EXTENTS correctly reflects this.

Suggested fix:

Don't zero out frame_extents if _NET_FRAME_EXTENTS reports non-zero values - trust the WM's reported extents rather than inferring decoration state from the window hierarchy.

---

commit containing debug logs: natepiano@0065337b