[PATCH] configure: set X render animated cursors optional

Tiago Vignatti tiago.vignatti at nokia.com
Wed Sep 2 04:16:10 PDT 2009


On Tue, Sep 01, 2009 at 10:31:39PM +0200, ext Keith Packard wrote:
> On Tue, 2009-09-01 at 20:37 +0300, Tiago Vignatti wrote:
> > The real issue is to not bother with cursors related code when I don't in
> > fact need... cursors!
> 
> Fair enough. I see a couple of options here:
> 
>  1) more DDX entry points to handle animated cursors. Your DDX would
>     do nothing at all, others could move the animation into the kernel
>     or even hardware.
>  2) Full build-time 'no cursors' option which completely disables all
>     cursor images.
>  3) Specific build-time 'no animated cursors' option, this seems 
>     sub-optimal as it leaves lots of cursor code still running.

I'm not sure if you've seen these options as exclusive but for me they all
complete each other. Let the following environments: full cursor support; no
animated but only normal cursor (yep, it exists!); no cursor at all. 

So 1) would set modesetting or whatever cursor and give full cursor support;
1) together with 3) would cut off animated cursor and let only normal cursor,
and; 2) would totally remove the cursor support.

 
> I'm starting
> to wonder what level of build-time configurability we should have
> though.

I share the same thoughts as you here, Keith [0]. For instance, look some
recently commits that I've done to set autoconf options: 

    root at xeron:~/xserver# git shortlog --author=vignatti --since="3 months ago" |
    grep configure
          configure: Provide the --enable/disable-xaa option.
          configure: introduce --{enable,disable}-vgahw
          configure: introduce --{enable,disable}-vbe
          configure: introduce --{enable,disable}-int10-module
    root at xeron:~/xserver# 


And we can set much more build-time options like this (e.g. put as optional
the pci library, some network layers, now the vgaarbiter, etc) to configure
the only needed parts, depending how is the machine's environment. 

In the end it's funny: DDX is losing its meaning, we're targeting only one
DDX, OS dependent things are going away and Xorg is becoming a more scalable
server :)


Cheers,

[0] Has someone already thought in a kbuild like, with a .config file and all
the beauties there? Don't know if it's feasible for the server, but at least
sounds cool.

            Tiago


More information about the xorg-devel mailing list