On 5/28/06, Adam Jackson <[EMAIL PROTECTED]> 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 > > > _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
