Add setRelativeMode for SDL driver

[ndren]

I found a way to fix the screen view spinning rapidly out of control on the SDL driver. This seems to be the most practical way to do it, bar any changes upstream to the minetest repository, even if it is inelegant.

I am not sure why there is still some jitter even with relative mouse mode, but this is definitely a significant improvement over how it was previously.

[sfan5]

Sorry, assuming mouse visibility = relative movement is just too much of a hack. Which platform are you experiencing this on anyway? I didn't notice anything on Linux/X11.

[ndren]

This issue is on Wayland, which I now remember is because of mouse warping not being allowed. I am curious if this patch has side effects on X though.

[ndren]

I am trying to make this less hacky. I have tried simply checking for WAYLAND_DISPLAY but I don't think that's any good if, for example, the Xorg driver is used through Xwayland.

Is there some way to detect if the SDL driver is being used inside of minetest/minetest?

[ShadowNinja]

This is way too hacky. The right way to do this would be something like this:

• Add {I,C}CursorControl::setRelativeMode(bool relative)
  • This will have to be added for every backend unless we remove all of the non-SDL backends.
• Update Minetest to call setRelativeMode.
• Update Minetest camera control to be event driven: Instead of calling CursorControl::getPosition, handle MouseMove events and sum up their contribution for each frame.
  • This might the source of your jitter, getPosition is probably returning something like the last mouse movement instead of what we need, which is the sum of all mouse movements since getPosition was last called for camera control.

[ndren]

https://github.com/minetest/minetest/pull/12636 now depends on this PR. I'd like to know if this is better.

I think I got through the first two sorted. I cannot figure out the camera control code for now, so the jitter will have to be left for a different PR. (I don't know if I'll be able to do that, since I could not find where CursorControl::getPosition is called or what it does.)

[ndren]

This seems to cause jitter on the SDL/X11 driver as well... it'll have to be looked into more.

[ndren]

@slouken has provided a new patch that works without the jitter: https://github.com/libsdl-org/SDL/issues/6034. This now depends on (unreleased) SDL 2.0.24. Whenever this dependency on newer SDL is deemed suitable for fixing Wayland input this will need to be merged first before merging the actual code calling in https://github.com/minetest/minetest/pull/12636.

So far I have tested on sway and i3 and they both work well. I will try to test on other platforms over the next few weeks, though it might be a bit more difficult given the need to build a newer SDL. It's likely easier to wait until SDL 2.0.24 gets released.

[ndren]

I've tried to test on Windows, but I could not find a way to get it to locate zlib. I was able to test on weston and it worked fine.

Since SDL 2.0.24 has been released I would like to know what changes I need to make to get this merged alongside the actual code in https://github.com/minetest/minetest/pull/12636. Could I get some feedback please?

[Desour]

Tested (on X11; with SDL 2.24.0). Works, mouse spinning is gone. (And my touchpad mouse still works.)

But when I exit relative mouse mode (i.e. via esc), and move the mouse, the mouse jumps to somewhere in the upper left quarter of the screen (always the same pos on screen; can jump out of window).

(Also, the game is no longer controllable at all with my drawing tablet, but that's totally irrelevant.)

[ndren]

@Desour thanks for letting me know! I've tested on i3wm and could not reproduce that, the pointer always jumps to the centre of the minetest window when pressing esc. Which X client are you using?

[Desour]

The X client is minetest, if I get the terminology right. My X11 server is the xorg implementation. And I'm using the openbox window manager.

My pointer also is at the center of the window when I press esc. But as soon as I move it slightly, it jumps to the upper left quarter.

I guess the relative coordinates are still stored somewhere and then interpreted as absolute pixel-space screen coordinates.

[ndren]

Sorry, I had the terminology confused, I thought (part of) the client was the WM/DE.

I've tried testing on openbox, and I still can't find anything specifically moving towards the top left quarter. The only thing I could find is that mouse acceleration looks like is maintained when pressing esc. This does not sound like the issue though, so I don't know whether I can reproduce this at all. I've tested with both a mouse and touchpad.

Stab in the dark: could you try running minetest with the environment variable SDL_MOUSE_RELATIVE_WARP_MOTION=1 and see if you can still reproduce? (This might conflict with the change in https://github.com/minetest/irrlicht/pull/123/commits/94111a63c8ca30faa89426fa38ce88c500ca9fa5, so maybe revert that to make sure.)

Thanks a lot!

[ndren]

@Desour Does this happen regardless of which mouse/touchpad etc. you use or is it specific to one of them? If it is specific it may be down to SDL itself.

[Desour]

Running minetest with SDL_MOUSE_RELATIVE_WARP_MOTION=1 seems to make no difference.

The issue only happens with my mouse (which spins without this PR), not with my touchpad.

Sorry for the late answer.

[Desour]

I've tried adding this code:

		input->setMousePos(driver->getScreenSize().Width / 2,
				driver->getScreenSize().Height / 2);

into this if block: https://github.com/minetest/minetest/blob/a805b7ee8ef3f148eb01530dea1fda2d2ba9bf43/src/client/game.cpp#L2409

One would expect that the mouse gets warped to the center of the window each draw step, and this happens. But, if I move the mouse, the curse moves away from the position in the upper left quarter of the window, not from the center. I'll look more into this.

---

I guess the best way to fix this would be to not always warp the cursor to the center when in relative mode, but instead use the relative movement from the mouse-movement events. Relative mouse mode in non-SDL drivers could be simulated with mouse warp to center.

---

Edit: As this seems to be an SDL issue, and because it's not a too big issue, the PR should be merged regardlessly imo.

[slouken]

Yes, mouse warping doesn't generate events in relative mode, it just moves the internal mouse position. When in relative mode you should be looking at the relative motion of the SDL mouse events.

[Desour]

After testing a bit, I found out that the issue can only be reproduced with an xinput coord transformation matrix. See https://github.com/libsdl-org/SDL/issues/6275 for details.

[sfan5]

If on X11 then that sounds like the same root cause as https://github.com/minetest/minetest/issues/8539 except on SDL2's side.

[ndren]

Relevant code: https://sourceforge.net/p/irrlicht/code/6230/ It looks like this only depends on libxi, which SDL seems to feature flag already.

[ndren]

@sfan5 Since that issue has been moved to upstream, could I get this PR and https://github.com/minetest/minetest/pull/12636 reviewed please? Thanks!

[ndren]

Good news: the issue upstream with warps has been fixed.

[Desour]

FYI, for me the mouse spinning seems to have come from the mouse jumping. With newest sdl, I have no issues. With stable sdl and identity coord transformation matrix I also have no issues. In relative mode there seems to be no jumping (and warping works somewhat different).

Anyway, this still works and makes sense. :+1:

[sfan5]

Didn't mean to merge it like this, here's the proper commit: a549d0bfed02801d642ef281697f8ac7c3dbc2cf