Directfb Xorg server

[Mike Emmel]

On 5/31/06, Enrico Weigelt <weigelt at metux.de> wrote:
> * 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.
>
>
Right with the addition that the protocol handling code as I said is split
from the implementation this is important actually the design I'm suggesting
is similar to libxcb but in this case for the server.
The protocol side generally would except all messages and just default
to sending
a unsupported message or error so the default hook would be error.
You can ifdef it for custom builds but generally you won't.

Supporting the protocal lib is a must otherwise its not and X server :)
The rest is optional.


Mike

> 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/
> ---------------------------------------------------------------------
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>