SDL_HideCursor doesn't work reliably on Wayland

[hwsmm]

Description

Right-click in testcustomcursor seems to work fine, but I can still see the cursor in another test that also hides cursor (testpen) if I set SDL_VIDEO_DRIVER=wayland. I can't see the cursor with x11 on XWayland, so this should be Wayland-specific.

I did git bisect and it says that 113475a is the bad commit.

Also, a game that uses SDL3 started getting a segfault on exit after that commit, but I am not sure if it is related to this. I noticed this issue because my hardware cursor started showing up in the game.

Here are some steps you can try if you are interested: Download an AppImage from here, run SDL3_DYNAMIC_API=/path/to/libSDL3.so SDL_VIDEO_DRIVER=wayland OSU_SDL3=1 gdb ./osu.AppImage, and exiting the game gives me the following stacktrace.

I'll test and investigate again myself after this issue gets fixed, so you don't need to try if you don't feel like doing it.

Thread 1 "osu!" received signal SIGSEGV, Segmentation fault.
0x00007fbeaa1a064b in pointer_handle_leave (data=0x7fbe98003650, surface=0x555555899680,
    serial=<optimized out>, pointer=<optimized out>)
    at /mnt/general/git/SDL/src/video/wayland/SDL_waylandevents.c:738
738        window->sdlwindow->flags &= ~SDL_WINDOW_MOUSE_CAPTURE;
(gdb) bt
#0  0x00007fbeaa1a064b in pointer_handle_leave (data=0x7fbe98003650, surface=0x555555899680,
    serial=<optimized out>, pointer=<optimized out>)
    at /mnt/general/git/SDL/src/video/wayland/SDL_waylandevents.c:738
#1  0x00007fbeaa1a07d9 in pointer_handle_leave (data=0x7fbe98003650, pointer=<optimized out>, serial=0,
    surface=<optimized out>) at /mnt/general/git/SDL/src/video/wayland/SDL_waylandevents.c:726
#2  Wayland_SeatDestroyPointer (seat=seat@entry=0x7fbe98003650, send_event=send_event@entry=false)
    at /mnt/general/git/SDL/src/video/wayland/SDL_waylandevents.c:2119
#3  0x00007fbeaa1a1376 in Wayland_SeatDestroy (seat=0x7fbe98003650, send_events=false)
    at /mnt/general/git/SDL/src/video/wayland/SDL_waylandevents.c:3464
#4  0x00007fbeaa1a5d77 in Wayland_VideoCleanup (_this=0x5555558052f0)
    at /mnt/general/git/SDL/src/video/wayland/SDL_waylandvideo.c:1503
#5  Wayland_VideoQuit (_this=0x5555558052f0)
    at /mnt/general/git/SDL/src/video/wayland/SDL_waylandvideo.c:1688
#6  0x00007fbeaa146a96 in SDL_VideoQuit () at /mnt/general/git/SDL/src/video/SDL_video.c:4491
#7  0x00007fbeaa146b6f in SDL_VideoQuit () at /mnt/general/git/SDL/src/video/SDL_video.c:4472
#8  0x00007fbeaa0415db in SDL_QuitSubSystem_REAL (flags=flags@entry=4294967295)
    at /mnt/general/git/SDL/src/SDL.c:605
#9  0x00007fbeaa041df5 in SDL_Quit_REAL () at /mnt/general/git/SDL/src/SDL.c:659
#10 0x00007fff7eaf5f03 in ?? ()

I use sway 1.10.1 on openSUSE Tumbleweed.

[Kontrabant]

The pointer visibility issue is now fixed, but that crash is strange. Shutting down the video subsystem destroys all existing windows, and pointer focus should have been relinquished due to the toplevel window being destroyed, so the crashing code path shouldn't be hit in that case.

Can you replicate the crash with the envvar WAYLAND_DEBUG=1 set? That will show exactly what is going on.

[hwsmm]

Thanks for the quick fix, the cursor now gets hidden properly!

Here is a full log with WAYLAND_DEBUG=1 until the crash: https://gist.github.com/hwsmm/e1592f33a4cecdc7b384a20587b8f10f

[Kontrabant]

Thanks for the log. When destroying the window Sway is sending a keyboard leave event, but no pointer leave, so the mouse focus still points to a destroyed window.

[hwsmm]

I just installed Weston and it seems that no crash happens there (https://gist.github.com/hwsmm/bbf761c9de08abc54384b173c4591d3e).

So, this seems like a Sway bug?

[Kontrabant]

It doesn't happen on GNOME or KDE either as they send pointer leave events when windows are destroyed.

Not sure if this is technically a bug on their end, as I don't think the spec makes any guarantees about leave events for destroyed toplevels/surfaces. Either way, I would rather make SDL robust against this to avoid any future issues.

We ran into something similar in the past involving a crash during suspend/resume on some compositors due to surfaces not getting a preceding leave event when the display they were on disappeared, even though you would logically assume that this would be the case.