False positives with twist scrolling

[scatterthought]

As discussed in Discord, some users experience false-positive twist scrolling while moving the pointer. Anecdotally, this seems to affect users who drop their fingers lower toward the centre of the ball when rolling it. If our next movement is at a hard angle, we end up twisting the ball. My suggestion would be to require that the ball must be stationary in order for twist scroll to engage.

https://discord.com/channels/1406886533063118848/1427297722687291514/1438680494408466625

At @efogdev's request, I've opened an issue for this. Please comment if you are also experiencing it or want to contribute to the solution/testing.

Thanks!

[efogdev]

I'll leave some comments immediately; while that sounds simple, I've encountered many problems implementing such a filter with code. First, can you define "stationary"? Because before twisting, you will unavoidably move the pointer a bit. Second, if we're talking about the case when you change your direction in a sharp angle, that will have a moment of no movement either. How do you see distinguishing those? We'd need to predict out future intentions I guess.

[scatterthought]

Yeah, I totally get what you're saying. There's definitely a predictive element to it.

I originally suggested that a delay be required between pointing and scrolling. So perhaps the if statement is:

"If no movement for x milliseconds, twist scroll activation enabled for y milliseconds."

I'm going on the theory that most (all?) users will have a deliberate pause when they switch from pointing to scrolling, in the same way we do going from scrolling to pointing. But since we expect some random movement when someone tries to twist, we'd add a second variable to create a buffer period during which twist scroll is allowed to activate. After that, we can assume the user does not want to twist scroll.

In any case, it should be a feature that can be enabled/disabled, since it doesn't affect everyone.

[Cwiiis]

This does affect me, I frequently unintentionally scroll small amounts, but as always seems to be the case with these sorts of issues, it's difficult to reproduce intentionally. I would say that as things are now, if any change in behaviour made it more difficult to twist-scroll, I'd likely prefer the false triggers...

@scatterthought's idea in the comment above this sounds like a good start. If you've performed either a scroll or movement for more than X milliseconds (50?), lock to that particular action until the mouse is stationary for Y milliseconds (probably the same as X, but maybe there's some reason it should differ?). I think for this to not be annoying, there needs to be some threshold for 'stationary' - I don't necessarily lift my hand off the trackball to switch between these gestures and the endgame with BTUs is particularly sensitive to movement. It'd be annoying to require true stillness to break the gesture type lock.

[efogdev]

You see, your "if no movement for x milliseconds, twist scroll activation enabled for y milliseconds" also covers sudden change of the direction.

"If you've performed either a scroll or movement for more than X milliseconds (50?), lock to that particular action until the mouse is stationary" has exactly the same problem.

[scatterthought]

I think @Cwiiis was paraphrasing what I'd suggested, so I agree that they'd be the same thing. But I'm struggling to see the problem.

The x variable is specifically intended to be the threshold. Sudden changes of direction would happen faster than x (preventing twist scroll), and stoppages would be slower than x (allowing twist scroll).

I don't know if the 100 millisecond buffer that's in place for scroll-to-pointer movement is enough of a threshold, which is why I'd make them separate settings.

[robwalgen]

Per @efogdev's request to comment on this when we experience false positives:
I had the same issue, there were a lot of false positives in the beginning. After a couple of days, they became less and less frequent, I believe it was just a habit (coming from an Adept) to rotate and move the ball at the same time. Maybe worth noting: I never trigger twist scroll by rotating the ball near the buttons, only ever with 2nd and 3rd finger from the top (hard to describe in words how exaclty, I added a short video showing the 2 ways I twist scroll). So the movement is really similar to moving the ball regularly.

twist_scroll.mp4

Yesterday, I switched the config in config/efogtech_trackball_0.conf to these values, as recommended on the Discord server:

CONFIG_POINTER_2S_MIXER_EMA_ALPHA=7
CONFIG_POINTER_2S_MIXER_DELTA_Y_OVER_TRANS_MAG_MUL=5

and didn't have any false triggers since.

That being said, it's also a bit harder to trigger twist scroll (obviously), so I will have to learn to be more precise. Maybe I'll go back to the original value (CONFIG_POINTER_2S_MIXER_EMA_ALPHA=10) for ease-of-use, because there were very few false positives by now.

[scatterthought]

After testing it for awhile, I agree with @robwalgen. This definitely reduced my false positives, but I'm not sure the trade-off is worthwhile. I might try adjusting the values a bit to see if there's a butter zone for me.

@efogdev, can you explain a little what the values do, so that I'm not flying completely blind?

Thanks!

[efogdev]

EMA_ALPHA is basically a smoothing factor: https://en.wikipedia.org/wiki/Exponential_smoothing (it's being divided by 100)

DELTA_Y_OVER_TRANS_MAG_MUL is the multiplier part of the check, to detect scroll it should satisfy the equation TWIST > TRANSLATION * MUL / DIV and DIV is 3 by default. So it's most likely this value that contributes to the harder detection most.

[scatterthought]

I changed the values to 9 and 4:

CONFIG_POINTER_2S_MIXER_EMA_ALPHA=9
CONFIG_POINTER_2S_MIXER_DELTA_Y_OVER_TRANS_MAG_MUL=4

To make up for the slight delay, I also cranked up the step size and limit for scroll sensitivity, matching it to pointer sensitivity (5-40% in 5% steps).

step = <50>;
min-step = <1>;
max-step = <8>;

So far it feels pretty good. Hopefully this will be the solution for me.