eglGetDisplay/eglChooseDisplay, CreateContext

[Jon Smirl]

On 7/11/05, Brian Paul <brian.paul at tungstengraphics.com> wrote:
> Jon Smirl wrote:
> > In our model eglGetDisplay(display_name) opens a specific device. So
> > if I want to open three screens I need to do:
> > eglGetDisplay("display/0");
> > eglGetDisplay("display/1");
> > eglGetDisplay("display/2");
> >
> > And I end up with three display handles.
> >
> > With the X server if I XOpenDisplay() I get:
> > Display
> >      screen0
> >      screen1
> >      screen2
> >
> > With EGL I could also get:
> > Display
> >      screen0
> >      screen1
> > Display
> >      screen0
> >
> > So if I understand things right an EGL display is corresponding to an
> > X screen. And there is no equivalent to an X Display in EGL. There is
> > also no parallel for EGL screen in X.
> 
> I was going on the assumption that an EGL display corresponded to a
> device (a card).  Each card may have 0 or more screens attached to it.
> 
> X has screens too.  They're named by an integer starting at 0.

I have this figured out now. EGL displays correspond to cards, it has
to be this way from the initial EGL spec. We are then adding screens
(heads) to the cards.

X does not have a structure that corresponds to cards, instead it only
has screens. Because of this difference I had to rework most of the
code in dri/common/dri_util.c.

> > Another area of confusion I'm having is glXCreateNewContext(display,
> > config). The display is not used in DRI code. Instead GLX configs are
> > bound to screens and the screen is determined from the config.
> 
> Because X is rather screen-oriented internally.

I solved this by making a driCreateNewContext2(driScreen). Ian and I
will need to get together and sort out the dri_util internals.

> > In eglCreateContext(display, config) my display corresponds to an X
> > screen and my config is not bound to a particular EGL screen. So why
> > does eglCreateContext() need config as a parameter?
> 
> The EGL config (pixel format) sets a variety of parameters/limits for
> the rendering context.  For example, whether or not
> depth/stencil/accum buffers are present, the bit depth of each,
> whether there's 2 or 4 colorbuffers (double buffered, stereo), color
> index mode vs. RGB, etc.
> 
> Later, when a rendering context is bound to a drawing surface, we need
> to make sure the context and surface are compatible by comparing their
> EGL configs.

I didn't understand that the Context was created with initial limits.
Instead I thought that the context should just adapt to whatever
surface was being bound. I'm still not sure that I have this
implemented correctly so I will need to check this out when my code is
working better.

-- 
Jon Smirl
jonsmirl at gmail.com