EGL and X spec ambiguities
brian.paul at tungstengraphics.com
Mon Dec 10 08:38:57 PST 2007
michael giovinco wrote:
> On Dec 10, 2007 10:38 AM, Brian Paul <brian.paul at tungstengraphics.com
> <mailto:brian.paul at tungstengraphics.com>> wrote:
> I think Tom mostly answered your question, but I think the crux of your
> problem is the difference in interpretation of "Display".
> There's the X concept of Display which can be a collection of screens
> which is controlled by the X server. Or you can think of the Xlib
> 'Display' datatype which has a default screen field and can identify a
> particular screen.
> For multi-screen EGL, I think you'd simply have to obtain an EGLDisplay
> handle for each screen.
> Yes, in X, a display can have multiple screens but it's not the same in
> EGL. That's the problem. Your solution would be ideal, but how would you
> do it? How would you get an EGLDisplay handle for each screen when
> eglGetDisplay wants a X Display as a parameter. Calling XOpenDisplay
> multiple times to create multiple X Display structures is not a option.
> X applications don't work that way. The application only wants a single
> "display" with multiple screens.
OK, I think I know what you're getting at.
An Xlib application _can_ be written to call XOpenDisplay(),
eglGetDisplay(), etc. per screen. But it's inconvenient and probably
doesn't mesh well with toolkits that probably base their event loops,
etc. on the assumption that there's just one Display* connection to deal
I don't see a good way to reconcile those differences either.
I guess if this is really an important issue to solve, you might look
into writing an EGL extension for multi-screen support. Note that
eglCreateWindow/Context(), etc. all take a general-purpose attrib_list
parameter through which you could pass a screen index.
More information about the dri-egl