EGL_MESA_screen_surface version 5

[Brian Paul]

Matthew Tippett wrote:
> Comments within.
> 
>  >
>  >     7. How should the notion of a screen's "native" mode be expressed?
>  >        For example, LDC panels have a native resolution and refresh rate
>  >        that looks best but other sub-optimal resolutions may be 
> supported.
>  >
>  >        The mode attribute EGL_OPTIMAL_MESA will be set for modes which
>  >        best match the screen.  [M. Danzer]
> 
> Note the typo for LCD.

Fixed.


> These two are related.  Within the EDID specification, the ordering of 
> display information has an implication that the native resolution is the 
> first detailed timing that is returned.
> 
> There are certian monitors that (Apple Cinema) that do not follow this 
> approach since the bandwidth requirements for the native display would 
> not be suitable for non-dual link cards.  That monitor returns the 
> single link (1280x800) mode first - implying that that is the native 
> resolution, and then the dual link mode (2560x1600) second.  All cards 
> will support the first mode, but only high end cards will support the 
> second.  In short, for the Apple Cinema display there are two 'OPTIMAL' 
> modes that would be possible depending on hardware.  I guess that the 
> monitor hardware detection becomes a driver issue to determine which is 
> truly the optimal mode based on hardware configuration.  This will 
> require more work on the driver, but will leave a more consistent 
> interface for OES applications.

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.

-Brian