Alex Deucher wrote:

Ok I've started taking a look at this, unfortunately, I can't seem to
find where libGL and GLCore live in the course tree.  According to the
FAQ:

"The GLcore extension source code resides at
xc/programs/Xserver/GL/mesa/src/ . "

and,

"3.3.2. Where does libGL reside?

The GLcore extension source code resides at xc/lib/GL/GL/ . "

However, the directories seems to be empty.  I remember some talk a
while back about changing the tree around, but I didn't think that
actually happened.  Anyway, if someone would be so kind as to point me
in the right direction I'd appreciate it.

Most of the intersting libGL code comes from xc/lib/GL/glx. HOWEVER as part of the build process stuff gets copied around. Look in your build tree. There's also some interesting code in xc/lib/GL/dri. Most of those files get built into the client-side driver though.


The FAQ should be updated to say that these directories get populated during the build process.

and just to double check,

DRI aware drivers live here:
xc/lib/GL/mesa/src/drv


glx lives here:
xc/lib/GL/glx/

how do these files relate:
xc/programs/Xserver/GL/mesa/src/X/

All of the files in xc/programs/Xserver/GL get built into either libglx.a or libGLcore.a. This is another case where a lot of things get copied around in the build process. Most of the files in .../mesa/src come from xc/extras/Mesa/src. The part that lives in .../mesa/src/X are, basically, the changes that need to be made to Mesa for it to communicate with the GLX extension from within the X-server. When the build happens parts of Mesa get copied there and libGLcore.a is built.


Also, in regards to 3D with xinerama, I have an idea.  if we can get HW
indirect rendering 3D working on indepenant heads, one could run dmx
(dmx.sf.net) and use glproxy to get xinerama working. (can't seem to
access sourceforge ATM).  it's not optimal, but it's an interim
solution.

I'm not 100% up to speed on Xinerama. I believe that it works by giving multiple physical devices a single screen ID. If there's only a single screen ID, there's no way for glproxy to tell the X-server to use one physical display versus another.





------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to