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

[Simon Thum]

On 06/09/2011 02:14 AM, Peter Hutterer wrote:
> On Wed, Jun 08, 2011 at 07:30:52PM +0200, Simon Thum wrote:
>> (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?
> 
> The plans are mostly to have sensible defaults and push everything else into
> run-time configuration in the desktop environment.
> 
> There is no straightforward way to do this right now but we do support udev
> tags. so in theory, udev rules could check for high-res devices and could
> assign a free-form tag to it. Then you can have your InputClass section
> use MatchTag on this to apply a CD. Not ideal though since the resolution is
> a numeric value and not easily expressed in a tag.
> 
> I think we're much better off increasing the CD to a higher default if the
> resolution provided is high enough.
That would be driver/os-specific, I guess. The labels are portable at
least in principle,
so e.g. high-res / very-high-res / ultra-xtra-res / ... might fit the bill.

> I think you misread here. there are two matrices in the patch, "transform"
> and "scale". Transform is the one set by the client and applied to all
> devices including relative onces.. Scale is the one only applied on absolute
> devices to get the mapping into the current desktop dimensions (so that
> transformation can be specified as [0..1] instead of [0..current width]).
> That seems like sensible naming, isn't it?
I must have been monday.

But then you need two matrix muls per hw event. If more than scale and
free transform get on the list, it may make sense to squash all into
final abs and rel matrices. But that's for then.

Cheers,

Simon