EGL_MESA_screen_surface version 5
brian.paul at tungstengraphics.com
Fri Apr 22 14:37:43 PDT 2005
Jon Smirl wrote:
> 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.
It would be more "EGL-like" to have an opaque handle/datatype for
screens, rather than an integer. I was just following the Xlib
Care to propose new API functions which use EGLScreen instead of integers?
More information about the dri-egl