EGL and X spec ambiguities

[michael giovinco]

Thanks for the response, but I still think there is a problem:

On 12/9/07, Tomas Carnecky <tom at dbservice.com> wrote:
> michael giovinco wrote:
> > "EGLDisplay" when creating a context; we don't get to specify a screen
> > or head/device parameter.  Thus we don't know what screen the context
>
> And neither do you in GLX. There you pass glXCreateContext() only a
> 'Display' as well. But to which physical screen the 'Display' points to
> was specified when you opened it (using XOpenDisplay(":0.1") for
> example). So eglCreateContext() knows on which screen to create the
> context by looking at EGLDisplay that was passed to it which points to
> an X 'Display' which has a physical screen encoded in it.
>

In GLX you call glXCreateContext with a GLXFBConfig as a parameter.
You get this config from calling glXChooseFBConfig which takes a
screen as a parameter. So, a GLX implementation can have return a
different config depending on the screen you called glXChooseFBConfig
with and thus glXCreateContext will know what screen it should use
from the config you pass it. Even though eglCreateContext also takes a
config, eglChooseConfig doesn't let you specify a screen so
eglCreateContext doesn't know as much as glXCreateContext does.

It's true you can specify a screen when you call XOpenDisplay, but
this only lets you specify the default display an application can use.
The description of the XOpenDisplay function in the xlib docs explains
this: http://tronche.com/gui/x/xlib/display/opening.html
If your display only has one screen or your application only wants to
use one screen, then you are all set and you can just let it use the
default screen. But if you want your application to display on another
screen on the same display you have to use the "ScreensOfDisplay"
macro to get the screen you want (see
http://tronche.com/gui/x/xlib/display/display-macros.html#ScreensOfDisplay).
Finally, if you look at the display structure in Xlib.h it includes a
list of screens and a pointer to the default screen.

> > refers to until we bind it to a surface (in eglMakeCurrent). Later on
> > we could rebind that context to another surface with another call to
> > eglMakeCurrent and that surface might lie on a different device. You
> > can see the obvious issues that arise when this context refers to
> > texture or vertex buffer objects that live in the video memory of one
> > device but not the other.
> >
> > I'm not sure what is the correct way to view this. In my opinion, it
> > seems to me that the EGL spec is just... wrong. GLX doesn't have this
> > problem because it requires you to specify the screen you are dealing
> > with when you are creating contexts and drawables. The GLX
>
> Where did you get that idea from? Neither XCreateContext() nor
> XCreateWindow() take a screen parameter.
>

XCreateContext doesn't but it takes a config which could store the
screen (see what I wrote above). The same is true for glXCreateWindow.
Like egl, glXCreateWindow also takes a Window paramter ("win") which
must be a valid X window, and in X, a window is limited to a specific
screen so like eglCreateWindowSurface, glXCreateWindow knows what
screen it should use.

So my concern is still the same: an X Display can contain a list of
multiple screens and while you can specify a default screen when you
call XOpenDisplay there is no way for an application using EGL to use
another screen that is not the default in a multi-screen system.

Mike