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

[Peter Hutterer]

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.

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

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?

Cheers,
  Peter