On 04/05/2011 02:41 PM, Daniel Stone wrote: > Hi, > > On Tue, Apr 05, 2011 at 02:07:33PM +0200, Simon Thum wrote: >> 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: > > So, at the risk of sounding like a bit of an arse here ... what's the > planned usecase? Well, numerous: - rotation - translation (e.g. coupling device to a screen for touchscreens) - scaling (as orhan requested) - offload ConstantDeceleration (essentially that's scaling as well) - retain the matrix we currently have combined with the above - x/y flipping
Making it flexible will give that to drivers who want it as well. Above all, some of these require sub-pixel processing, which we can a) get wrong or b) spill all over the codebase or c) unify in virtually one point. c) is what you get here. It will practically guarantee you can combine all those without testing every combination (with every driver). > > I ask mainly because we already have a very extensively-engineered > pointer acceleration architecture, where 90% of the code could probably > be removed without more than seven people noticing. I'm kind of wary of > adding another possibly-overengineered transformation architecture where > the only current feasibly-demonstrated usecase (TTBOMK) is rotation. Well, I'm suggesting it also because offloading scaling could greatly simplify acceleration, as scaling is the only reason to keep around schemes (the only use-case of the old scheme not completely replaced). > > Of course, if we could demonstrate a real need for this, then great. > But I'm kind of nervous about making the input path more complex still, > just because we can. As I pointed out, I'm also seeing some potential for simplification. I think I've seen the features above requested or implemented (in some of the drivers). An infrastructure will yield all kinds of benefits to users and developers, which IMO could easily offset any complexity gains. I also don't think complexity will grow a lot since pixman will do the tricky bits (at least it looks capable of). Consider that alternatives don't come for free either. So the question is who buys those arguments ;) Cheers, Simon _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
