EGL_MESA_screen_surface version 3

[Michel Danzer]

On Sun, 2005-03-20 at 17:02 -0800, Ian Romanick wrote:
> Michel Danzer wrote:
> > On Fri, 2005-03-18 at 07:46 -0700, Brian Paul wrote:
> > 
> >>    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.
> 
> This is the only issue that I have any strong feeling about.  If the 
> only reliable use is to determine the aspect ratio, then we should just 
> provide that value.  However, is this the aspect ratio of the display or 
> of a pixel?  I assume it's the aspect ratio of the display, but should 
> the pixel aspect be provided?  Either way, a single integer won't 
> suffice.  How would 16:9 or 4:3 be represented?

One possibility would be a fixed point value expressed as an integer,
like EGL_REFRESH_RATE.


> >>    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?
> 
> So, would a multi-state value like GLX_VISUAL_CAVEAT_EXT work here?  We 
> could also do something like GLX_SGIX_visual_select_group.  In that 
> extension each fbconfig has a value, which is completely hidden from the 
> application, that is used to break ordering ties.  I don't know if 
> either of those is the right answer, but there is at least some 
> implementation / usage experience with both.
> 
> http://oss.sgi.com/projects/ogl-sample/registry/EXT/visual_rating.txt
> http://oss.sgi.com/projects/ogl-sample/registry/SGIX/visual_select_group.txt

Both approaches look appropriate to me, I guess which is better depends
on whether applications need to know whether a mode is native or not. I
can't think of a reason why they would offhand, so the
visual_select_group approach might be better.


-- 
Michel Danzer, Linux Software Engineering       \   Tel: +1 905-882-2600
ATI Technologies Inc., Markham, Ontario, Canada  \       Extension: 3550