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 <div class="gmail_quote">On Apr 5, 2011 7:08 AM, "Simon Thum" <<a href="mailto:simon.thum@gmx.de">simon.thum@gmx.de</a>> 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 >> >> _______________________________________________ >> <a href="mailto:xorg-devel@lists.x.org">xorg-devel@lists.x.org</a>: X.Org development >> Archives: <a href="http://lists.x.org/archives/xorg-devel">http://lists.x.org/archives/xorg-devel</a> >> Info: <a href="http://lists.x.org/mailman/listinfo/xorg-devel">http://lists.x.org/mailman/listinfo/xorg-devel</a> >> > > _______________________________________________ > <a href="mailto:xorg-devel@lists.x.org">xorg-devel@lists.x.org</a>: X.Org development > Archives: <a href="http://lists.x.org/archives/xorg-devel">http://lists.x.org/archives/xorg-devel</a> > Info: <a href="http://lists.x.org/mailman/listinfo/xorg-devel">http://lists.x.org/mailman/listinfo/xorg-devel</a> </div>