EGL_MESA_screen_surface version 3

[Brian Paul]

Thanks, Michel.  I'll roll these into the next revision.

I'll just point out that there's probably 3 different positions to 
take on each issue:
   1. In favor
   2. Against
   3. Defer for a separate, layered extension.

-Brian


Michel Danzer wrote:
> Here's my take on some of the issues. Keep up the good job Brian.
> 
> On Fri, 2005-03-18 at 07:46 -0700, Brian Paul wrote:
> 
>>    1. Should EGL_INTERLACE be a supported mode attribute?
> 
> 
> No, this should be provided by another extension which would also
> provide the mechanisms needed to play back interlaced video material
> correctly on hardware that supports it.
> 
> This extension should prefer non-interlaced modes.
> 
> 
> 
>>    2. Should EGL_REFRESH_RATE be a supported mode attribute?
> 
> 
> Yes, it's been shown that applications and/or users need to select modes
> by this.
> 
> 
> 
>>    3. Exactly how should the list of modes returned by eglChooseConfigMESA
>>       be sorted?
> 
> 
> I think the current order is good.
> 
> 
> 
>>    5. Should the EGL_PHYSICAL_WIDTH/HEIGHT_EGL tokens be kept?  They're
>>       not always reliable (i.e. projectors) but can still be used to
>>       determine the pixel aspect ratio.
> 
> 
> If they're only useful for the pixel aspect ratio, they could be
> replaced by a single token for that.
> 
> 
> 
>>    7. How should the notion of a screen's "native" mode be expressed?
>>       For example LDC panels have a native resolution and refresh rate
>>       but may support other sub-optimal resolutions.
>>
>>       At this time, the EGL_OPTIMAL_MESA values may be specified in
>>       eglChooseModeMESA() for EGL_WIDTH, EGL_HEIGHT, etc.
>>
>>       However, that violates the principle that eglChooseModeMESA()
>>       should be fully implementable in terms of the eglGetModesMESA and
>>       eglGetModeAttribMESA functions (as for eglChooseConfig).
> 
> 
> Another option would be a special attribute like EGL_OPTIMAL. Modes that
> have this set would be preferred. The native resolution should be
> covered by the preference for larger modes, or are there displays that
> handle larger than native resolution?
> 
>