Smooth scrolling
Simon Thum
simon.thum at gmx.de
Wed Apr 7 03:58:11 PDT 2010
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
>
More information about the xorg-devel
mailing list