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

[patch] macOS 10.12: small scrolls (1 wheel notch) don't generate events #2253

SDLBugzilla opened this issue Feb 11, 2021 · 0 comments


Copy link

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: HG 2.1
Reported for operating system, platform: Other, x86

Comments on the original bug report:

On 2016-09-21 17:47:09 +0000, Eric Wasylishen wrote:

Created attachment 2566
proposed fix

If I run the "testrelative" SDL demo with "--info all", rolling the scroll wheel one "notch" doesn't generate a scroll event. If I keep rolling it, I will start to see scroll events logged. This is with a logitech G400, or a microsoft ergonomic mouse.

What's happening is, in Cocoa_HandleMouseWheel the deltaY for
scrolling the scroll wheel one notch is 0.00172424316. SDL adds 0.9 to
that, and the resuting value is truncated to an int which results in

I don't think this happened in OS X 10.11.

Attaching a patch that uses floor/ceil instead of adding/subtracting 0.9. I'm not sure if the use of 0.9 was to deliberately filter out scrolls with a abs(delta)<0.1, or if it was just an accident.

On 2016-09-21 23:45:02 +0000, Martijn Courteaux wrote:

This problem should be resolved once someone finally decides to take a look in my precise scroll events patch ( You could use that patch instead for accurate floating-point scrolling amounts.

On 2016-09-24 16:31:13 +0000, Alex Szpakowski wrote:

Thanks Eric, this should be fixed as of

(In reply to Martijn Courteaux from comment # 1)

This problem should be resolved once someone finally decides to take a look
in my precise scroll events patch
( You could use that patch
instead for accurate floating-point scrolling amounts.

That's a separate issue - this particular bug is about a regression in SDL due to a change in macOS. Also I'm not sure your patch handles precise scrolling properly in macOS since it doesn't make use of -[NSEvent scrollingDeltaX/Y] on 10.7+.

On 2016-09-24 17:13:03 +0000, Martijn Courteaux wrote:

@alex: I'm not sure what the difference is between deltaX and scrollingDeltaX. I can try scrollingDeltaX/Y tomorrow. However, I'm using my patch on macOS Sierra for over a month now, and works fine. However; I had to add a factor 5 to make things scroll at the normal speed on both macOS Sierra and OS X. I'll have a look at the "preferred way" with scrollingDeltaX, and hopefully this will fix the factor 5-ish slowness.

On 2018-03-09 03:01:52 +0000, Eric Wasylishen wrote:

This bug was reintroduced by

The steps to reproduce are the same: run the "testrelative" SDL demo with "--info all",
connect a USB mouse with a scroll wheel, and roll the scroll wheel one "notch". You'll get log output like:

testdraw2[1644:67222] INFO: SDL EVENT: Mouse: wheel scrolled 0 in x and 0 in y (reversed: 1) in window 1

As far as I can tell macOS doesn't have an API for getting the number of "wheel notches"; I get a deltaY of 0.100006 for one "notch", and it's heavily accelerated (if you roll the wheel quickly you'll get large deltas). So NSEvent's deltaY is only meant to be used for scrolling a scroll view, with the given distance in points, not something like selecting an item in a game.

Maybe looking at the IOHIDManager API is the correct solution here?

On 2018-03-09 03:06:03 +0000, Eric Wasylishen wrote:

Created attachment 3190
Proposed patch

Here's a temporary patch that at restores the foor/ceil in Cocoa_HandleMouseWheel.
Not ideal, but at least it restores the ability to scroll one notch of a mousewheel.

On 2018-03-11 05:15:18 +0000, Sam Lantinga wrote:

Patch applied!

This seems like a reasonable workaround, giving people the behavior they would expect from the API. Feel free to close this if you think this is sufficient for the long term.

On 2018-03-12 04:40:45 +0000, Eric Wasylishen wrote:

Thanks! I think this can be considered closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

1 participant