[PATCH] mouse wheel acceleration

[Simon Thum]

Am 07.09.2010 17:44, schrieb Albert Zeyer:
>  Hi Simon, Tiago and list,
> 
> Simon Thum:
>> Hi Albert,
>>
>> the code looks good to me in general. Besides some technicalities,
>> there may be a larger problem: There is an effort to support wheels with
>> higher precision (github.com/x-quadraht/pscroll).
> Ah, quite interesting. While my solution worked quite fine, I was
> thinking about that this would exactly be the next step because
> scrolling with such higher resolution would be much higher.  This is
> also the main difference now if you scroll on MacOSX compared to my
> solution: The minimal scrolling-step on OSX is one single pixel.
> 
>> Whether that
>> particular solution will make it or not, it would be cool to handle
>> wheel acceleration in one place.
> In one place with what? You mean together with pointer acceleration?
Not exactly, just in one place with other wheel-like things. Like the
smooth wheel ;)

> 
> pscroll does on Xorg the following:
> 1. In the Xorg server, it adds a way to add axes with no integration (I
> guess so that they are not interpreted as pointer position).
> 2. In each mouse input driver code (so far only evdev and synaptics), it
> creates additional axes for the wheel and in addition to the standard
> wheel button events (4 and 5), it sends axis motion events for the wheel
> axes.
> 
> If the wheel acceleration is based on those wheel axes, it means that
> the acceleration works only for applications which support pscroll.
No - you've shown that accel may work for non-smooth wheel signaling
mechanisms as well. But at the least behaviour should be comparable with
any smooth variant signaled as well. So IMO it makes sense to route them
over one code path which adapts to the native precision, and later split
them up into axis/button-based events.

> That is the problem if it was done wrong in the first place (why was it
> done with button events at all? only because it was simpler to do?) and
> now everythings depends on that. Of course that is not a reason to not
> fix this finally.
It's because initially, X didn't really know those buttons. They were
ordinary buttons on a mouse, so what? X supports more buttons than you
have fingers! Some apps understood it, and it became a de-facto
standard. Today the kernel understands it, and the old crap is being
emulated.

> It might be a reason though to implement the mouse wheel acceleration in
> a way that it works with both ways, i.e. it accelerates also those wheel
> button events (like what I have done).
Exactly.


>> I don't think the scheme mechanism is
>> especially suitable here, IMO one can achieve a much higher degree of
>> code sharing.
>>
> Code sharing with pointer acceleration?
Yep - actually the accel context can accelerate anything which emits
relative events. Some of your boilerplate code needs to change,
obviously. Just look at the DeviceVelocityRec - it doesn't really care
about pointers.


>> Most of that is done in the ptrveloc equivalent as well. You could
>> instantiate a PointerVelocityRec using InitVelocityData (the structure
>> is a bit tied to pointer accel but I'm cleaning that up.) and go like:
>>
>> switch(button) {
>>     case 4: x =  0; y = -1; break;
>>     case 5: x =  0; y =  1; break;
>>     case 6: x = -1; y =  0; break;
>>     case 7: x =  1; y =  0; break;
>>     default: /* unknown wheel button number */ return;
>> }
>> ProcessVelocityData2D(ptr, x, y, timestamp);
>>
>> Besides having a time-tested algorithm, you could adapt to a smooth
>> wheel vs. button-based wheel by simply adjusting the PtrVelocityRec
>> and some boilerplate code.
> I actually thought of that while I was investigating how I should
> implement it.
> 
> The reasons I did not do it this way was:
> 
> 1. The pointer acceleration is much more complicated because each motion
> event can have a different distance. For mouse wheeling (without
> pscroll), it was always the same. This simplifies the whole calculation
> a lot.
Yes - but OTOH this is integration potential for free.
> 2. The pointer acceleration code was highly pointer specific. It heavily
> used those valuators.
Yes again - but only in the scheme function. That's just wiring it up
with the pointer - as said, the acceleration context is pretty agnostic
(I'm cooking up a patch to get rid of the last field ATM)

> 3. I thought about that less is sometimes more. I.e. that it might be
> overkill to have different acceleration profiles/schemes for wheel
> acceleration.
You don't need to wire up those for wheel acceleration. In fact, I
wondered why you had remnants of the scheme code in place.

> 4. I was not sure if all the code allowed me to have the acceleration
> the way I thought about it. More details:
> 
> Currently, in my implementation, the acceleration code is quite simple.
> In case that the user scrolls in the same direction (and dt > 0):
> 
>    dt = evtime - velocitydata->lastWheelEvent[axeIndex].time;
>    *add_num_button_presses = (int) (velocitydata->speed_mult / dt);
> 
> And that is capped by some maximum (max_speed). This can be done that
> simple because of the single button events. If you translates that to
> velocity, it basically is this:
> 
>    v_new = v_old * (1 + min( int( speed_mult * v_old ), max_speed ) )
> 
> If pscroll is being adopted, this situation changes of course. Then, it
> would not very difficult anymore to reuse that code. My first two points
> may become invalid (whereby I still don't really like that
> valuator-stuff in that code). My third point may hold, though (well,
> that is arguable). I'm not sure about the fourth point but with pscroll,
> it is anyway not possible anymore to do the calculation that simple.
Yes, and when it gets more complicated you're likely to reinvent the
wheel here.

> When will pscroll be adopted? Or will it? When/how is such a decision
> made? Will it be soon? If not, what are the problems with pscroll? If
Mostly technical problems AFAIK - it doesn't apply to master and it
seems to collect dust (I may be wrong ITR).

> not, might it be a solution to adopt my wheel acceleration patch for now
> and to reimplement (just with shared code from pointer acceleration) it
> as soon as we have something like pscroll?
I can't speak for peter but I'd rather see something with a little less
code duplication. And I don't think "we'll fix it later" will buy you
cheering applause on the list.

Don't get me wrong - IMO this patch has good chances, but it needs a
little more love.

> 
> Tiago Vignatti:
>> I'm not sure about the feasibility but implementing all the velocity
>> framework in the client side seems to solve this kind of issues.
> I don't think that it would be a good idea to have it on the client
> side. We also don't have pointer acceleration on the client side (well,
> this may be bad example because we also can't because the mouse pointer
> is handled server side). But I think it would be a quite bad idea to let
> each application / framework implement that itself.
Same here - some consistency can't be bad.

Cheers,

Simon