Solo Xgl..
Brian Paul
brian.paul at tungstengraphics.com
Sun Feb 20 10:20:23 PST 2005
Adam Jackson wrote:
> On Sunday 20 February 2005 11:29, Brian Paul wrote:
>
>>Dave Airlie wrote:
>>
>>>building an Xserver on top of mesa solo is a bit of a nightmare in terms
>>>of includes and defines .. as an Xserver requires all the X types to
>>>build but solo has its own set of defines/typedefs that don't match what
>>>the Xserver has... so calling XCreateWindow is a bit painful for
>>>example... glitz-glx also includes X headers... (not sure if it really
>>>needs them as glx.h should pull in any necessary headers...
>>
>>I've mentioned this before: my thinking is that for the long term,
>>mini GLX could/should be replaced by a different API, such as EGL
>>(from OpenGL-ES) plus a few extensions.
>>
>>Mini GLX is a hack. It filled a specific need when it was created but
>>I'm not sure it's an appropriate base for large projects.
>>
>>An enhanced EGL interface could be a nice clean foundation. Xgl could
>>layer upon it and other people could use it as-is for projects where X
>>isn't wanted. Hopefully, other IHVs would adopt/implement it too.
>
>
> I'm working on this, actually. Right now I'm doing it as an EGL->GLX
> translation layer so we can get glitz retargeted at the EGL API. Turning
> that into a dispatch layer wouldn't be too tough, particularly since a good
> bit of the engine is already written in miniglx. I've nearly got it to the
> point of being able to run eglinfo, but it seems to have uncovered a bug or
> two in the fbconfig handling.
I actually started writing some EGL interface code a few months ago,
but haven't touched it since. Give me a day or two to clean it up.
Then let's exchange code and see what we've got.
> My only complaint with EGL is that a lot of the 1.1 version is, on big
> systems, a lot of work for not a lot of gain (OES_byte_coordinates for
> example).
Well, GL_OES_byte_coordinate is an (optional) extension. I'm not sure
we need to be concerned with it for now.
Just to be clear, I was thinking of using the EGL API with full
Mesa/OpenGL, not the ES subset.
-Brian
More information about the xorg
mailing list