Xgl server

[Brian Paul]

Martijn Sipkema wrote:
> 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.

Windowing is the responsibility of the window system, not EGL.

By screen management, I mean things like allocating VRAM for the 
framebuffer, specifying the screen width/height/depth, refresh rate, 
viewport position, turning scan-out on/off, etc.


>>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?

Rather than invent a new API from scratch, it seems a bit more 
attractive (to me anyway) to leverage an existing API.  EGL seems to 
be a good candidate.


>>>>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.

I believe the window-related stuff should be handled by the window 
system, not a lower-level library.  There's a lot of people doing 
graphics projects who don't need or want a window system.  They just 
want an API for setting up a full-screen display surface and doing 
OpenGL rendering.

-Brian