brian.paul at tungstengraphics.com
Wed Mar 16 09:18:26 PST 2005
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?
>>>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
>>>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-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.
More information about the dri-egl