ajax at nwnk.net
Mon Mar 14 08:07:53 PST 2005
As with GLX, if you want contexts and surfaces you need a display first. I
don't know that eglGetDisplay is good enough for us here:
EGLDisplay eglGetDisplay(NativeDisplayType native_display);
Now this works fine for the single-head case because EGL_DEFAULT_DISPLAY is
just a fancy word for NULL. And if you know your EGL API is hosted under X,
you can pass in X Displays and it'll work, similarly for WGL I expect.
However it doesn't give native applications any way to specify what card to
So we want a device specifier. Are PCI strings good enough?
EGLDisplay dpy = eglGetDisplayForWidgetXXX("pci/0000:01:00.0");
As long as there's a unique identifier for a device on a given bus, this
works, so basically that's everything except ISA. Not very GL-ish to pass a
string in as an argument, I suppose.
Part of this hinges on what our idea of a display is. I'm old fashioned and I
tend to think of a display as being a single piece of glass. My spies tell
me this isn't an accurate model anymore. I think I can see the relationships
- one card hosts A displays (ie, things corresponding to an EGLDisplay)
- one display hosts B screens (ie, framebuffers being read by a DAC)
- one screen can have C views onto it
I think it's just a matter of deciding on "exactly one" or "arbitrary numbers
of" for each of A B and C. Every one-to-many relationship here is another
place to fix up the API, so, less is more if we can get away with it. The
problem here is that B and C don't have associated data types or entrypoints
in the API.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dri-egl/attachments/20050314/1cd6b883/attachment.pgp
More information about the dri-egl