[PATCH weston 4/8] shell: Update bindings to conform to pointer axis protocol

[Jonas Ådahl]

On Thu, Oct 4, 2012 at 12:47 AM, Daniel Stone <daniel at fooishbar.org> wrote:
> Hi,
>
> On 29 September 2012 19:31, Jonas Ådahl <jadahl at gmail.com> wrote:
>> Ok, so what I'm trying to do is to enable what people call "smooth
>> scrolling" on an input level, meaning that scrolling is not based on
>> discrete arbitrary "steps" but on a more fluid motion. These types of
>> events makes most sense for certain types of step-less scroll wheels
>> and touchpads and I'll try to explain why.
>
> I agree it makes perfect sense, but note that axis events are already
> fixed-point, so you already get fairly fluid motion (motion in units
> of 1/256th of a wheel 'chunk', i.e. already subpixel).  The only
> advantage of making it pixel-based is that clients no longer have to
> do the multiplication.  But some applications don't want to smoothly
> scroll by pixels, and instead just want to, e.g, flip a page, every
> time the scroll motion passes a certain threshold.
>
>> When axis events are discrete steps, there is indeed little need to
>> relate to any kind of coordinate space except knowing what is "up" and
>> what is "down". A step can only be 1 or -1, thats it. This is how it
>> traditionally works in X11 (except XI2 I think supports non-discrete
>> axis events).
>
> XI2 follows exactly the same approach of offering scroll events in
> units of wheel chunks, except with a little more precision (using
> 16.16 fixed-point rather than 24.8).
>
>> If one wants to have axis events that more resemble smooth motions,
>> such as the ones emitted by those step-less scroll wheels or
>> touchpads, one needs to specify what the events actually mean, since
>> they are no longer only limited to 1 and -1. To do this, if we specify
>> an axis event to be a vector along an axis in a coordinate space
>> identical to motion events, we can create axis events that relate to
>> some measurement already known to both the compositor and client. A
>> step-less scroll wheel would transform its scroll events to a motion
>> vector measured in pixels and a touchpad would simply emit an axis
>> event as it would emit a motion event when scrolling. A client could
>> then read these events and can scroll its view by that amount of
>> pixels specified by the value parameter.
>
> I don't think this change makes much difference; the key is really
> just tuning the acceleration in the server (usually so it has a little
> more initial resistance and dampens low speeds, but accelerates
> dramatically at high speeds).  I'm pretty ambivalent about this.
>

The major difference between the (even smooth) step-based approach is
that it makes it possible to have scroll events that "feel" the same
as motion events (again, talking about touchpads here). By scaling
down the motion vector it would make it more or less impossible
without communicating factors to get axis events as if they were
motion events.

I think step based scrolling can be useful as well, but I think its
use cases are different from scrolling view ports. For example games
probably want to make use of scroll steps to change some state, but
wont do so with a the fractional steps. I'd say that having another
type of axis (say "horizontal/vertical step") for those types would
make more sense.

Jonas