Smooth scrolling

[Simon Thum]

Am 07.04.2010 02:46, schrieb Max Schwarz:
> Hi Simon,
> 
>> The problem I see is that it's really degrees or cycles on a wheel, or
>> some distance on more freaky devices (e.g. pad on mouse). Maybe it's
>> preferable to add some (user-overrideable) axis information which
>> toolkits may use to ultimately do something sensible.
> 
> Well the way it is now the driver maintainers decide how often they sent the 
> scroll button presses. I thought I would keep it that way and let them decide 
> how many pixels to scroll. Of course the user would have to be able to change 
> that setting.
I'm unsure I get it. I assumed you were breaking up the 1:1 relation
between scroll button presses and your scroll valuator, such that the
valuator may work with much higher precision while button-scroll remains
working for apps unaware of the scroll valuator(s). Is that intended?

> Anything else would create problems in interpretation later on. For example, 
> equal distances on small and huge touchpads could mean very different amounts 
> of pixels to scroll.
> In addition to that, users should be able to change the amount of scrolling on 
> a per-device basis, so the conversion should be made in driver-space in my 
> opinion.
I guess a input device property would be fine for that.

> 
>> Now for my suggestion: when things work fine (i.e. not now ;), you may
>> want to add acceleration to the scroll wheel. The ptrveloc.h header
>> contains the necessary methods to create an 'acceleration context', feed
>> it with the wheel data and map it over acceleration functions. I think
>> some windows drivers implement such a feature.
> 
> Thank you very much for the suggestion. I had thought of acceleration before, 
> but as you said, I first have to get basic event reporting working.
> ptrveloc.h is a very good hint though, X.org is really a place to get lost in 
> :-)
> 
> Max
>