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
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
