Display specification

Adam Jackson 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 
run on.

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 
we want:

- 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.

- 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/20050314/1cd6b883/attachment.pgp

More information about the dri-egl mailing list