EGL_MESA_screen_surface version 5

Adam Jackson ajax at nwnk.net
Thu Apr 7 08:05:35 PDT 2005


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.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dri-egl/attachments/20050407/761ae05e/attachment.pgp


More information about the dri-egl mailing list