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. 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). - ajax
pgph3Sp6rr6S9.pgp
Description: PGP signature
