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

[Daniel Stone]

Hi,

On Wed, Aug 17, 2011 at 08:41:22AM +1000, Peter Hutterer wrote:
> On Tue, Aug 16, 2011 at 12:58:49PM +0100, Daniel Stone wrote:
> > 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.

Well, the point of smooth scrolling was for scrolling to be smooth,
really.

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

Huh, I thought it was dropped in XI2, sorry.  OK, in that case I guess
we'd need to use resolution so clients have some sensible mapping.

> > > 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 at the moment, given that the scrolling and full axis range act
independently, why not just create a scroll axis as well? It's not
pretty, but no worse than what's already there now.

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

Sure, I'm fine with exposing it in the protocol.  Surely though if you
have different axes with different properties though, then it'd need to
be a part of the ValuatorInfo rather than ValuatorClassInfo ...

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

I don't see how this introduces anything other than additional
uncertainty and complexity, tbqh.  (Not to mention that it breaks the
nice property we have at the moment where real and emulated scroll
events have the same timestamp, as well as removing the possibility to
later do one-or-the-other delivery for smooth/emulated scroll events as
is planned for multitouch.)

Cheers,
Daniel