EGL_MESA_screen_surface version 5

[Brian Paul]

Adam Jackson wrote:
> On Thursday 07 April 2005 00:06, Brian Paul wrote:
> 
>>Jon Smirl wrote:
>>
>>>On Apr 6, 2005 6:57 PM, Brian Paul <brian.paul at tungstengraphics.com> 
> 
> wrote:
> 
>>>>So, are you saying that we need something additional in the
>>>>EGL_MESA_screen_surface API for this?
>>>>
>>>>We still need to define what happens when one display device is
>>>>removed and a new one replaces it.  The set of available display modes
>>>>may change.  The EGL API user should have a way to detect this.
>>>
>>>fbdev will generate a HAL event for this. I think the code is already
>>>in the kernel. It is then up to the higher layers to catch the event.
>>>fbdev may also blank the monitor until a new mode is set. This is to
>>>prevent the old mode from destroying a new monitor.
>>
>>Would this HAL event be a signal or interupt or what?
> 
> 
> HAL events are generally multicast over DBUS to any interested listening 
> application.  The driver could in principle open a new fd for this, but it 
> would be more straightforward for us if the event were also noted in the 
> sarea.
> 
> 
>>It sounds like an EGL application that wanted to detect and deal with
>>monitor changes would be using a non-EGL mechanism to do so, right?
>>
>>It might be nicer if there were an EGL interface for dealing with this.
> 
> 
> Perhaps operations on screen surfaces are allowed to fail analogously to 
> EGL_CONTEXT_LOST.  If we don't do this, then we have the situation where 
> eglGetModesMESA can return different values on successive calls with no 
> app-visible state to reflect the reason.

I've added this as another open issue.

-Brian