On Tuesday 22 February 2005 11:48, Brian Paul wrote: > Adam Jackson wrote: > > I pounded out most of the rest of the API compat today. This is good > > enough to run eglinfo and return mostly correct answers (caveat is always > > "slow" for some reason), and of the 25ish egl* entrypoints only around > > three are still stubs. > > > > Apply patch to a newish Mesa checkout, add egl.c to sources in > > src/glx/x11/Makefile, build libGL. > > While you were working on a translation layer I was working on a > general-purpose implementation of the EGL API.
Excellent! I was hoping our work wouldn't overlap. I should probably describe where I see this going. All the egl* entrypoints would call through a dispatch table (think glapi.c) that determines whether to use the GLX translation or the native engine. The native engine would fill the role that miniglx currently holds. In practical terms, what this means is: $ Xegl -drm /dev/dri/card0 :0 & # starts a server on the first video card $ DISPLAY=:0 Xegl :1 & # runs a nested Xgl server under :0 would work the way you expect. (Obviously I'm handwaving away the fact that the Xgl server doesn't support the GLX extension yet, and that there's no EGL backend for glitz yet. The latter was actually my motivation for doing the GLX translation, so we could have glitz ported before attempting to bring it up native.) So. Naive EGL applications would Just Work, whether or not there's a display server already running. The EGL dispatch layer would be responsible for checking some magic bit of per-card state that says whether there's currently a live display server on the device, and route the EGL API accordingly. This magic bit of per-card state would be exposed by some new EGL extension, call it EGL_display_server. Non-naive applications like EGL, in the presence of this extension, will register themselves as display servers for the given device(s?) when they start up. This bit of state then gets handed down to the DRM layer (or its moral equivalent for non-DRI drivers). (Plenty of other magic can happen here, for example releasing this display server lock on VT switch.) [1] After which, the only hard part (sigh) is setting video modes. This may want to be an EGL extension as well, and would have some precedent (eg GLX_MESA_set_3dfx_mode). Of course we can implement this any which way we like, it's just that exposing the API through EGL makes it easier for apps to do this both across vendors and across platforms. Hopefully this doesn't sound completely insane. Comments? - ajax 1 - One question at this point would be why not make the first EGL app to start on a device always take the lock? I could envision (probably embedded) environments that want, essentially, cooperative windowing, where (for example) each "window" maps to a hardware quad, textured through a pbuffer or fbo, and the Z buffer is used to implement stacking order, with some message passing between display apps so they don't fight. This is certainly not a use case I care about, but other people might...
pgpd6fF7C7R1y.pgp
Description: PGP signature