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

[Peter Hutterer]

On Fri, Jun 10, 2011 at 09:00:37PM +0200, Simon Thum wrote:
> 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.

yeah, it's going to be like VGA all over :)
Does anyone actually know what the difference is between WXGA+ and WUXGA? 
Other than that one is more ultra than the other one is plus? Or we could
pull a USB and do Full Res and High Res and then laugh about all the suckers
that confuse the two.

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

checked the code again, right now there's only one matrix per event.
(and now you're right again with the misnaming ;)
the scale matrix is the _whole_ matrix (transform + scale), the transform
matrix is the pure transformation only. so the code is roughly:

if (relative)
    matrix_mult(dev->transform)
else if (absolute)
    matrix_mult(dev->scale)
else
    stop space-time and restart with big bang

Cheers,
  Peter