EGL_MESA_screen_surface proposal

[Brian Paul]

Jon Smirl wrote:
> On Wed, 16 Mar 2005 12:12:31 -0700, Brian Paul
> <brian.paul at tungstengraphics.com> wrote:
> 
>>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 point here is that you don't want to create an interlaced display.
> You instead want the best display at 1920x1080. So if you
> glChooseMode(1980, 1o80) and your monitor and hardware both support it
> you will get back HDTV 1080p. If either your monitor or hardware
> doesn't support 1080p you'll get back 1080i. But both of these scan
> out of the same buffer so it doesn't really matter which is returned.
> You just want the best display possible.

The list of matching modes returned by eglChooseModeMESA(), like 
eglChooseConfig(), is sorted according to some rules.  I suspect we'd 
simply sort the list so non-interlaced modes come before interlaced. 
We'd also sort according to refresh rate to put faster refresh rates 
first.  This way, if you just use the first mode in the returned list, 
you'd _generally_ get the most desirablable one.

If that doesn't suit your needs you can query all modes with 
eglGetModes and interogate them with eglGetModeAttrib.  People have 
sometimes bypassed glXChooseVisual in this manner.


> The only reason you need the interlace attribute is when you have both
> 1080p and 1080i available and you want to force 1080i. But now that
> think about it I don't think you'll ever want to do this so we don't
> need the attribute. I can't think of a situation where you want to
> force an inferior mode when you have a better one available.

Suppose I'm a video engineer and I just want to test interlaced mode 
with my lab equipment.

If a graphics card supports 332RGB TrueColor mode few people may ever 
want to use it since 888RGB is so much nicer, but the option to use it 
should still be there.

-Brian