Re: On complexifigurability

2011-04-06 Thread Peter Hutterer
On Tue, Apr 05, 2011 at 06:37:47PM +0100, Daniel Stone wrote: It's about organization of the code really, which leads to correct driver API usage, so we could talk about deprecation and proper versioning of unused/old/unmaintained drivers - we would be enforcing ourselves to use correct

On complexifigurability (was: Re: [PATCH dix] dix: Added a flat acceleration profile that provides a linear pointer response.)

2011-04-05 Thread Daniel Stone
Hi, On Tue, Apr 05, 2011 at 04:30:38PM +0300, Tiago Vignatti wrote: On 04/05/2011 04:05 PM, ext Daniel Stone wrote: On Tue, Apr 05, 2011 at 03:45:58PM +0300, Tiago Vignatti wrote: and bonus points if we could disable/enable the acceleration architecture in compilation time also. If we get

Re: On complexifigurability

2011-04-05 Thread Tiago Vignatti
Daniel, On 04/05/2011 05:51 PM, ext Daniel Stone wrote: On Tue, Apr 05, 2011 at 04:30:38PM +0300, Tiago Vignatti wrote: 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.

Re: On complexifigurability

2011-04-05 Thread Daniel Stone
Hi, On Tue, Apr 05, 2011 at 08:21:43PM +0300, Tiago Vignatti wrote: On 04/05/2011 05:51 PM, ext Daniel Stone wrote: Sure, but at some stage there has to be a limit. Every configuration option has a cost: in making the source files larger by putting #ifdefs everywhere - and you could argue we