Display specification

[Alex Deucher]

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

Alex

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