Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relative mouse mode won't report movements if buttons are pressed in X11 #963

SDLBugzilla opened this issue Feb 10, 2021 · 0 comments


Copy link

@SDLBugzilla SDLBugzilla commented Feb 10, 2021

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

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

Comments on the original bug report:

On 2013-07-13 05:19:48 +0000, Sik wrote:

Found this bug with X11.

When a mouse button is held down, mouse movement won't be registered in relative mouse mode (didn't check if there are no events or just all events give me a xrel/yrel of 0). Besides feeling unnatural, this prevents actions such as dragging and the like from working.

On 2013-07-13 08:12:47 +0000, wrote:

Does SDL_SetRelativeMouseMode(SDL_TRUE) help?

The issue has recently been mentioned in this post, originally referring to an input grabbing related issue:

It should really be a reply to the following post from 2012:

The last post from 2012 should have a patch (although a call to SDL_SetRelativeMouseMode(SDL_TRUE) is expected to be required for your purposes after applying it, as before; Not yet tested by me, though). If it can't be downloaded from the forums then the more recent post has a link with a backup (and it also has the patch re-attached for users of the mailing list).

On 2013-07-13 08:21:46 +0000, Sik wrote:

SDL_SetRelativeMouseMode(SDL_TRUE) is exactly what triggers this issue actually (and I don't know any other way to enable relative mouse mode). Though I haven't tried it in windowed mode to be honest (only in fullscreen mode), though I could check there.

Also the patch seems to be missing (yes, even the one from the link in the post).

On 2013-07-13 08:58:44 +0000, wrote:

Sorry, there is a minor typo of mine: I have rather meant to refer to SDL_SetWindowGrab(SDL_TRUE) here.

As for the attachment, are you talking about the archived copy of the post from 2012 on Gmane? Because I can download and view the attachment (although the downloaded file has a .bin extension appended to its name).

On 2013-07-13 09:06:02 +0000, David Gow wrote:

Created attachment 1227
The patch from the "Grabbing the Keyboard in X11" thread

I'll need to have another look at this: I don't remember the keyboard grabbing stuff having much to do with relative mouse mode and holding the mouse button down, but I've dug through my "Sent Items" and found the missing patch. I have no idea if it applies cleanly, and I'd definitely want to have another look through the mouse grabbing / relative mouse movement code before having another go.

Still, for the record, the patch is attached!

-- David

On 2013-07-13 09:35:50 +0000, Sik wrote:

I knew about the patch being a .bin file, but the server kept throwing me 404 errors :P Kind of hard to even try using the patch that way.

Also tried the SDL_SetWindowGrab thing. It works, yep, but as mentioned, no way to set the grab exclusively for the mouse. For the record, system shortcuts are not affected by the grab (!!) which probably means that as a workaround for what I need it works (I only need this in fullscreen, to work around yet another bug).

On 2013-07-13 11:45:26 +0000, wrote:

Yeah, that is the exact problem originally reported by David (to which I have referenced in that reply). What's interesting is that Alt-Tab may fail for me, but not other WM shortcuts (currently running Unity on Ubuntu).

BTW, was the original issue (about the keyboard grabbing) reported in the bug tracker? If not, maybe it worths to have a separated report for that, optionally tagging with target-2.0.0 if it is sufficiently important and may not break a lot of things.

However, maybe there is a different path, since one title on Steam appears to take care of it (Alt-Tab + Relative mouse motion done in parallel to a mouse button press). I hope it's not a manual override of the WM shortcut.

On 2013-07-13 11:49:05 +0000, Sik wrote:

Alt+Tab works fine for me actually, otherwise I'd have complained.

The problem is that keyboard grabbing behavior is... rather unstable. It seems to change every so often, so shortcuts may be working fine in the current build, but break in the following one, then get fixed again some time later, etc. You simply can't rely on it and that's a huge issue. Seems to be the best I have for now though :/

On 2013-07-15 23:27:23 +0000, David Gow wrote:

The whole Alt+Tab thing was fixed. I just had another look through the X11 grabbing code and it now works basically how the patch above worked, though with the addition of a SDL_HINT_GRAB_KEYBOARD hint to force keyboard grabbing. This basically means that the keyboard shouldn't be grabbed in XRandR is enabled. (We have to grab it in the "legacy" fullscreen mode, or things break, which is why it isn't enabled in SDL 1.2).

I've also been trying to reproduce this issue, where relative mouse mode doesn't work if a mouse button is held down, and I can't manage it. I've tried both my own application and "testrelative" in windowed, fullscreen, and fullscreen desktop modes and everything works fine. I'm using KWin 4.10.5 (on a multimonitor setup, no less). What WM are you using?

-- David

On 2013-07-16 10:49:53 +0000, wrote:

I'm currently running Unity 5.20 here.

I have just built testrelative and then started it using the following command:
./testrelative --fullscreen-desktop

The internal cursor stays at its last location while the left mouse button is pressed. Once I press on Ctrl+G (effectively calling SDL_SetWindowGrab(window, SDL_FALSE)), I can freely move the cursor while the same button is pressed.

On 2013-07-16 12:56:36 +0000, David Gow wrote:

Hmm... I haven't been able to reproduce this on openbox or twm either. Can you reproduce it under another window manager?

-- David

On 2013-07-16 13:29:54 +0000, wrote:

I should've probably typed before that it is Ubuntu 12.04 which I'm currently running.

I've reproduced this on the following environments: Unity (2D or not), GNOME Classic (with or without effects), KDE

On 2013-08-01 03:42:46 +0000, Sam Lantinga wrote:

You need to grab the mouse in order to get mouse motion while buttons are down when in raw input mode under X11.

SDL should be doing that internally, but in the meantime you can work around it by just grabbing input when you turn on relative mode. The drawback of course is that the Unity window manager won't let you Alt-Tab when you have the mouse grabbed.

On 2018-08-06 21:20:18 +0000, Ryan C. Gordon wrote:

Hello, and sorry if you're getting dozens of copies of this message by email.

We are closing out bugs that appear to be abandoned in some form. This can happen for lots of reasons: we couldn't reproduce it, conversation faded out, the bug was noted as fixed in a comment but we forgot to mark it resolved, the report is good but the fix is impractical, we fixed it a long time ago without realizing there was an associated report, etc.

Individually, any of these bugs might have a better resolution (such as WONTFIX or WORKSFORME or INVALID) but we've added a new resolution of ABANDONED to make this easily searchable and make it clear that it's not necessarily unreasonable to revive a given bug report.

So if this bug is still a going concern and you feel it should still be open: please feel free to reopen it! But unless you respond, we'd like to consider these bugs closed, as many of them are several years old and overwhelming our ability to prioritize recent issues.

(please note that hundred of bug reports were sorted through here, so we apologize for any human error. Just reopen the bug in that case!)


@SDLBugzilla SDLBugzilla added abandoned bug labels Feb 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

1 participant