EGL_MESA_screen_surface proposal

[Adam Jackson]

On Wednesday 16 March 2005 13:15, Jon Smirl wrote:
> On Wed, 16 Mar 2005 10:18:26 -0700, Brian Paul
> > 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.
>
> 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.

Well that's sort of the point, isn't it?  If you only ask for a width of 1024 
and a height of 768, you're implicitly stating that any other attribute is a 
"don't care".  If you really care about your screen surface having the buddha 
nature, then set EGL_BUDDHA_NATURE in the attrib list.

Adding attributes later is not a problem, just write an extension that adds a 
few new tokens.

Jon, your real issue seems to be this:
> 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.

The API Brian proposed _does_ have a way to enumerate all the modes supported 
by a device: eglGetModesMESA.  You then walk that mode list doing 
eglGetModeAttribMESA for every attribute your app knows about.  This is 
exactly parallel to how we enumerate visual configs at the bottom of your 
glxinfo output.  Construction human-readable names for these modes is a 
mechanical process once you have the attributes of each mode.

And it's not something we should be attempting in EGL, I don't think.  If 
nothing else, booleans like "is interlaced" will be represented in the UI as 
strings, which means they need to be localized, and I really don't want 
either the driver or the EGL dispatch layer to need to know the 
French/Russian/Swahili/Huttese way of spelling "interlaced".

Not that that logic isn't valuable, just that it doesn't belong this low in 
the stack.  It belongs in the display control panel of your DE.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dri-egl/attachments/20050316/88708ff6/attachment.pgp