EGL_MESA_screen_surface version 5

[Jon Smirl]

On 4/22/05, Adam Jackson <ajax at nwnk.net> wrote:
> This is why I said the semantics are allowed to change in the presence of a
> hotplug extension.  Once you call the EnableHotplug routine that said
> extension defines, then you can change the EGL_SCREEN_COUNT_MESA semantics
> and add API for requesting a new handle, iterating over screens, etc.  But
> it's logically separate, and the implementation is separable from the basic
> stuff we've been talking about.  So we should separate it.  Build
> EGL_MESA_dynamic_screens on top of this extension, once we have an idea how
> it should work.  Let's get MESA_screen_surface to the 90% point so we can
> start building with it.
> 
> Remember that EGL will continue to be used on low-end devices.  If you have to
> add all these additional entrypoints and code to support massively dynamic
> screen reconfiguration as a _requirement_ for implementing
> MESA_screen_surface, then it becomes less attractive for small devices.
> 
> I don't want to design a hotplug extension right now, but that's just an
> expression of my personal priorities, not a declaration that no one should.
> Feel free to interpret that as a challenge ;).

Screens on Linux are hotplug today. While right now we may not want to
build the egl mechanism for tracking add/remove we should at least
make the screen handle opaque and have an iterator function. People
should not be writing code that says how many screens do I have now
let's allocate a static array to hold them. And they shouldn't be
writing loops assuming incrementing integer screen numbers. We
definitely need error returns from all functions saying that the
screen has gone missing.

Doing it this way will let us transparently add code later that
actually add/removes screen. I don't think changes along these lines
will impact low end devices. And if we don't do them we're going to
get code written that will break when a screen disappears.

Another area is monitor hotplug. I have code that supports this ready
to go into fbdev as soon as we can get some interrupt handling issues
sorted out. Apps need to deal with an error saying something like mode
context lost, choose a new one.

-- 
Jon Smirl
jonsmirl at gmail.com