SDL_FreeCursor() is being called after SDL_DestroyWindow(): problem in KMSDRM

SDL Development
1

Hi there,

When exiting an SDL2 program, normally the programmer calls SDL_DestroyWindow() and then SDL_Quit(), with some other SDL_Destroy* calls in the middle.

In a backend using EGL, like the KMSDRM backend does, SDL_DestroyWindow() indirectly calls eglDestroySurface(), and also in the KMSDRM backend, it destroys the GBM surface. Both the EGL and the GBM surfares are the KMSDRM-side support of the SDL Window.
Then, SDL_Quit() indirectly calls SDL_FreeCursor(), which in the KMSDRM backend tries to free the GBM cursor (hardware cursor). But there’s a big problem: the GBM and EGL surfaces have already been destroyed when we try to disable the GBM cursor, so in the AMDGPU driver it causes a kernel error message, and the cursor stays on screen after the SDL2 program ends.

So I was thinking about making KMSDRM_DestroyWindow() or KMSDRM_DestroySurfaces() to disable the hardware cursor, if any cursor is active, instead of waiting for the SDL_FreeCursor()->KMSDRM_FreeCursor() call: the problem is that some program could:
1- Create a window (EGL and GBM surfaces)
2- Set a GBM cursor
3- Destroy the window and it’s surfaces -> cursor is destroyed
4- Create another window, and still want to have the cursor…
So I am asking for help here because I don’t know how to solve this situation. Ideally, I would like to discuss this directly with SDL2 core devs, so I have also emailed @Slouken to understand how to proceed, but any ideas are welcome.

PS: I contribute to SDL2 in small bursts of time, I don’t have much time to fix this, so ideas are welcome ASAP. Thanks!

2

In the end, after thinking about it myself, I have came to the conclusion that, sinde drmModeSetCursor() uses the CRTC and drm_fd as parameters, the right way to think about it is that a cursor is related to a CRTC and drm fd, so disabling the cursor AFTER the EGL and GBM surfaces are destroyed is OK: so for the cursor staying on screen and the kernel error, I have to blame AMDGPU and not SDL2, which does something reasonable after all.