EGL and X spec ambiguities

[zeAtYahoo XtraADSL]

hi,

- may i ask you how do you do it... i mean, where did you start, 
are you building up on some existing source code or writing it from scratch? 

- where does Mesa fit in your project, 
are you using any source code derived from it?

- why do you need X? in my opinion graphic driver should be lower level than windowing system, so X uses/depends on the graphic driver and not the other way around



- are you aware of Trolltech Qt, Qtopia, Qt Embedded
http://trolltech.com/downloads/


- are you aware of Scitech and MGL/SNAP drivers?
http://scitechsoft.com/products/dev/sdk_home.html


if you developing drivers you might find this interesting -
"An approach to solving the "device driver crisis"
http://www.linuxdevices.com/articles/AT4396090607.html


here is my project page:
Linux         based OpenGL development system without X
http://www.geocities.com/ze_aks/index.html




cheers,
zelko





michael giovinco <gio at post.harvard.edu> wrote: I hope this is not too much off topic but I'm working on developing
OpenGL ES drivers for NVIDIA chipsets. I'm currently working on
implementing EGL for use under X and I've run into some issue that
really confuse me. From reading the archives of this list, I've seen
that similar issues have come up before and maybe it's not just me who
has these concerns.

My main confusion is the over what EGL calls a "display". According to
the EGL 1.3 spec: "In most environments a display corresponds to a
physical screen." Notice is says "most", but not all. Later, when it
talks about how to use the function eglGetDisplay to get a display, it
uses X as an example: "... an EGL implementation under X windows would
require display_id to be an X Display...". This implies that an EGL
display is equivalent to an X display.

In X, a Display can consist of multiple X screens (a X screen being a
single head on a single device in most cases). These various screens
can refer to different heads on a single device or could even be
different heads on different devices. This means that an EGL display,
if it is truly equivalent to an X display, might actually refer to
different heads and maybe even different devices. Fortunately, when
creating a window surface in EGL we specify a window as a paramter. In
X, a window is confined to a single screen so this removes the
ambiguity as to which head and device that surface belongs to. The
problem exists when creating contexts though, since we only specify an
"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
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
specification also says that contexts and drawables must refer to the
same screen in order to be bound together. No such requirement exists
in the EGL spec, and in fact, it can't since EGL doesn't know this
information. So either the EGL display is NOT equivalent to an X
display or it is in which EGL actually allows contexts that could bind
to different devices. In the event that an EGL display shouldn't be
passed an X Display as the display_id parameter to eglGetDisplay,
well, then what is an appropriate parameter that should be used
instead? On the other hand, if an EGLDisplay is really meant to refer
to a X display then we are back to the issue of "screen-less contexts"
that I mentioned earlier. In addition, since creating pbuffers and
pixmaps doesn't require a window parameter those kinds of surfaces
would be without a screen too. How then would EGL determine on what
device they should live? Another solution is too perhaps simple use
the "default screen" as specified in the X Display structure. But this
isn't adequate either since it precludes the application from creating
a context on another screen in an X Display.

I'm sorry for the length of this post but I hope you can see my
confusion here, and I'd greatly appreciate if someone could clarify
this for me. Thanks.

- Mike
_______________________________________________
dri-egl mailing list
dri-egl at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-egl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/dri-egl/attachments/20071210/7bcd9f93/attachment.htm