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

[zt.tmzt at gmail.com]

Interesting approach, similar to GL using a series of matricies.

This would fit perfectly into an event driven input infrastructure I'm
researching, with the low level protocol drivers handling that end and a
series of filters or chains processing and transforming the input before
handing it off to the internal event system.

--
Timothy Meade
tmzt on freenode
On Apr 5, 2011 7:08 AM, "Simon Thum" <simon.thum at gmx.de> wrote:
> 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
>>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20110405/8bb4b3e0/attachment.html>