There are games which reconfigure the window, but assume the mouse is in the same location. (e.g. over a button to change resolution, etc.)

Does SDL do the right thing if the mouse is grabbed and the cursor is outside the window? If not, let's fix that instead.

How do I know if the mouse is "grabbed"? What does that mean in a context where there are no real windows to begin with?

And... What would be the idea?

1) That the mouse has to remain on the EXACT same position after the window is reconfigured?

OR

2) That the mouse has to remain on the same position RELATIVE TO THE WINDOW after the window is reconfigured?

In most systems the mouse position is independent of the window position. The only time the mouse moves with the window is when the input is constrained, with SDL_SetWindowMouseGrab().

We should retain this behavior in KMSDRM.

To answer your question, when the mouse is grabbed, the mouse position is clipped by the window rectangle and adjusted to the intersection if it is outside the window.

Essentially:
if ( x < left edge ) x = left edge
if ( x > right edge ) x = right edge
if ( y < top edge ) y = top edge
if ( y > bottom edge ) y = bottom edge

@Sam: So essentially I should "manually" limit the mouse to the window area in KMSDRM, but only when the mouse is "grabbed". Is that right?

If so, how do I know if the mouse is "grabbed" so I should move it with the window?

@Sam: I can see if a window input is grabbed by using SDL_GetWindowGrab() in the KMSDRM code, right?

So, if the window input is grabbed, I should reposition the mouse+cursor with "if ( x > right edge ) x = right edge", etc. when the window is created or reconfigured, right?

@Sam: I seem to understand now that I should NOT modify the mouse position manually from the KMSDRM backend: instead, the SDL mouse position should always be INSIDE the window when the window is grabbed. 

So, for example if I go from a FULLSCREEN window that covers the whole screen area to a normal windowed-window that only covers an small rect in the lower-left corner of the screen, the mouse coordinates should by updated by SDL internals, not KMSDRM, so the mouse position goes from, let's say, 1322,55 to 640,55.

The problem is that does not happen: mouse->x and mouse->y can be out of the window rect, SDL does NOT set a valid mouse position so the mouse is inside the new window.

Can you please explain this? What am I missing?

The grab implementation is handled by the video driver, not the higher level mouse code. You're responsible for making sure that the cursor position is clipped to the window when the mouse is grabbed.

Created attachment 4753 [details]
Updates the cursor position (if needed) on window creation or reconfiguration

@Sam this new version of the patch does what your algorithm suggests, adapted to the KMSDRM eviroment (ie: no real concept of window, etc)
Seems to work ok, please review so I can merge

thanks

Created attachment 4754 [details]
Updates the cursor position (if needed) on window creation or reconfiguration

I have updated the patch so the UpdateCursorPosition() is safer (don't try to do anything if there's no cursor buffer object available, etc).

Created attachment 4755 [details]
Updates the cursor position (if needed) on window creation or reconfiguration

Another version of the patch: I forgot that the internal mouse position has to be adjusted when the Y position is corrected, or internal mouse position and cursor positoin wouldn't match, causing an unwanted mouse warp effect on first movement on that axis.

Created attachment 4758 [details]
Updates the cursor position (if needed) on window creation or reconfiguration

Yet another version of the patch:
I found out that I haven't to change the Y coord to the upper limit if it's greater than the upper limit, because I do that correction later when I call the DRM cursor drawing function after making the Y coord relative to the window.

Can't find any more failures... Seems to be the right combination this time.

Since windows are fullscreen again, let's hold off on this change. We may revisit this in the future if we re-add optional support for planes, etc.

@Sam: Agreed.