EGL_MESA_screen_surface proposal

[Brian Paul]

Jon Smirl wrote:
> On Wed, 16 Mar 2005 09:39:54 -0700, Brian Paul
> <brian.paul at tungstengraphics.com> wrote:
> 
>>Jon Smirl wrote:
>>
>>>On Wed, 16 Mar 2005 09:21:30 -0700, Brian Paul
>>><brian.paul at tungstengraphics.com> wrote:
>>>
>>>
>>>>I guess I'm not sure what you're getting at though.
>>>
>>>
>>>Say I'm using a desktop windowing system implemented on top of XGL. It
>>>has an HDTV projector hooked up to the second head of the card. Is it
>>>useful to have a UI that says force that head into 1080i or 720p?
>>
>>Sure.
>>
>>
>>
>>>The UI under X for doing this is to use keypad +/- to cycle through
>>>all of the modes. That model is complicated when multiple heads are
>>>involved.
>>>
>>>To build a UI for choosing the mode I need a list of mode names,
>>>either that or or they can choose from a list with all of the
>>>attribute/value pairs but a lot of people won't understand the pairs.
>>
>>OK, I see what you want.  But somehow it just doesn't feel right to
>>export that information through the EGL API.  Can we defer that for now?
> 
> 
> Isn't the EGL API the only way the desktop can interact with the video
> system? You can't read config files since mesa/ATI/NVidia may all
> implement it differently.
> 
> I may also have some thing like
> HDTV-1080i
> HDTV-1080i-left -- where the mode line has been adjusted to move the
> image to the left
> 
> These will both have with=1920,height=540,refresh=60,interlace=1 the
> only difference will be the name since the mode difference is
> controlled by attributes not exposed in EGL.

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);

The danger, of course, is that this mechanism might be abused by 
someone.  A similar example is OpenGL applications that query the 
GL_RENDERER string to check for specific information that might 
disappear in future drivers.


As a side note (not directed to Jon): I really want to keep the EGL 
API extension small and concise.  I want to capture 95% of what's 
needed now and not get too side-tracked with the other 5%.

The other 5% can be accomodated in the future with additional EGL 
extensions.  The key thing is to design the API with extensibility in 
mind.  That's why (for example) all the EGL datatypes are totally 
opaque, rather than C structs which would be a PITA to extend.

I've been involved in designing OpenGL extensions with the OpenGL ARB 
for 5 or 6 years now and I have seen first-hand how things can get 
derailed if one gets too side-tracked.  I don't want that to happen 
here.  I don't want to dictate this project, but I think my experience 
is worth something.

-Brian