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

Tiago Vignatti tiago.vignatti at nokia.com
Tue Apr 5 06:30:38 PDT 2011


On 04/05/2011 04:05 PM, ext Daniel Stone wrote:
>
> On Tue, Apr 05, 2011 at 03:45:58PM +0300, Tiago Vignatti wrote:
>> On 04/05/2011 03:41 PM, ext Daniel Stone wrote:
>>> 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.
>>>
>>> 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.
>>
>> agreed.
>>
>> and bonus points if we could disable/enable the acceleration
>> architecture in compilation time also.
>
> If we get to that stage, something is _badly_ _badly_ _badly_ _badly_
> wrong.  Rather than papering over the problem (assuming it is actually
> large enough to notice at runtime, which I'm not entirely convinced it
> is) and adding yet more alternate codepaths no-one will probably ever
> test, we could just make accel acceptably small ...

maybe you are right.

But my point is (well, always was) to chop off the server internal 
modules in parts so we can have a lean implementation for different 
purposes and cover everyone's desires. The testing and conformance could 
be stressed in a different way, but not just compiling and forcing 
developers to use the thing.

Actually, by implementation of X11 we can pick all client libraries, 
headers, the server itself and drivers. So what motivated you to break 
them in pieces, when you started the autotools conversion?

           Tiago


More information about the xorg-devel mailing list