Directfb Xorg server

[Mike Emmel]

On 5/28/06, Adam Jackson <ajax at nwnk.net> wrote:
> On Sunday 21 May 2006 04:53, Mike Emmel wrote:
> > There is and inital port of the directfb Xorg server is really rough
> > and not documented but
> > it worked for me serveral people are intrested in looking at the code
> > even it its current condition.
> >
> > It is located at.
> >
> > http://forjamari.linex.org/scm/?group_id=54
>
> Just got a chance to look at this today, and it seems mostly straightforward.
> For reference, I'm referring to:
> http://forjamari.linex.org/plugins/scmcvs/cvsweb.php/X11/xorg.patch?rev=1.5,cvsroot=futura
>
> Overall it looks like the only big issue is that the way the patch is done
> currently, you can't build the dfb ddx at the same time as any other ddx.
> Disabling building Composite/XF86VidMode/XF86Misc isn't going to be

XF86VidMode
I don't need this X has no control of the screen or display depths in
this implementation its strictly a network window manager in rootless
mode it should not be mucking with any video settings.

XF86Misc
Same X does not control the hardware and has no access

Composite
External composite managers are not supported there is no reason in a
rootless implementation to support composite managers composite
operations like window alpha
are supported internally via the directfb api's. Since directfb
modifies the window alpha according to its own algorithm its
impossible to correctly support composite in the rootless case with
windows thate are already being managed by the directfb window
manager.

Note external X11 windowmanagers are not  supported either.

The goal of this server is to support X11 applications integrated with
the native apps not server extensions that interfere with the native
window manager.

Now that does not mean someone can't build a similar X11 server off
the same code base
that does allow these extensions in general you will find that they
have so pretty bad side effects with the native which manage
composting vidmodes etc.

With that said this server should support a wide range of applications
as long as they don't interfere with the native window manager which
generally means uncontrolled access to the hardware or  controlling
the window stack. For those intrested in supporting the above
extensions regardless of there effect on directfb applications you
could certainly use most of the same code base. I'm not saying you
can't do it but I am saying it would result in some pretty bad
artifacts in the mixed application case.

Composite in particular is a bad extension the xwin does not support
it completely yet when they do it probably only makes sense in full
screen mode not sure what darwin supports its not clear. I'm sure the
interaction of composite with rootless xservers was not fully
explored.
Bottom line is it makes no sense in a rootless implementation were X
is not the window manager but simply a remote protocol for drawing the
contents of a window.
Agian I stress the same code base can be used to implement a X server
on directfb that allows this but thats not what I'm doing on reason
the server is on Futura and not being presented as a replacement for
the current directfb X server. I could very well be the person that
provides a more traditional server for directfb but thats not were
were going with futura.

WindowManager
As I noted earlier traditional X11 window managers are no longer
supported in this server.
I think you haven't realized that I'm sure it will raise some eyebrows.

I'm working on the window manager right now its in directfbWM.c and it
uses the changes
made to dispatch and window etc required to allow me to implement
what are traditionally
external programs embedded in the xserver.
The new window manager is based on metacity and will manage both
native directfb windows and x11 windows. Basically I'm spliting
metacity in half moving all the X11 specific code into the server  and
 porting metacity to directfb. The directfb wm will then interface
with the x11 side via  a api. This is one of the big reasons I needed
to be a shared lib since I'm actually loading the X11 server into the
directfb wm which itself is a shared lib.



> acceptable, nor is the -DMAIN=x11_main trick.  I'd have to look at the dfb
> ddx closer to figure out what to do there.
>
The problem is having main in the ddx it should be elsewhere. In any
case I need to build
as a shared library there should be no reason this is not possible.

One approach I could take is to replicate main in the driver and just
compile selected ddx
file i.e everything but main when I build my version. I can certainly
come up with solutions that don't effect other drivers but on the same
hand building the server as a shared library esp for rootless
implementation is probably useful to others.



> I'm not sure what the changes to dix/window.c and dix/dispatch.c are intended
> to do, but they certainly look intentional.  Can you clarify them?
>

CreateWindow returns before registering the window  in CreateRoot its
done the way I did it. This was one of the changes needed to allow a
traditional client to be builtinto the window server in my case the
window manager clipboard and composite manager etc will end up being
builtin. I'm doing some pretty radical stuff with the changes but I
think having for example the composite manager builtin could be a
performance boost esp if you want to use the 3D hardware.

> The changes to miext/rootless look fine though, I'd be happy to merge them if
> you think they're ready.
>

Yep these are the main changes I think should be able to go in pretty
much as is but I've not tested the OSX or windows build so I'm not
sure there compatible they should be tested agianst both servers.

I hope we can figure out a way for me to build my server on the same
code base with no patches you may not agree with it but I've done
nothing that requires me to fork the code if your willing to make some
changes that won't impact the main implementation.

Mike


> - ajax
>
>
>