Multiple EGL implementations

[Jon Smirl]

On 7/2/05, Adam Jackson <ajax at nwnk.net> wrote:
> On Saturday 02 July 2005 15:13, Jon Smirl wrote:
> > On 7/2/05, Adam Jackson <ajax at nwnk.net> wrote:
> > I haven't worked through the details of how a remote EGL display would
> > work. Xegl is going to want to open the display, get a list of modes
> > and set a screen surface. Can all of that be mapped on GLX without
> > changes? How about off screen surfaces? Have you paired up the EGL API
> > with corresponding GLX calls to make sure that everything is mappable?
> 
> Yeah, I pretty much already did it:
> 
> http://people.freedesktop.org/~ajax/indiegl-1.0.tar.gz
> 
> But I did it before the EGL driver interface really existed, and haven't had
> time to get back to it.  The only major issue, as you pointed out in another

Does my Xegl server run on it? You should check it into the Xgl
project so that everyone can find it.

> mail, would be handling window resizes.  The possible solutions include:
> 
> - Don't care, resizes change the view clip but not the scene geometry
> - Don't, use SetWMNormalHints to prevent resizes
> - Generate EGL_MODE_LOST_MESA on next state update to the drawable, invalidate
> the window contents but don't destroy the backing X window yet.
> 
> The last one hinges on a token we don't have.  I think it maps exactly to
> resize events in hardware, so the semantics there would be:
> 
>   Once MODE_LOST_MESA is issued for a screen surface, the EGLSurface is
>   invalidated for state changes and its buffers are undefined.  Either
>   destroy it, or select a new mode and re-show the surface using the new mode.
> 
> For everything else, the EGL API is almost a strict subset of the GLX API.
> It's pretty straightforward.

We should discuss screen surface size changes more and have a
recommend solution. Another way to trigger this is with pivot monitors
that switch from portrait to landscape.

-- 
Jon Smirl
jonsmirl at gmail.com