devdraw: fix cursor warping under XWayland

[e0bt]

If devdraw is run under Wayland via XWayland cursor warping doesn't work.

However it's possible to move the cursor if it's not visible: libsdl-org/SDL#9539
I modified devdraw rpc_setmouse function to hide cursor before calling XWarpPointer() and show it afterwards.

Hiding and showing cursor is handled by XFixes extenstion which requirers including X11/extensions/Xfixes.h header and adding -lXfixes to CFLAGS.

[eaburns]

If it's useful, I also have a Wayland driver for devdraw that doesn't require Xwayland: https://github.com/eaburns/plan9port/tree/wayland

[JLanzuisi]

Hi! This is a really nice, simple, workaround. I am having issues building on Fedora 41 tho:

>>> cd /home/j/clones/plan9port/src/cmd/devdraw; mk all
9l -o o.devdraw devdraw.o latin1.o mouseswap.o srv.o winsize.o x11-alloc.o x11-cload.o x11-draw.o x11-fill.o x11-get.o x11-keysym2ucs.o x11-load.o x11-pixelbits.o x11-screen.o x11-unload.o
/bin/ld: x11-screen.o: in function `rpc_setmouse':
/home/j/clones/plan9port/src/cmd/devdraw/x11-screen.c:1387:(.text+0x497): undefined reference to `XFixesHideCursor'
/bin/ld: /home/j/clones/plan9port/src/cmd/devdraw/x11-screen.c:1390:(.text+0x4e0): undefined reference to `XFixesShowCursor'
collect2: error: ld returned 1 exit status
mk: 9l -o o.devdraw ...  : exit status=exit(1)
mk: for i in ...  : exit status=exit(1)
mk: for i in ...  : exit status=exit(1)

I've made sure that both libXfixes-devel and libXfixes packages are installed. Also ldconfig -p shows

libXfixes.so.3 (libc6,x86-64) => /lib64/libXfixes.so.3
libXfixes.so.3 (libc6) => /lib/libXfixes.so.3
libXfixes.so (libc6,x86-64) => /lib64/libXfixes.so
libXfixes.so (libc6) => /lib/libXfixes.so

and the header file is at /usr/include/X11/extensions/Xfixes.h.

If anyone has an idea has to what's going on here, I would appreciate it.

[JLanzuisi]

Ok, so looking at the output of mk all in $PLAN9/src/cmd/devdraw I saw that the -lXfixes flag appeared before the c files, so I changed this line removing the flag here and added a echo 'LDFLAGS=$LDFLAGS -lXfixes' line below. With these changes it built for me, and cursor warping works as expected.

[nicolagi]

Thanks @e0bt and @JLanzuisi - applied to my copy, it works great!

[sternenseemann]

Same here, this seems to work correctly:

Suggested change

	echo 'CFLAGS=$CFLAGS '$X11H -lXfixes
	echo 'CFLAGS=$CFLAGS '$X11H
	echo 'LDFLAGS=$LDFLAGS -lXfixes'

[rsc]

I've been investigating this, and even after adding AUTOLIB(Xfixes) to make it link, it does not work for me under Xwayland on GNOME. Perhaps the "bug" this hack took advantage of has been fixed.

It looks like there is support for a real protocol now but only when the mouse is held down. I commented on https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4525#note_2543753 to see if another use case will change their mind. They seem very set in their ways, though. (And coming from someone who worked on Plan 9 and Go, that's saying something!)

[rsc]

On https://gitlab.gnome.org/GNOME/mutter/-/issues/4301#note_2543773, they wrote "You're showing really good examples of things we want to avoid." which is less than encouraging.

If this patch worked for me, I would merge it, but it does not. Perhaps I have some newer version of Wayland/XWayland/Mutter/some other thing.

I also tried @eaburns's wayland devdraw code, and it did pop up a window that could move the cursor (good!) but the window had no border or window decorations (less good). This was using GNOME. If we could make it play nicer with windowing systems, I'd be happy to merge that.

[eaburns]

KDE provides a Wayland extension that will draw the window decorations for you. My understanding is that the Gnome project takes the stance that the decorations shouldn't be drawn at the Wayland level in the stack, and they expect you to use GTK+ instead of directly using Wayland.

So on KDE you get the decorations, but unfortunately on Gnome you do not. I'm not sure there is a good way forward for direct Wayland on Gnome for the time being.

[lobre]

but the window had no border or window decorations (less good).

I believe this will remain the main blocker to having a usable Wayland devdraw backend, as Wayland effectively has a different model for window decorations.

From what I understand, decoration negotiation is handled through the optional xdg-decoration protocol. GNOME/Mutter does not advertise xdg-decoration, so clients are assumed to draw their own decorations if they want any. Compositors that do advertise xdg-decoration allow clients to express a preference, but ultimately the compositor decides whether decorations are drawn by the server or by the client.

This explains why server-side decorations are available on KDE, but not on GNOME.

I currently see only two ways forward:

• either we accept that devdraw windows will remain undecorated on compositors that do not support server-side decorations (which is far from ideal, and maybe the recommendation here would be to tell people to use Xwayland);
• or we implement minimal client-side decorations in devdraw.

For the second option, the decorations could be kept very simple: for example, a top bar in a Plan 9 style with the usual close/maximize/minimize buttons, and possibly some minimal borders. In any case, Plan 9 applications already come from their own graphical world, with a distinct style and spirit, and are not designed to visually integrate into modern desktop environments. From that perspective, this could even be seen as an opportunity to embrace that difference and define a decoration style that matches the Plan 9 aesthetic, rather than trying to blend into each host desktop.

Anyway, the modern Wayland model (and the push toward client-side decorations) implicitly encourage applications to target a specific toolkit or desktop environment. So it is not specific to devdraw, but more a consequence of the Wayland decoration model itself.

[lobre]

The above client-side decorations idea has been tried in the following pull request. It does not draw a proper bar (as I think it does not make a lot of sense) but instead a border that resembles the ones that Rio draw.

eaburns#8

Hope it can help pushing the thinking forward.

Though, the initial issue of this pull request is about cursor warping and I agree that this is the main struggling point for devdraw on Wayland. When using acme with the Wayland backend, we can see that pointer does not warp, while the application think it has, so clicking again sometimes is not consistent and you end up clicking at a place which is not where your cursor is. And apart from convincing the Wayland people otherwise, I don't see how we can make progress here.

[eaburns]

I think it may be best to move this discussion to a different place. One option is Issue #130 and another option is Pull Request #696.

That said, I am curious about your comment:

When using acme with the Wayland backend, we can see that pointer does not warp

At least with KDE Plasma, this is not the case. With the Wayland backend, pointer warping does work correctly. If you are seeing otherwise on Gnome, then it may be another Gnome issue. If this is broken on Gnome, then I think that coupled with lack of window decorations (which I see you are working on adding as client-side) is more evidence that the Wayland backend isn't ready for merging.

But let's move the follow-up discussion to one of those other recommended places.