[PATCH 3/3] dix: support the transformation matrix for relative devices.

[Simon Thum]

(I removed some text)

>> I think "my" wiki page has a scenario for high-resolution mice, plus
>> some users asked for that. Perhaps the man page can be improved.
> 
> the problem with pointer acceleration is that the UI to tweak it is is
> suboptimal. yes, there's xinput but we don't have a ubiquitous GUI tool for
> a per-device CD. it'd be great if the default settings for each device would
> adjust accordingly.
> 
> evdev does report resolution if the kernel provides it, but only on absolute
> devices so far because that's all the kernel gives us.
The ideal way would be input sections - e.g. "do CD if resolution is
large". My reason for turning to HAL was that it lets such bits to be
kept in userland.

What are the plans on that frontier?

>> I failed to look at them, TB just shows me a mailto: url.
> 
> each email has a Message-ID header, that's what you can search on when
> someone posts this.
I guess I'm officially lame now.

>> What I'd drop are the schemes - and your transform would do away the
>> last reason to keep them - enabling us to do the following data flow:
>>
>> 1) derive velocity estimate from the raw data (that's read-only)
>> 2) transform relative
>> 3) multiply in acceleration
>>
>> If that coincides with daniel's patches (disclaimer: I didn't look at
>> them), we've gotten away with one API bump.
>>
>> Sounds fine?
> 
> yes, because unless I misunderstood it again, we can apply daniel's
> valuator_*_double patches and then just apply the transformation as
> originally proposed in this patch :)
> 
> plus the velocity estimate, but that's hopefully the simple bit.
That seems to work out. When daniel's patches hit master, I'll be
removing the schemes.

But please, don't name the relative matrix "scale". I fail to come up
with something more misleading...

Cheers,

Simon