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

[Peter Hutterer]

On Tue, Aug 16, 2011 at 12:58:49PM +0100, Daniel Stone wrote:
> Hi,
> 
> On Tue, Aug 16, 2011 at 04:08:24PM +1000, Peter Hutterer wrote:
> > This isn't true in most cases, especially where physical scroll axes are
> > involved. Wacom Intuos4 scroll rings have a unit size of 3.0 and the driver
> > historically sent one scroll event per 3.0 increment or decrement. Mapping
> > one scroll event to 1.0 makes the ring mostly unusable through legacy
> > button events.
> > 
> > Leave the exact mapping to the driver.
> 
> Err, but then it makes smooth scrolling useless to clients.  Does -1.0
> mean to scroll up one unit, or one third of a unit? Or one tenth of a
> unit? Or one pixel? Who knows.  In lieu of a strict convention, you can
> pretty much guarantee that clients will use 1.0 as either one button
> press or one pixel.  Neither of those are one third of a button press,
> and they're different enough to pretty much make the whole thing
> pointless.

theory goes that at some point we can configure clients to adjust the scroll
factor on a per-device basis which arguably is the point of smooth
scrolling, right? see below though.

> If you don't want to normalise to [0..1.0] in the drivers before posting
> events, can we at least use the axis range (or perhaps re-introduce
> resolution) so we have some kind of useful standardised behaviour
> between clients?

re-introduce? evdev does resolution since 2.5 (April 2010), wacom does too
and IIRC synaptics even adjusts for different x/y resolutions, or at least
did at some point. Anything I'm missing here? XI1 and XI2 both send
resolution to the client too.

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

Cheers,
  Peter