[PATCH] mouse wheel acceleration

[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?

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.

It might be quite confusing/annoying for the user if it works in some 
application and not in others. Whereby, if you patch GTK and Qt, you 
already have most of the applications (except those who are statically 
linked and/or use a different framework).

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 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).


> 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?

>> +/********************************
>> + *  acceleration proc
>> + *******************************/
>> +
>> +
>> +void
>> +ProcessWheelAccel(
>> +    DeviceIntPtr dev,
>> +    int button,
>> +    int* add_num_button_presses,
>> +    int evtime)
>> +{
>> ...
>> +}
> 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.
2. The pointer acceleration code was highly pointer specific. It heavily 
used those valuators.
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.
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.

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 
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?

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.

Cheers,
Albert

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100907/d1d7bd98/attachment.htm>