[PATCH dix] dix: Added a "flat" acceleration profile that provides a linear pointer response.

[Simon Thum]

Hi Orhan,

please answer to all, makes life easier for everyone. I just saw that
mail by incident.

On 03/29/2011 04:41 PM, Orhan Kavrakoglu wrote:
> On 03/29/2011 02:56 PM, Simon Thum wrote:
>> It's technically correct, and I welcome people to patch it into distros,
>> but for master I'd prefer a conceptually clean solution. But if it turns
>> out there's no support for the concept as described, we should probably
>> add it to master (given you provide a man page entry).
>>
> 
> I see. Unfortunately, I'm nowhere near familiar enough with the input
> code to implement this. Though I'm willing to try, it will take some
> time, to say the least. (Some reading pointers would be great, at this
> point.)
Well, it's an RFC by Peter at the moment, AFAIK not much to read. I'll
add a bit to my idea FYC. The concept would probably use pixman and
list.h-lists and look something like:

struct TransformChain {
   Bool is_dirty;
   Bool is_unit;
   struct TransformNode* chain;
   pixman_f_matrix transform;
}

struct TransformNode{
   pixman_f_matrix transform;
   struct list *prev, *next; /* see list.h */
}

/* prepare matrices, don't malloc as we call this from the event loop */
Bool PrepareTransform(TransformChain* tc) {
  if (tc->is_dirty) {
    // squash chained matrices together (pixman_f_matrix_multiply or
so), supply unit if no matrices are there
    tc->transform = result;
    tc->is_unit = pixman_f_matrix_is_unit(tc->transform);
    tc->is_dirty = false;
  }
  return !tc->is_unit;
}

// ... helpers to prepend and append transforms, setting the dirty flag,
init etc.

struct DeviceInt {
  ...
  TransformChain raw_transform; /* the transform from driver input
("raw" in XI2) to nice-and-friendly XI/core X coordinates */
  ...
}

In GetPointerEvents(), we'd apply the transform like

if (PrepareTransform(&dev->raw_transform)) {
   // apply
} else {
   // fast path: just copy over
}

Drivers could use that or have an own chain if they like to.
Each linear transform we want to have could simply be modeled as a node
in this chain. Due to affinity, this would even include the transform
matrix we have in place for abs mode already.

Technically, we'd first need to resolve how
dev->valuators->last.remainder is handled, but that's not really hard.
Mostly we'd need to kick it by streamlining the sub-pixel processing.

Peter, do you have any plans in that direction (subpixel)?


> 
> There's another thing: The profile I posted is equivalent to the "none"
> profile (-1) when acc = 1.0. Do you think it is feasible to merge the two?
I don't really see a point in that. In a sense, "flat" _is_ "none", but
there's more gain from an approach as outlined above. Acceleration does
scaling as a historical necessity, but that doesn't means it's a good idea.

> 
> As this was my first patch, there was bound to be something missing. I
> will update the man entry in any case.
Just go ahead. As said, it's probably suitable for anything but master.

Cheers,

Simon

> 
> Thanks for your help,
> Orhan
> 
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
>