linux ppc, mesa drivers and Jun

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

linux ppc, mesa drivers and Jun

Christian Ponti
hi all,
I have some problem with opengl and Jun.
I follow the instructions in http://dri.freedesktop.org/wiki/Building to
install mesa driver which manage opengl for linux. At the end opengl and
direct rendering work, tested with glxinfo.
The problem came testing it with Jun: I tryed the examples in jun
launcher and a window appears but nothing is rendered. The object is
created as is possible to see inspecting it.
I think that Jun, via DLLCC, point the wrong driver but I can not figure
out why. Taking a look inside DLLCC, JunMesaInterface
defines /usr/lib, /usr/local/lib and /usr/X11R6/lib as library
directories and the needed drivers are symlinks in /usr/lib which point
to the right place.
Any suggestion?

Christian


Reply | Threaded
Open this post in threaded view
|

Re: linux ppc, mesa drivers and Jun

Andres Fortier-2
Christian,
          about a month ago I tired to run Jun on Ubuntu and sadly found  out
the same problem you are describing :-(. As far as I could inspect, the
problem is that the rendering context is not well suited, since the call
to glXMakeCurrent:with:with: throws an error (to see this error run VW
from a console):

X11 Error:
Display:        0x08118990
Serial: 0x00015047
Major:  143
Minor:  5
XID:    0x00000000
GLXBadContext

I think (although I'm not sure about this) that the problem might be in
the creation of the drawable:

pixmapHandle := OpenGLInterface
                        glXCreateGLXPixmap: self displayHandle
                                        with: visualInfo
                                        with: aPixmap key.

I don't know if the pixmap key is a valid handler for an X pixmap (and I
find the GraphicsHandle comment confusing):

GraphicsHandle instances represent handles to various platform
WindowManager entities such as windows and pixmaps.  They are created by
the object engine which dictates their format.  The object engine
guarantees that the first 4 bytes of a GraphicsHandle can be used as a
unique key to identify the resource the GraphicsHandle references (see
GraphicsHandle>>#key).  The remaining bytes, if any, have meaning only
to the engine.

So, the first 4 bytes just UIDs or they are actually OS-dependent
references? Could someone in the list clarify this?

So, instead of debugging it I finally decided to build my own small
abstraction layer to OpenGL...

HTH,
     Andrés

Christian Ponti escribió:

> hi all,
> I have some problem with opengl and Jun.
> I follow the instructions in http://dri.freedesktop.org/wiki/Building to
> install mesa driver which manage opengl for linux. At the end opengl and
> direct rendering work, tested with glxinfo.
> The problem came testing it with Jun: I tryed the examples in jun
> launcher and a window appears but nothing is rendered. The object is
> created as is possible to see inspecting it.
> I think that Jun, via DLLCC, point the wrong driver but I can not figure
> out why. Taking a look inside DLLCC, JunMesaInterface
> defines /usr/lib, /usr/local/lib and /usr/X11R6/lib as library
> directories and the needed drivers are symlinks in /usr/lib which point
> to the right place.
> Any suggestion?
>
> Christian
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: linux ppc, mesa drivers and Jun

Christian Ponti
hi,
problem solved. I added /usr/lib/opengl/xorg-x11/lib to the library
directories under JunMesaInterface and organized file drivers and
symlinks. There are application which search in /usr/lib for drivers but
apparently with Jun it does not work, so I put there a symlink with
libGL.so pointing to the driver in /usr/lib/opengl/xorg-x11/lib.
It works fine using Jun version 736.

Christian

On Fri, 2007-03-30 at 11:21 -0300, Andres Fortier wrote:

> Christian,
>  about a month ago I tired to run Jun on Ubuntu and sadly found  out
> the same problem you are describing :-(. As far as I could inspect, the
> problem is that the rendering context is not well suited, since the call
> to glXMakeCurrent:with:with: throws an error (to see this error run VW
> from a console):
>
> X11 Error:
> Display:        0x08118990
> Serial: 0x00015047
> Major:  143
> Minor:  5
> XID:    0x00000000
> GLXBadContext
>
> I think (although I'm not sure about this) that the problem might be in
> the creation of the drawable:
>
> pixmapHandle := OpenGLInterface
> glXCreateGLXPixmap: self displayHandle
> with: visualInfo
> with: aPixmap key.
>
> I don't know if the pixmap key is a valid handler for an X pixmap (and I
> find the GraphicsHandle comment confusing):
>
> GraphicsHandle instances represent handles to various platform
> WindowManager entities such as windows and pixmaps.  They are created by
> the object engine which dictates their format.  The object engine
> guarantees that the first 4 bytes of a GraphicsHandle can be used as a
> unique key to identify the resource the GraphicsHandle references (see
> GraphicsHandle>>#key).  The remaining bytes, if any, have meaning only
> to the engine.
>
> So, the first 4 bytes just UIDs or they are actually OS-dependent
> references? Could someone in the list clarify this?
>
> So, instead of debugging it I finally decided to build my own small
> abstraction layer to OpenGL...
>
> HTH,
>      Andrés
>
> Christian Ponti escribió:
> > hi all,
> > I have some problem with opengl and Jun.
> > I follow the instructions in http://dri.freedesktop.org/wiki/Building to
> > install mesa driver which manage opengl for linux. At the end opengl and
> > direct rendering work, tested with glxinfo.
> > The problem came testing it with Jun: I tryed the examples in jun
> > launcher and a window appears but nothing is rendered. The object is
> > created as is possible to see inspecting it.
> > I think that Jun, via DLLCC, point the wrong driver but I can not figure
> > out why. Taking a look inside DLLCC, JunMesaInterface
> > defines /usr/lib, /usr/local/lib and /usr/X11R6/lib as library
> > directories and the needed drivers are symlinks in /usr/lib which point
> > to the right place.
> > Any suggestion?
> >
> > Christian
> >
> >
> >
>