EGL_MESA_screen_surface version 5
brian.paul at tungstengraphics.com
Thu Apr 7 08:58:08 PDT 2005
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>
>>>>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
>>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.
More information about the dri-egl