EGL_MESA_screen_surface version 5

[Jon Smirl]

On 4/25/05, Matthias Hopf <mhopf at suse.de> wrote:
> > Then these are the two error codes for my screen or mode disappearing?
> >
> >    EGL_BAD_SCREEN_MESA
> >    EGL_BAD_MODE_MESA
> 
> I would suggest that the ability to generate screen or mode disappearing
> errors should be part of the hotplug extension that is yet to come. This
> would ease the life of embedded device programmers a lot. The error
> codes can already be defined in this extension, as we have to generate
> them for bad handles (e.g. NULL) as well.

Embedded developers can ignore the error codes since embedded systems
can generate them. On the other hand I don't want another generation
of desktop systems out there that can't handle hotplug.

The error should probably be:
 EGL_LOST_SCREEN_MESA
 EGL_LOST_MODE_MESA
 EGL_LOST_SURFACE_MESA

If we allow framebuffer to share the adapter EGL_LOST_MODE_MESA and
EGL_LOST_SURFACE_MESA could be generated because framebuffer stomped
the egl state. Even a VT switch to an old X server could cause these
errors.

Think about Xen and virtual devices too.

> > We'll need to note that screen, mode, surface handles can't be reused.
> > Once the associated object is deleted the handles will always need to
> > return EGL_BAD_xx_MESA. This implies that the handles can't be direct
> > pointers and instead  have to be indices into a look up table.
> 
> You are indicating that we need a lookup table of endless size?
> Shudder...
> If there is a persistent state attached to handles, there must also be a
> way to free/close them.

What you don't want to do is lose a screen and get another one with
hotplug and then immediately reuse the same handle. If you do that
there is no way for the app to know that the screen has been switched.

You don't need a lookup of table of endless size. Just track the
active handles and assign new ones in increasing order. By the time
the handle numbers wrap all of the old uses should have been
identified.

This also implies that pointers are not good for handle values.


-- 
Jon Smirl
jonsmirl at gmail.com