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

[Daniel Stone]

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.

Cheers,
Daniel