Re: Why run xserver on the OpenGL API?
"Kendall Bennett" <[email protected]>
| Newsgroups | gmane.comp.freedesktop.xserver |
|---|---|
| Organization | SciTech Software, Inc. |
| Message-ID | <3FC3A69B.27119.164815AA@localhost> |
Keith Packard <[email protected]> wrote: > Around 18 o'clock on Nov 25, "Kendall Bennett" wrote: > > > Since I am sure we are not talking about building an X server based on > > OpenGL that requires an existing OpenGL enabled X server to run, perhaps > > you can clear this up? > > Yeah, I'm not completely clear in my own mind how all of this is > going to work, but certainly the bottom of the system is an > X-independent OpenGL library sitting atop the raw hardware. Right. I am glad we are on the same page then. The good news (as I outlined in my previous post) is that we already have a completely X independent OpenGL library sitting atop the raw hardware right now on Linux. Software only, but it should be enough to kick start this project if you are interested. > I would like to know how direct rendered 3D apps will get drawn > into X windows; I'd like to think that the solution involves > drawing to an off screen buffer and then telling the X server to > swap buffers so that the Composite extension could get involved > somehow. Yes, exactly! In fact that is exactly how I have designed it with SNAP. The SNAP 3D architecture is broke into two pieces. The first piece is a low level driver that handles all the probing, mode enumeration, mode sets, palette/gamma ramps etc, plus it contains a complete offscreen surface manager for allocating and managing draw buffers, depth buffers, textures, video surfaces etc etc. Layered on top of that is the 3D module (Mesa naturally ;-) that uses the buffer manager to manage all it's surfaces. Code that wants to draw to video memory allocates buffers with the buffer manager API and can either directly call the 2D SNAP functions or create an OpenGL rendering context for that buffer and draw to it. To display it on the screen, you can either BitBlt it to a visible buffer or if the buffer is part of a flip chain simply make the buffer visible for hardware page flipping. Here is the basic SNAP buffer version of glX: void ChooseVisual(GA_buf *buf,GA_glVisual *visual); ibool CheckVisual(GA_buf *buf,GA_glVisual *visual); GA_HGLRC CreateContext(GA_buf *buf,GA_glVisual *visual,GA_HGLRC shareList); void DeleteContext(GA_HGLRC ctx); ibool MakeCurrent(GA_HGLRC ctx); GA_HGLRC GetCurrentContext(void); void SwapBuffers(GA_HGLRC ctx,N_int32 waitVRT); void SetPaletteData(GA_HGLRC ctx,GA_palette *pal,N_int32 num,N_int32 index); void GetHalfTonePalette(GA_palette *pal,N_int32 num); void * GetProcAddress(const char *procName); Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~