On 04/05/2011 01:34 PM, [email protected] 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" <[email protected]> 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 >>> >>> _______________________________________________ >>> [email protected]: X.Org development >>> Archives: http://lists.x.org/archives/xorg-devel >>> Info: http://lists.x.org/mailman/listinfo/xorg-devel >>> >> >> _______________________________________________ >> [email protected]: X.Org development >> Archives: http://lists.x.org/archives/xorg-devel >> Info: http://lists.x.org/mailman/listinfo/xorg-devel > _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
