EGL_MESA_screen_surface version 5
brian.paul at tungstengraphics.com
Wed Apr 6 15:57:16 PDT 2005
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
> > The mode attribute EGL_OPTIMAL_MESA will be set for modes which
> > best match the screen. [M. Danzer]
> Note the typo for LCD.
> 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.
More information about the dri-egl