EGL and X spec ambiguities
tom at dbservice.com
Sun Dec 9 11:47:59 PST 2007
michael giovinco wrote:
> 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
I've never seen any OpenGL implementation return different fbconfigs
depending on the screen. So the screen parameter is usually not encoded
in the GLXFBConfig structure. The screen parameter is probably just for
convenience there so the application doesn't have to open a display
connection for each screen.
> 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
> 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.
Having multiple screen probably wasn't that important when OpenGL-ES was
written. After all it's mainly for embedded devices that usually have
only one screen.
Some things were removed from OpenGL-ES to simplify implementations with
the hope that the few applications that would need these features would
do it themselves. So you'll have to open multiple X/egl displays, one
for each screen, and manage those in your application.
More information about the dri-egl