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

[Peter Hutterer]

On Wed, Aug 17, 2011 at 11:33:51AM +0100, Daniel Stone wrote:
> 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.

and to do so requires the clients to interpret the device data correctly -
i.e. knowing about the step increment.

> > > > 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 the same data on two axes just so the clients receive normalised data on
one axis? seems simpler to just flag one of the axes and tell the clients
what the driver thinks is one scroll event on that axis.

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

yeah, fair enough. see the latest patch though which simply adds those few
pieces into a new class and thus makes it a) configurable by the driver and
b) accessible to the client
http://patchwork.freedesktop.org/patch/6738/

Cheers,
  Peter