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

[Simon Thum]

On 04/05/2011 01:34 PM, zt.tmzt at gmail.com wrote:
> Interesting approach, similar to GL using a series of matricies.
Actually, I consider myself inspired by VRML (as mentioned in
http://lists.freedesktop.org/archives/xorg-devel/2011-March/020680.html). VRML
also specifies how to handle common transforms, a thing X should
probably align to.

> 
> 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.
Yeah, X isn't there yet. Note however that the approach could be scaled
up to what you describe. Does your research or implementation focus X?

Cheers,

Simon


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