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

[Simon Thum]

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