This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Reset cursor position on window creation or reconfiguration (reset_cursor.diff, text/plain, 2021-01-30 14:51:04 +0000, 2219 bytes)
• Updates the cursor position (if needed) on window creation or reconfiguration (update_cursor_v2.diff, text/plain, 2021-02-03 12:17:33 +0000, 4842 bytes)
• Updates the cursor position (if needed) on window creation or reconfiguration (cursor_update_v3.diff, text/plain, 2021-02-03 12:34:44 +0000, 4891 bytes)
• Updates the cursor position (if needed) on window creation or reconfiguration (cursor_update_v4.diff, text/plain, 2021-02-03 13:11:32 +0000, 5084 bytes)
• Updates the cursor position (if needed) on window creation or reconfiguration (cursor_update_v5.diff, text/plain, 2021-02-04 00:17:11 +0000, 4854 bytes)

Reported in version: 2.0.15
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2021-01-30 14:51:04 +0000, Manuel Alfayate Corchete wrote:

Created attachment 4738
Reset cursor position on window creation or reconfiguration

Hi,

This problem only makes sense in an X-less enviroment, where toggling a window fullscreen mode (or recreating a window with a different fullscreen state) can leave the cursor in a screen position that is outside the window area.

So, what I do to prevent this is simply reset the mouse+cursor position to 0,0 each time a window is recreated or reconfigured. Patch included.

Please review so I can merge. Thanks!

On 2021-01-30 20:40:01 +0000, Sam Lantinga wrote:

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.

On 2021-01-30 21:24:15 +0000, Manuel Alfayate Corchete wrote:

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?

On 2021-01-31 02:29:46 +0000, Sam Lantinga wrote:

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.

On 2021-01-31 02:31:35 +0000, Sam Lantinga wrote:

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

On 2021-01-31 03:11:44 +0000, Manuel Alfayate Corchete wrote:

@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?

On 2021-01-31 03:16:26 +0000, Manuel Alfayate Corchete wrote:

@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?

On 2021-01-31 22:36:17 +0000, Manuel Alfayate Corchete wrote:

@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?

On 2021-02-01 02:59:33 +0000, Sam Lantinga wrote:

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.

On 2021-02-03 12:17:33 +0000, Manuel Alfayate Corchete wrote:

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

On 2021-02-03 12:19:39 +0000, Manuel Alfayate Corchete wrote:

@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

On 2021-02-03 12:34:44 +0000, Manuel Alfayate Corchete wrote:

Created attachment 4754
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).

On 2021-02-03 13:11:32 +0000, Manuel Alfayate Corchete wrote:

Created attachment 4755
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.

On 2021-02-04 00:17:11 +0000, Manuel Alfayate Corchete wrote:

Created attachment 4758
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.

On 2021-02-05 16:49:31 +0000, Sam Lantinga wrote:

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.

On 2021-02-05 21:20:08 +0000, Manuel Alfayate Corchete wrote:

@sam: Agreed.