On Fri, Aug 14, 2009 at 05:08:00PM +0100, Jakob Bornecrantz wrote:
> I don't know how well creating two or more displays from the same
> driver works with the old/new API. I'm guessing with the old one it
> would load the driver twice. From what I can see from the code it
> looks like your does as well.
> The biggest point is that you should move the "const char *args"
> away from the function which create the driver to something which
> creates a EGLDisplay instance.
I think the args of _eglMain should be ignored now. It is not used, and
thus it is not used to pass "card0", etc.
Recall that the argument of eglGetDisplay is EGLNativeDisplayType. It
gives the native display of the native window system. When
"!EGL_radeon:card0" is passed to eglGetDisplay, it assumes the native
window system to use. Let's call it ADHOC window system.
For all drivers loaded by EGL core, they must agree on the native window
system. For example, egl_softpipe supports X window system. What would
happen if one calls eglGetDisplay("!egl_softpipe")? It simply crashes
because egl_softpipe would treat the string as a "Display *".
Logically, the EGL core should stay window system neutral. But a
problem arises. How does it know which drivers to load? Two ways are
obvious and already used: assume a default driver, or out-of-band
mechanisms such as environment variables.
There is another way that is currently in use. That is, it assumes the
drivers use ADHOC window system. And it extracts from the native
display of ADHOC, which is a string, the driver to load. This is a hack
though because the drivers might not use ADHOC window system. Anyway,
in this point of view, when driver's eglInitialize is called, it is
given the native display, something like "!EGL_radeon:card0". As it is
ADHOC window system that the driver supports, it makes perfect sense
that the driver parses the native display and knows it should initialize
card0.
While unclear from the code (this should be improved), it should be
noted that it is the drivers that supprot ADHOC window system. The EGL
core is neutral, with a hack to extract certain infomation from the
ADHOC native display.
I think this interpetation matches the "native window system" idea of
EGL spec. And it matches how the EGL core and ADHOC drivers work (or
should work) in principle. There are other ways to load drivers. One
way I might implement is to scan some directory for drivers.
--
Regards,
olv
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
