Xgl server

[Martijn Sipkema]

From: "Brian Paul" <brian.paul at tungstengraphics.com>
> Owen Taylor wrote:
> > On Fri, 2004-11-05 at 17:27 -0700, Brian Paul wrote:
> > 
> > 
> >>A while back I suggested designing a very simple OpenGL glue interface 
> >>for creating/managing rendering contexts, drawing surfaces, etc. that 
> >>the GL-based X server could layer upon.  It would also work for people 
> >>wanting to do X-less GL applications.
> >>
> >>mesa-solo (aka mini-glx) serves that purpose now, but it's kind of a 
> >>hack (the emulation of the GLX and basic Xlib functions is kind of icky).
> > 
> > 
> > Especially inside the X server, presumably...
> > 
> > 
> >>It occured to me that maybe the EGL interface (part of the OpenGL ES 
> >>standard) could be used instead.
> >>
> >>The EGL spec can be found here:  http://www.khronos.org/opengles/spec.html
> >>
> >>One potential advantage to using the EGL interface is the fact that it 
> >>might be supported by other hardware vendors.  Suppose, 
> >>hypothetically, that NVIDIA were to support EGL.  Then, the GL-based X 
> >>server could run on it (instead of a full X server).
> > 
> > 
> > Well, but once you fill in the blanks of what NativeWindowType, and
> > NativeDisplayType, do you really have much useful portability left?
> 
> I think so.  If we could create an EGL extension for screen management 
> then the eglCreateWindow/PixmapSurface() functions wouldn't be used at 
> all.

What exactly do you mean with screen management? I think there will still
need to be functions for creating/managing windows since that is what
OpenGL doesn't provide.

> We could also make EGL extensions for managing cursors, etc. if needed.

Perhaps it would be best to create a new API, based on GLX/EGL, but
designed specifically for use by a display server, such as X?

> >>One thing with EGL is that it's designed to interface with an existing 
> >>window system, like X or WGL.  See eglCreateWindowSurface() for 
> >>example.  But, I think a "pure" EGL implementation is possible with a 
> >>little work.
> > 
> > 
> > It's quite possible that EGL is a useful starting point; why create
> > another <x>MakeCurrent name if we can use eglMakeCurrent. But in the
> > end, it seems like to go beyond proof-of-concept, we're going to have
> > a much bigger X server <=> hardware interface.
> > 
> >  - Implementing an X server in GL without clip lists sounds pretty
> >    painful. But while GLX implementations have clip lists, they aren't
> >    API exposed, and neither are they in EGL.
> 
> Suppose we defined a new OpenGL extension to specify a list of scissor 
> boxes, maybe glScissorListEXT().  Would that fit the bill?

Why not have the X server use windows provided by a lower level
driver library? The clip lists/bitmap of these can then be set by the
X server seperate from the OpenGL commands.


--ms