Window X/Y offsets (specified through --geometry) ignored on Wayland

[petrmanek]

Important Information

mpv version:

mpv 0.33.0-dirty Copyright © 2000-2020 mpv/MPlayer/mplayer2 projects
 built on UNKNOWN
FFmpeg library versions:
   libavutil       56.51.100
   libavcodec      58.91.100
   libavformat     58.45.100
   libswscale      5.7.100
   libavfilter     7.85.100
   libswresample   3.7.100
FFmpeg version: n4.3.2

Linux Distribution and Version: archlinux (updated ~week ago), output of uname -a follows

Linux davos 5.11.10-arch1-1 #1 SMP PREEMPT Fri, 26 Mar 2021 00:11:29 +0000 x86_64 GNU/Linux

Source of the mpv binary: official distribution package

If known which version of mpv introduced the problem: unknown, issue discovered when transitioning from X11 to Wayland

Window Manager and version: sway 1.5.1, installed from official distribution package

GPU driver and version: nothing fancy, using Intel graphics, so i915 + MESA, details follow

$ lspci -vnn | grep VGA -A 12
00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 620 (Whiskey Lake) [8086:3ea0] (rev 02) (prog-if 00 [VGA controller])
    Subsystem: Lenovo Device [17aa:2279]
    Flags: bus master, fast devsel, latency 0, IRQ 138, IOMMU group 1
    Memory at d7000000 (64-bit, non-prefetchable) [size=16M]
    Memory at b0000000 (64-bit, prefetchable) [size=256M]
    I/O ports at 3000 [size=64]
    Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
    Capabilities: <access denied>
    Kernel driver in use: i915
    Kernel modules: i915

$ glxinfo | grep OpenGL
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) UHD Graphics 620 (WHL GT2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 21.0.1
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.6 (Compatibility Profile) Mesa 21.0.1
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 21.0.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:

Possible screenshot or video of visual glitches: no glitches per se, but I still took a screenshot

Reproduction steps

Run the following command:

mpv \
    --no-config \
    -v -v \
    --log-file=mpv-bug.log \
    --geometry=50:40 \
    --image-display-duration=inf \
    /usr/share/backgrounds/sway/Sway_Wallpaper_Blue_1136x640.png

Expected behavior

The window of mpv should be placed at x=50, y=40.

Actual behavior

The window of mpv is aligned to the center of the display.

Log file

Attached as mpv-bug.log

NOTE: even though the log was produced with a multi-display setup, I verified earlier that the number of displays does not affect the issue in any way.

Sample files

N/A

[Dudemanguy]

Unfortunately this is just a wayland limitation. Wayland clients have no way to position themselves on an output, so there's nothing we can do. The only possible way to fix this would be to convince wayland developers to extend xdg-shell and/or add a new protocol we could use. Good luck with that though.

It's possible that your compositor may offer a way to position windows. I don't recall if sway has something like that.

[petrmanek]

One thing I may have forgotten to mention, which seems obvious though, is that I am using the following mpv-related commands in my sway config:

for_window [app_id="(?i)mpv"] floating enable
for_window [app_id="(?i)mpv"] sticky enable

@Dudemanguy Right. After browsing through some more issues that happen to be connected with sway, I realize this may be a common theme for Wayland. For instance, in #6080 or #8606.

I just checked the sway(5) manual page and there definitely exists a sway-aware way of positioning client windows within workspaces and outputs. The following commands do just that:

move left|right|up|down [<px> px]
    Moves the focused container in the direction specified. If the container, the optional px argument specifies how many pixels to move the container.  If unspecified, the default is 10 pixels. Pixels are ignored when moving
   tiled containers.

move [absolute] position <pos_x> [px] <pos_y> [px]
    Moves the focused container to the specified position in the workspace. If absolute is used, the position is relative to all outputs.

move [absolute] position center
    Moves the focused container to be centered on the workspace. If absolute is used, it is moved to the center of all outputs.

I have tested the second one using swaymsg and it seems to work just fine. However, I understand that you may want to prefer a WM-agnostic way if there is one.

Even though I am no Wayland (and by no means xdg-shell) expert, I dug a bit in xdg-shell docs and found the xdg_surface.set_window_geometry request. It seems to be included in the stable version of the protocol, and allow clients to modify their surfaces' offsets & dimensions. Would that not do the job to your satisfaction?

[Dudemanguy]

All the coordinates we get client-side in wayland are surface-local meaning that they have no information about the global layout/coordinates of the entire output space. set_window_geometry is actually not particularly useful for mpv since we set the size in the rendering backends (opengl or vulkan).

[PawnProd]

Hi guys,

Do you have any news about this problem ? You said that is a limitation of wayland, but with wayland becoming the default choice in new Ubuntu releases do they change something about that ?

[Dudemanguy]

The situation remains unchanged. There is currently no way for a wayland client to request where on the desktop it should be placed. This functionality would either need to be added to xdg-shell or in a new wayland-protocol.

[petrmanek]

I can confirm that issue is still present with mpv 0.34.0 and sway 1.6.1. Anybody care to raise this upstream? Also what would be the appropriate upstream place to have this discussion?

[Dudemanguy]

The right place to ask would be in wayland-protocols. Glancing around, I do not see an open issue related to this at the moment.

[petrmanek]

@Dudemanguy Agreed. I have just created a feature proposal there. We shall see what the response is like. Feel free to voice your support in the referenced discussion. :wink:

[BrodieRobertson]

After the prior Wayland issue was derailed and went nowhere a new MR has been opened, hopefully this time we'll see a positive result

[Dudemanguy]

I wouldn't hold my breath.

[JoonasPitk]

Not sure how this would work on other DEs, but as a workaround, I was able to set the mpv window position through KWin's application rules in Plasma.

[Botspot]

Conky can set its position on wayland environments somehow.

[guidocella]

Layer shell surfaces can anchor themselves to an edge of the screen and specify the margin, but clients can't place themselves in arbitrary positions.

[Botspot]

but clients can't place themselves in arbitrary positions.

They can if you force xwayland. Just use this command:

export WAYLAND_DISPLAY=
export XDG_SESSION_TYPE=x11
mpv

This works great for our app store's dual-pane window placement on wayland, but I admit it is less ideal for a video player.

[llyyr]

it is less ideal for a video player

it is less ideal for anything at all to be running under xwayland. Thanks for letting me know i should never use pi-apps