EGL_MESA_screen_surface proposal

[Brian Paul]

Jon Smirl wrote:
> On Wed, 16 Mar 2005 10:18:26 -0700, Brian Paul
> <brian.paul at tungstengraphics.com> wrote:
> 
>>Well, I think that's a pretty esoteric example.  We're starting to get
>>into things that most people will never come across.  Still, I'm
>>willing to be flexible.
>>
>>Would a function like this suffice:
>>
>>const char *eglQueryModeStringMESA(EGLDisplay dpy, EGLModeMESA mode);
> 
> 
> This solves the problem. You can eliminate the interlace attibute if
> this call is added.

I wouldn't want to eliminate the interlaced attribute.  If I did, and 
one wanted an interlaced mode, they'd have to resort to parsing the 
mode name strings.  As an EGL API user, I'd rather use eglChooseMode 
to specify that attribute.  Otherwise, how I am I to know whether I 
should look for "i" or "interlaced" in the mode name strings?


> The root of the problem is that there are more attributes on the mode
> than are exposed in EGL. You could do a elgChooseMode(1024,768) and
> get back 10 identical modes at the EGL level, but they would all be
> different at the hardware level. EGL will pick the what it thinks is
> the best mode and you won't be able to get to the others since you
> can't tell them appart.

The complete list of EGL mode attributes hasn't been set yet (and 
could be extended in the future).

This is all very much like EGLConfigs.  If you only request an 
RGB+Stencil config, you might get a list of 20 of them from 
eglChooseConfig.  If you really care what distinguishes each of them, 
you should have specified more precise attributes to eglChooseConfig() 
or you'll use eglGetConfigAttrib() to query additional attributes.


> If you think it is better to leave this call out we can. The
> alternative is the keypad +/- scheme that X uses to cycle through all
> of the modes. The cycling scheme doesn't need a name..

OK.

-Brian