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

[Daniel Stone]

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.

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?

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

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

Cheers,
Daniel