Closed qrp73 closed 11 months ago
just tested it on Linux Arch under Wayland, on Arch/Wayland XMoveWindow function also works ok, as expected.
So, the only system where XMoveWindow fails on Wayland is raspios-bookworm.
Does it work under upstream Wayfire? Or Sway (both of which are based on wlroots), would identify which codebase is the problem.
What is the Wayland implementation on Arch you're using?
XMoveWindow cannot work on Wayland. It is an instruction to an X server. There is no equivalent in Wayland; there is no Wayland instruction to which it can be mapped. It is functionally a no-op in a Wayland environment.
If you are seeing XMoveWindow work on a Wayland environment, then it has to be being processed by an X server, which in this case is presumably an Xwayland instance running in the Wayland environment.
As far as I am aware, Xwayland is a standard component across all Wayland instances. In order for it to respond to an XMoveWindow instruction it would need to map it onto a layer-shell instruction in Wayland. This does not appear to happen in the version of Xwayland we are using, which is the standard Debian bookworm release.
So if this is indeed working on Ubuntu, then they have customised their Xwayland instance to remap XMoveWindow into a layer shell command, which would be a very non-trivial thing to do. Grepping the Xwayland source code for the version we are using, I can find no references to the use of layer shell, so it seems unlikely this has been implemented.
My Ubuntu laptop is configured for Wayland (settings/about shows "Windowing System: Wayland").
The attached test-x11
does behave as described there (pressing keys moves window).
Using xeyes
, test-x11
does get watched, so is running as some sort of X. ps shows:
/usr/bin/Xwayland :0 -rootless -noreset -accessx -core -auth /run/user/1000/.mutter-Xwaylandauth.P9EKB2 -listenfd 4 -listenfd 5 -displayfd 6 -initfd 7
In Bookworm I get:
pi@raspberrypi:~$ Xwayland -version
The X.Org Foundation Xwayland Version 22.1.9 (12201009)
X Protocol Version 11, Revision 0
Ubuntu it's:
$ Xwayland -version
The X.Org Foundation Xwayland Version 22.1.8 (12201008)
X Protocol Version 11, Revision 0
so marginally older (but there may be different patches).
The other possibility, on thinking about this further, is that Ubuntu have implemented some mechanism whereby an XMoveWindow instruction received by Xwayland is then passed back to the compositor, which then reacts by relocating the window. But this would, as far as I know, be an extension to the default behaviour requred by a Wayland compositor, and not standard functionality.
I don't know whether that potential mechanism should be in wlroots or in wayfire, but my suspicion is that its absence is due to an optional feature not having been implemented rather than this being a bug.
The OP might like to raise the issue at https://github.com/WayfireWM/wayfire/issues with the Wayfire developers to see what their position is.
Here is Xwayland version from linux arch where XMoveWindow works ok:
$ Xwayland -version
The X.Org Foundation Xwayland Version 23.2.1 (12302001)
X Protocol Version 11, Revision 0
$ wayland-scanner --version
wayland-scanner 1.22.0
Currently cannot check ubuntu, because I replaced it with latest raspios-bookworm and trying to compile wayfire...
Here is current version of Xwayland and Wayland on raspios-bookworm:
$ Xwayland -version
The X.Org Foundation Xwayland Version 22.1.9 (12201009)
X Protocol Version 11, Revision 0
$ wayland-scanner --version
wayland-scanner 1.21.0
not relevant anymore
Steps To Reproduce:
1) Login to Wayland desktop 2) Create test-x11.c:
2) compile it with
gcc -o test-x11 test-x11.c -lX11
3) Run it with./test-x11
4) Select window 5) Press keyboard key 1Expected result: window should move to coordinate 100,100
Actual result on ubuntu/Wayland: window is moved to coordinate 100,100 => OK
Actual result on raspios-bookworm/Wayland: nothing happens, XMoveWindow fails => BUG
6) Press keyboard key 2
Expected result: window should move to coordinate 200,200
Actual result on ubuntu/Wayland: window is moved to coordinate 200,200 => OK
Actual result on raspios-bookworm/Wayland: nothing happens, XMoveWindow fails => BUG
Testing environment:
ubuntu:
raspios-bookworm:
As you can see XMoveWindow function works ok on Wayland in ubuntu, but fails on Wayland in raspios-bookworm
Conclusion
Broken XMoveWindow function in raspios-bookworm/Wayland leads to many issues in different apps. Especially it leads to out of display window issues when window needs to dynamically expand/collapse. It often happens for context menu (see bookworm/Wayland taskbar Network plugin or VLC media player for example) and for app window (for example in media players like VLC, in messengers and games).
On the other hand XMoveWindow function works ok with Wayland on other OS such as ubuntu.