Directfb Xorg server

[Enrico Weigelt]

* Mike Emmel <mike.emmel at gmail.com> schrieb:
> Lets refactor the servers so the DDX contains main not the DIX layer.
> So I can remove my hack.

ACK. The starting point of the code flow is an binary - specically 
for each separate server - called by the user. So main() also 
belongs there. If this function then calls some common code,
ie. argument parsing, okay ...

<snip>

> A lot of the conditionals in the DIX layer can be removed by having
> the ddx provide a list of function pointers to the dix during 
> initialization. 

ACK. Something like an ddx_callback_init() which gets passed an 
reference to an DDX_CALLBACK structure, where the actual function 
pointers sit.

> Right now the dix controls the flow of initialization if we reverse 
> this and let the ddx manage startup and make the dix a real library 
> default  functions. This will greatly reduce or eliminate all the 
> apping and unwrapping going on since the ddx knows the functions it 
> wants to call. Finally it would allow more extensions to be optional 
> since they can provide there own function lists to the DDX thence DIX 
> when loaded.

ACK. The server would be really modular.

<snip> 
 
> On the ddx side there is probably a new set of ddx common implementation
> code that was once part of the dix but this is now optional for the
> ddx layer and it provides example code for ddx implementations that 
> differ to dramatically from the norm to work.

That would be some libddx_common ...

<snip> 

> In my case I'd love to see the X protocal handling split out from the
> implementation
> this would allow a completely different server implementation. So dix
> splits into
> xprotocol or wire handling and sample event processing.
> 
> For example in dispatch.c ProcCreateWindow
> 
>      return BadValue;
>    }
>    pWin = CreateWindow(stuff->wid, pParent, stuff->x,
>                  stuff->y, stuff->width, stuff->height,
>                  stuff->borderWidth, stuff->class,
>                  stuff->mask, (XID *) &stuff[1],
>                  (int)stuff->depth,
>                  client, stuff->visual, &result);
> 
> If this call was done via a new function pointer
> say
> ddx->CreateWindow ....

100% ACK.


Okay, now lets start to nail it down! 

My roadmap suggestion:

1. introduce an DDX_CALLBACK structure and register_ddx_callback()
2. rename DIX' main() into dix_main() and add some main() to
   each DDX which just calls register_ddx_callback() and dix_main(). 
3. register_ddx_callback() initializes all fields with default 
   values and checks whether those callbacks are defined, which
   *must* be implemented by the DDX (aka have no default).
4. sucessively add DDX functions to the callback structure,
   let register_ddx_callback() init them and rename them,
   change all calling functions to use the DDX_CALLBACK structure
   instead.
5. sucessively move these functions completely to the DDX.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------