On Fri, 31 Dec 2004 11:34:52 -0500, Owen Taylor <[EMAIL PROTECTED]> wrote: > On Fri, 2004-12-31 at 10:45 -0500, Jon Smirl wrote: > I don't know if an incremental approach would be easier; there's clearly > a lot of refactoring to do to get to a point where rendering through > GL is clean. But the idea that a total rebase is necessary, that an > X server based on GL is a completely different binary and project > rather than a continuation of the current X server worries me. At what > point do you throw the big switch?
I was working down two parallel development paths. One was to get XGL working inside of an existing X server. XGL is an xserver implementation that only needs OpenGL to run. Dave Reveman already has this running: "I stuck the code into the "xserver" tree and './configure --enable-xglserver' should compile the common xgl code along with an Xglx server that can run on top of an existing X server with GLX.". The second part is to get mesa-solo running and providing a standalone OpenGL platform. This is the part I am working on. mesa-solo basically works except that it has no mode setting support (and some other minor things like hardware cursors). The mesa-solo in CVS limps along using fbdev to do it's mode setting. Actually it should be possible to get XGL running on mesa-solo right now as a demonstration on a single head. It probably just missing cursor support. The drm/fbdev work is caused by the need to support more than one head. The current xserver 2D drivers have multihead support in them. fbdev only supports a single head. The drm that just landed in linux-2.6 supports multihead but doesn't support mode setting. Since mesa-solo does not have the 2D xserver drivers available it can't support multihead. So the end result is that the drm/fbdev merge is driven by the need for mode setting support on the second head. You can't just blindly add this to fbdev since multihead means multiple buffers and fbdev doesn't have any memory management code. I was pretty far along in getting this working for the radeon driver when we had the babies. Now I'm tied up until we can hire some help (no one wants to work over the holidays) or the babies stop needing to be fed every three hours 24hrs a day. Once you get the two parts working, stick them together and you have a working system without disrupting the current X server. I would really like to see more work done on this since it may be possible to ship XGL before Microsoft can get the equivalent support released. This would be an excellent way to show that Linux is leading OS development instead of following. I think Redhat could make some major headlines by beating MS on this one. -- Jon Smirl [EMAIL PROTECTED] ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
