We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 1052 - Relative motion events don't work as expected
Summary: Relative motion events don't work as expected
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: events (show other bugs)
Version: HG 2.0
Hardware: All Linux
: P2 major
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on: 1174
Blocks:
  Show dependency tree / graph
 
Reported: 2010-09-15 07:37 UTC by Tomek Bury
Modified: 2013-05-21 01:23 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Tomek Bury 2010-09-15 07:37:45 UTC 
The current implementation of relative motion event for X11 has 2 disadvantages. It doesn't work when mouse cursor leaves the window and it's clamped by the edges of the screen.

Grabbing a focus is not really an option because you won't be able to Alt-Tab from such window. The only workaround for clamping problem is to keep wrapping mouse to the centre and hope it won't move fast enough to escape. 

The new XInput2 provides an elegant solution. It reports relative motion so you don't have to reverse-engineer it by tracking cursor position changes. The focus and edge clamping problems are direct consequences of tracking cursor. As the relative motion events report movement of the mouse, not the cursor, those problems disappear.

I'd suggest to use XI2 for relative mouse motion in SDL.
Comment 1 Sam Lantinga 2011-03-11 18:31:11 UTC 
I'm not sure when I'll have time to implement XInput 2, but you're welcome to submit a patch!
Comment 2 Adam Olsen 2012-05-29 00:15:03 UTC 
Just tripped over this using SDL1.3 trunk of May 25th on Linux (KDE desktop).  Fullscreen gave correct events but windowed gives absolute from the window edge once you leave the window.

Grabbing the mouse stops motion entirely at the edge, but for some applications (including mine) it makes more sense to never grab the mouse.  Absolute coordinates actually give the same effect there, without grabbing the mouse, so I think I'll use them when not fullscreen.
Comment 3 Adam Olsen 2012-05-29 00:17:02 UTC 
I should say: when you leave the window it's *like* you're using absolute, but they're measuring the distance from that window edge instead.  In contrast, my workaround is to use *actual* absolute coordinates.
Comment 4 Adam Olsen 2012-05-29 00:51:24 UTC 
Ah, my mistake.  I don't get events when in fullscreen.

Also setting depends-on.
Comment 5 Tomek Bury 2012-05-30 12:35:51 UTC 
I think there are significant differences between cursor motion and mouse motion. Mouse doesn't have absolute (x,y) coordinates, cursor does. The only thing mouse knows is the relative motion (dx, dy). Mouse motion is (partially) limited by the length of mouse cable or range of Bluetooth. Cursor motion is constrained by window size. Mouse is not affected by cursor acceleration settings, cursor is. 

SDL is trying to recover mouse motion from cursor motion hence the problems. Some are obvious (focus, clamping), some are more subtle (cursor acceleration applied to mouse motion). My initial suggestion was to read the actual mouse events rather than reverse-engineer them from cursor position changes. Unfortunately I haven't got enough time on my hands to come up with the patch.
Comment 6 Sam Lantinga 2013-05-21 01:23:11 UTC 
XInput2 relative motion is implemented in the latest snapshot:
http://www.libsdl.org/tmp/SDL-2.0.zip