[PATCH RFC inputproto] Remove requirement for 1.0 == 1 unit of scrolling

[Peter Hutterer]

On Wed, Aug 17, 2011 at 08:41:22AM +1000, Peter Hutterer wrote:
> > > I noticed this only works in the synaptics driver with a strict mapping
> > > because it uses a virtual axis and does the normalization by dividing by
> > > scroll_dist_vert (which is the scroll unit size). This can't work with those
> > > devices that have real scroll axes though.
> > 
> > It can, you just need to normalise the values, much like how the Wacom
> > driver normalised three units of axis movement to one button
> > press/release.  Or provide the clients with enough information to do it
> > predictably themselves.
> 
> normalisation imo only makes sense if the scroll axis is a pure scroll axis,
> otherwise the real value range (and resolution:) can be valuable. easiest
> example here, the Intuos3:
> http://upload.wikimedia.org/wikipedia/commons/6/63/Wacom_Intuos3_A5.jpg
> The two strips left/right are typically used for scrolling but we've also
> been sending valuator data to the client. A client may just map each strip
> directly to a control instead.
> 
> So, back to the client configuration. IMO if we want the emulation be
> handled by clients automatically, we should expose the normalisation factor.
> Which could be either a property or another extension to the
> xXIValuatorClassInfo, the latter of which is better if the whole thing is
> ingrained in the protocol anyway and we require the server to emulate.
> 
> > > tbh, I'm beginning to wonder if automatic emulation code in the server is a
> > > good idea after all.
> > 
> > Yes, because otherwise all drivers with smooth scrolling will be doing
> > the emulation anyway: not much point in completely breaking all legacy
> > apps, which right now is all of them.
> 
> right, that's what I meant, add a new API for drivers to send scroll
> emulation events marked with XIPointerEmulated.

and another issue, because it's so much fun. since the strips as pictured
above do not have a clear horiz/vert association like a mouse wheel has,
they have been configurable for a while. This suggests that an extra driver
API would be the best solution here to determine which hardware event
results in a scroll event.

I haven't come up with a useful way of how to teach clients that axis up is
a scroll left event...

Cheers,
  Peter