Display specification

[Brian Paul]

Alex Deucher wrote:
> On Mon, 14 Mar 2005 10:10:07 -0700, Brian Paul
> <brian.paul at tungstengraphics.com> wrote:
> 
>>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.
> 
> 
> As far as the API is concerned it shouldn't matter whether a card is
> local or on a remote host right?  (thinking about dmx-like setups...)

Right.  The EGL API won't have any pointers and all the EGL datatypes 
are network-friendly.  I don't think anyone's planning on implementing 
indirect rendering with EGL, but I think the API design is improved by 
considering that sort of thing.

-Brian