Display specification

[Brian Paul]

Adam Jackson wrote:
> 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.

The sample code I'm working on does something like that.  I think it 
would be acceptable to pass a string.  Could we also have a more 
general syntax, like "screen/0" or "screen/1"?  That way we wouldn't 
tie the interface to PCI-based devices.


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

The way I was thinking of it was:
  - each card corresponds to an EGLDisplay
  - an EGLDisplay may have one or more screens (i.e. pieces of glass)
  - each screen may be a view onto different surface, or the same surface.

I'll try to write up my API proposal soon.

-Brian