mesa3d-users Mailing List for Mesa3D

Stephen J Baker <sj...@li...> wrote:
>On Thu, 31 Jan 2002, Brian Paul wrote:
>
>> Raul Dias wrote:
>>
>> > So, compiling OpenGL programs with XFree86's GL includes will have
>> > performance/problems/issues when running with the stand alone Mesa?
>> > and the other way around?
>>
>> Extensions aside, the header files you use should not make any difference.
>>
>> In a degenerate case, suppose an application looks for the hypothetical
>> GL_EXT_magic_pormance_boost extension but doesn't find that token in
>> the header file.  The application will then be compiled and run without
>> that extension.  Having a newer header file which defines that token
>> would allow the application to take advantage of that feature.
>>
>> That kind of thing is rare though.
>
>Yep. More than that - it's a method of writing code that is now deprecated
>in favor of using the glxGetProcAddress thingy.  You should always be
>able to get the latest and greatest gl.h from www.opengl.org which
>contains (in theory) *ALL* extension definitions and which is valid
>with *ALL* OpenGL implementations.

So, I ask:
Does this include have all Mesa and DRI/XFree86 Extentions?



>It shouldn't matter which OpenGL implementation you compile against.
>
>If you write the code correctly, you can compile against Mesa and
>run with the nVidia libraries - or vice-versa.

That's what I am looking for.

Regards,

Raul Dias

On Thu, 31 Jan 2002, Brian Paul wrote:

> Raul Dias wrote:
>
> > So, compiling OpenGL programs with XFree86's GL includes will have
> > performance/problems/issues when running with the stand alone Mesa?
> > and the other way around?
>
> Extensions aside, the header files you use should not make any difference.
>
> In a degenerate case, suppose an application looks for the hypothetical
> GL_EXT_magic_pormance_boost extension but doesn't find that token in
> the header file.  The application will then be compiled and run without
> that extension.  Having a newer header file which defines that token
> would allow the application to take advantage of that feature.
>
> That kind of thing is rare though.

Yep. More than that - it's a method of writing code that is now deprecated
in favor of using the glxGetProcAddress thingy.  You should always be
able to get the latest and greatest gl.h from www.opengl.org which
contains (in theory) *ALL* extension definitions and which is valid
with *ALL* OpenGL implementations.

It shouldn't matter which OpenGL implementation you compile against.

If you write the code correctly, you can compile against Mesa and
run with the nVidia libraries - or vice-versa.

----
Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://www.sjbaker.org

Raul Dias wrote:

> So, compiling OpenGL programs with XFree86's GL includes will have
> performance/problems/issues when running with the stand alone Mesa?
> and the other way around?

Extensions aside, the header files you use should not make any difference.

In a degenerate case, suppose an application looks for the hypothetical
GL_EXT_magic_pormance_boost extension but doesn't find that token in
the header file.  The application will then be compiled and run without
that extension.  Having a newer header file which defines that token
would allow the application to take advantage of that feature.

That kind of thing is rare though.


> >> >> If I have to delete one set of includes (and keep the other one)
> >> >> which one would be more complete to keep?
> >> >
> >> >In general, keep whichever is newer.
> >>
> >> which is.... ?
> >
> >Look at the version numbers or file sizes.  A larger GL/gl.h and
> >GL/glext.h generally indicates a newer one.
> 
> So, with this I assume that for my above question the answer is no, right?

Correct.


> Thnak you one more time for your time and answers.

You're welcome.  I've asked the DRI FAQ maintainer to include some
of this information in the FAQ.  Like I said, I've been answering
similar questions quite frequently.

-Brian

Brian Paul <br...@tu...> wrote:
>Raul Dias wrote:
>> Brian Paul <br...@tu...> wrote:
>
>It's different.  When you build stand-alone Mesa with Glide
>you wind up with a libGL.so library like this:
>
>+----- libGL.so ----+
>|   GL dispatcher   |
>|     Mesa core     |
>| Mesa/Glide driver |
>+-------------------+
>
>In the XFree86/DRI system, things are arranged more like this:
>
>   +---- libGL.so -----+
>   |   GL dispatcher   |
>   | DRI driver loader |
>   +-------------------+
>             |
>  +--- radeon_dri.so ----+
>  |      Mesa core       |
>  | radeon-specific code |
>  +----------------------+
>             |
>+---------------------------+
>|  Xserver/kernel/hardware  |
>+---------------------------+
>

This makes a lot clear their differences.
I had no idea that the mesa core was in the driver lib (if any).


>
>It's a VERY common misconception that someone can "upgrade" the
>Mesa code used in XFree86/DRI by simply downloading MesaLib-X.Y.tar.gz,
>compiling it, putting the new libGL.so in /usr/lib and be good to go.
>
>Wrong.
>
>I guess I've got to find a better way to make this known but it
>seems that few people read documentation anymore.

I know about this, this was not the point I was trying to get.


>
>
>> >The DRI drivers support different sets of extensions, as does
>> >software Mesa.
>> 
>> So, specifically in the latest release of Mesa and the latest release of
>> XFree86 (4.2.0) which differences can I expect between them?
>> 
>> Can't one incorporate the other?
>> 
>> If no why not?
>
>See above.  Even if you copy the new Mesa sources files into the
>xc/extras/Mesa/src directory and recompile XFree86 you'll probably
>run into compilation issues because Mesa's internal data structures
>often change from release to release.  You've got to update the
>hardware driver code as well.

I am not talking about the source code.
I am talking just about the include files.

So, compiling OpenGL programs with XFree86's GL includes will have
performance/problems/issues when running with the stand alone Mesa?
and the other way around?




>> >> If I have to delete one set of includes (and keep the other one)
>> >> which one would be more complete to keep?
>> >
>> >In general, keep whichever is newer.
>> 
>> which is.... ?
>
>Look at the version numbers or file sizes.  A larger GL/gl.h and
>GL/glext.h generally indicates a newer one.

So, with this I assume that for my above question the answer is no, right?


Thnak you one more time for your time and answers.


Raul Dias

Raul Dias wrote:
> 
> Brian Paul <br...@tu...> wrote:
> 
> >> Are the included files compatible?
> >Yes.
> >> Can I compile a GL application using XFree86 includes and run
> >> with standalone Mesa later?
> >Yes.
> >> Can I compile using Mesa includes and libs and then run using
> >> DRI?
> >Yes.
> >
> >
> >> Will I loose any feature in either way?
> >
> >Yes.
> >
> >When you run an OpenGL application with any implementation of OpenGL
> >you have to be prepared for different features sets (different
> >extensions or different versions (1.1, 1.2, 1.3)).  That's an issue
> >completely independent of Mesa/DRI/etc.
> 
> Yes, but Mesa is used to implement DRI.

Yes, but it's really not essential to the DRI.  Someone could write a
DRI driver that doesn't use Mesa at all.


> The little I understand about DRI is that Mesa gives DRI the
> generic hooks for the driver to use the DRI.

Not really.  The guts of Mesa are incorporated with some hardware-
specific code to form a DRI driver (i.e. radeon_dri.so).  Mesa
IS NOT used in its entirety in these drivers.  The dispatcher
is omitted (it's in libGL.so) and the typical software rendering
drivers (XMesa and OSMesa, etc) are omitted.


> Almost what Mesa does with Glide.

It's different.  When you build stand-alone Mesa with Glide
you wind up with a libGL.so library like this:

+----- libGL.so ----+
|   GL dispatcher   |
|     Mesa core     |
| Mesa/Glide driver |
+-------------------+

In the XFree86/DRI system, things are arranged more like this:

   +---- libGL.so -----+
   |   GL dispatcher   |
   | DRI driver loader |
   +-------------------+
             |
  +--- radeon_dri.so ----+
  |      Mesa core       |
  | radeon-specific code |
  +----------------------+
             |
+---------------------------+
|  Xserver/kernel/hardware  |
+---------------------------+


It's a VERY common misconception that someone can "upgrade" the
Mesa code used in XFree86/DRI by simply downloading MesaLib-X.Y.tar.gz,
compiling it, putting the new libGL.so in /usr/lib and be good to go.

Wrong.

I guess I've got to find a better way to make this known but it
seems that few people read documentation anymore.


> >The DRI drivers support different sets of extensions, as does
> >software Mesa.
> 
> So, specifically in the latest release of Mesa and the latest release of
> XFree86 (4.2.0) which differences can I expect between them?
> 
> Can't one incorporate the other?
> 
> If no why not?

See above.  Even if you copy the new Mesa sources files into the
xc/extras/Mesa/src directory and recompile XFree86 you'll probably
run into compilation issues because Mesa's internal data structures
often change from release to release.  You've got to update the
hardware driver code as well.

My advice is to just live with the version of Mesa you have in
XFree86/DRI.  Be patient - the next version of XFree86 will have
the latest appropriate version of Mesa (a stable release, not a
development release).


> >> If I have to delete one set of includes (and keep the other one)
> >> which one would be more complete to keep?
> >
> >In general, keep whichever is newer.
> 
> which is.... ?

Look at the version numbers or file sizes.  A larger GL/gl.h and
GL/glext.h generally indicates a newer one.


> Sorry for this bunch of questions, but I need to understand this
> issue to argue with the distribution I use about their layout.

You're not the only one asking these questions.  I guess I've got
to find a better way of getting the word out.

-Brian

Brian Paul <br...@tu...> wrote:

>> Are the included files compatible?
>Yes.
>> Can I compile a GL application using XFree86 includes and run
>> with standalone Mesa later?
>Yes.
>> Can I compile using Mesa includes and libs and then run using
>> DRI?
>Yes.
>
>
>> Will I loose any feature in either way?
>
>Yes.
>
>When you run an OpenGL application with any implementation of OpenGL
>you have to be prepared for different features sets (different
>extensions or different versions (1.1, 1.2, 1.3)).  That's an issue
>completely independent of Mesa/DRI/etc.

Yes, but Mesa is used to implement DRI.
The little I understand about DRI is that Mesa gives DRI the 
generic hooks for the driver to use the DRI.
Almost what Mesa does with Glide.

>
>The DRI drivers support different sets of extensions, as does
>software Mesa.

So, specifically in the latest release of Mesa and the latest release of
XFree86 (4.2.0) which differences can I expect between them?

Can't one incorporate the other?

If no why not?

>
>
>> If I have to delete one set of includes (and keep the other one)
>> which one would be more complete to keep?
>
>In general, keep whichever is newer.  

which is.... ?


Sorry for this bunch of questions, but I need to understand this 
issue to argue with the distribution I use about their layout.


Raul Dias

Raul Dias wrote:
> 
> Hi,
> 
> What is the status of interchange of Mesa and XFree86 (DRI)?
> (refering to the latest version of both: Mesa 4.x and
> XFree86 4.2.0)
> 
> Are the included files compatible?

Yes.


> Can I compile a GL application using XFree86 includes and run
> with standalone Mesa later?

Yes.


> Can I compile using Mesa includes and libs and then run using
> DRI?

Yes.


> Will I loose any feature in either way?

Yes.

When you run an OpenGL application with any implementation of OpenGL
you have to be prepared for different features sets (different
extensions or different versions (1.1, 1.2, 1.3)).  That's an issue
completely independent of Mesa/DRI/etc.

The DRI drivers support different sets of extensions, as does
software Mesa.


> If I have to delete one set of includes (and keep the other one)
> which one would be more complete to keep?

In general, keep whichever is newer.  Then you'll have the declarations
for the newer extensions.


> I am talking about library compatibility and eficience
> for compilation.  I actually have harsware that works with
> standalone Mesa (voodoo2) and other that uses DRI.
> 
> knowing the issues regading both implementations would help me
> compile programs only one time for each case.
> 
> Thanks.
> 
> Raul Dias

-Brian

Hi,


What is the status of interchange of Mesa and XFree86 (DRI)?
(refering to the latest version of both: Mesa 4.x and 
XFree86 4.2.0)

Are the included files compatible?
Can I compile a GL application using XFree86 includes and run
with standalone Mesa later?
Can I compile using Mesa includes and libs and then run using 
DRI?

Will I loose any feature in either way?
If I have to delete one set of includes (and keep the other one)
which one would be more complete to keep?

I am talking about library compatibility and eficience 
for compilation.  I actually have harsware that works with
standalone Mesa (voodoo2) and other that uses DRI.

knowing the issues regading both implementations would help me
compile programs only one time for each case.


Thanks.

Raul Dias

Lily Tse wrote:
> 
> hi,
>    i downloaded mesa-4.0 for Linux, HPUX, and Solaris.  I made and ran the
> executable files in the widgets-mesa/demo directories.  However, it seems
> like some of the buttons on those display windows are not working
> properly.  For example, for the demo executable file "tea" and "tea-m" on
> Linux and Solaris, the initial teapot is in gold color.  But when i
> clicked on the button ruby or emerald, the teapot just disappered.  But it
> seem to work fine on HPUX.  Other ones that have similar problems are ed
> and ed-m.  Their "next" and "exit" buttons do not seem to respond at
> all.  Does anyone has an idea of what's going on and how to fix the
> problem?  Thanks in advance....

Someone else had problems with these demos too within the past month
(though it was crashing for them).

In widgets-mesa/include/GL/MesaDrawingAreaP.h comment out or delete
this line near the end:

#define AVOID_MESABUFFER_INTERFACE 1

then rebuild and retest.

-Brian

Song KiSun wrote:
> 
> Hello.
> I'm using Redhat 7.2 beta version that got a Mesa 3.4.x.
> For upgrade, I uninstalled that rpm, and I compiled and installed
> Mesa-4.0.1 with oss-opengl.

Stand-alone Mesa knows nothing about the DRI.  If you install
the stand-alone Mesa's libGL you're going to lose DRI accelaration.
If you want to use the DRI, you just have to live with the version
of Mesa that it's based on.  Upgrading the Mesa version which DRI
uses is not that simple.


> Then, I runned Quake3, but it doesn't work.
> 
> ***********************************************************
>  You are using software Mesa (no hardware acceleration)!
>  Driver DLL used: libGL.so
>  If this is intentional, add
>        "+set r_allowSoftwareGL 1"
>  to the command line when starting the game.
> ***********************************************************
> 
> TuxRacer is too slow..

As expectecd.


> I down loaded DRIsetup-linux-i386, It tells DRI is all right.
> 
> Your config file is /etc/X11/XF86Config-4
> Your module path is /usr/X11R6/lib/modules
> You are running in Mesa X11 Direct Rendering Mode

That message, unfortunately, isn't completely unambiguous.
You're using software rendering.


> How can I repair my sytem.

Uninstall Mesa 4.0.1 and re-install the Mesa-3.4.2-7.rpm from your
RedHat CD.  Then you'll have the correct libGL.so for the DRI.

-Brian

Hello.
I'm using Redhat 7.2 beta version that got a Mesa 3.4.x.
For upgrade, I uninstalled that rpm, and I compiled and installed 
Mesa-4.0.1 with oss-opengl.

Then, I runned Quake3, but it doesn't work.

***********************************************************
 You are using software Mesa (no hardware acceleration)!   
 Driver DLL used: libGL.so
 If this is intentional, add
       "+set r_allowSoftwareGL 1"
 to the command line when starting the game.
***********************************************************

TuxRacer is too slow..

I down loaded DRIsetup-linux-i386, It tells DRI is all right.

Your config file is /etc/X11/XF86Config-4
Your module path is /usr/X11R6/lib/modules
You are running in Mesa X11 Direct Rendering Mode



How can I repair my sytem.

My graphic card is Matrox G450, and here is my kernel's config.

CONFIG_AGP=y
CONFIG_DRM=y
CONFIG_DRM_MGA=y

Zeljko Blace wrote:
> 
> On Tue, 29 Jan 2002, Brian Paul wrote:
> 
> > Zeljko Blace wrote:
> > >
> > > Is there any chance to get support for BeOS ?
> > > BeOS 5.03 Personal Edition can be freely downloaded
> > > from Bebits.com, can some of th developers use it to
> > > update Mesa for BeOS?
> > >
> > > since native support for OpenGL is disabled in this now abandonware
> > > slowly turnning into OpenSource with OpenBeOS
> >
> > I had written a BeOS 4.x driver back in Mesa 3.0 or 3.1, I think.
> > It no longer works in the later versions of Mesa since I haven't
> > had time to maintain it.
> >
> > However, it probably wouldn't take too long to resurrect it.
> > The code is in Mesa/src/BeOS/
> >
> > -Brian
> 
> Dear Brian,
> I know of this fact...
> That is way I am contacting you about this
> as you have overview of BeOS system. There is
> currently no real support for OpenGL as Be Inc.
> disabled native support becuse of instability
> and new version (officialy unreleased) BeOS 5.1
> has new one which is broken.
> 
> Would you be able to do quick patch that would get
> it running again. I have no programming skills
> (other than JavaScripting).

Sorry, I really don't have enough time available to do that.  Aren't
there any other BeOS developers who might do it?

-Brian

On Tue, 29 Jan 2002, Brian Paul wrote:

> Zeljko Blace wrote:
> > 
> > Is there any chance to get support for BeOS ?
> > BeOS 5.03 Personal Edition can be freely downloaded
> > from Bebits.com, can some of th developers use it to
> > update Mesa for BeOS?
> > 
> > since native support for OpenGL is disabled in this now abandonware
> > slowly turnning into OpenSource with OpenBeOS
> 
> I had written a BeOS 4.x driver back in Mesa 3.0 or 3.1, I think.
> It no longer works in the later versions of Mesa since I haven't
> had time to maintain it.
> 
> However, it probably wouldn't take too long to resurrect it.
> The code is in Mesa/src/BeOS/
> 
> -Brian

Dear Brian,
I know of this fact...
That is way I am contacting you about this 
as you have overview of BeOS system. There is 
currently no real support for OpenGL as Be Inc. 
disabled native support becuse of instability
and new version (officialy unreleased) BeOS 5.1 
has new one which is broken.

Would you be able to do quick patch that would get 
it running again. I have no programming skills
(other than JavaScripting).

Regards,
Zeljko.

hi,
   i downloaded mesa-4.0 for Linux, HPUX, and Solaris.  I made and ran the
executable files in the widgets-mesa/demo directories.  However, it seems
like some of the buttons on those display windows are not working
properly.  For example, for the demo executable file "tea" and "tea-m" on
Linux and Solaris, the initial teapot is in gold color.  But when i
clicked on the button ruby or emerald, the teapot just disappered.  But it
seem to work fine on HPUX.  Other ones that have similar problems are ed
and ed-m.  Their "next" and "exit" buttons do not seem to respond at
all.  Does anyone has an idea of what's going on and how to fix the
problem?  Thanks in advance....

       						       Lily Tse
						lt...@ch...

Zeljko Blace wrote:
> 
> Is there any chance to get support for BeOS ?
> BeOS 5.03 Personal Edition can be freely downloaded
> from Bebits.com, can some of th developers use it to
> update Mesa for BeOS?
> 
> since native support for OpenGL is disabled in this now abandonware
> slowly turnning into OpenSource with OpenBeOS

I had written a BeOS 4.x driver back in Mesa 3.0 or 3.1, I think.
It no longer works in the later versions of Mesa since I haven't
had time to maintain it.

However, it probably wouldn't take too long to resurrect it.
The code is in Mesa/src/BeOS/

-Brian

Is there any chance to get support for BeOS ? 
BeOS 5.03 Personal Edition can be freely downloaded 
from Bebits.com, can some of th developers use it to 
update Mesa for BeOS? 

since native support for OpenGL is disabled in this now abandonware
slowly turnning into OpenSource with OpenBeOS

FYI, thought you might like to know that I was able to use MSYS and
MinGW native utilities to build the Win32/MinGW version of Mesa-1.0.4 on
a Win32 platform.  See mingw.sf.net for more details.

Earnie.

-------- Original Message --------
Subject: [Mingw-users] [ANNOUNCEMENT] MSYS-1.0.4 released.
Date: Sat, 26 Jan 2002 10:44:12 -0500
From: Earnie Boyd <ear...@ya...>
Reply-To: Earnie Boyd <min...@li...>
To: Earnie Boyd <min...@li...>,Earnie Boyd
<Min...@li...>

I've just released MSYS-1.0.4 which you can find at
http://sf.net/project/showfiles.php?group_id=2435 the MinGW file list
page.  With this release symlinks used as arguments are resolved before
they are passed to the native program.

I've successfully executed configure and make for the following:

hello-1.3             (www.gnu.org)
Mesa-4.0.1            (mesa3d.sf.net)
SDL-1.2.3             (www.libsdl.org)


Have fun with it,
Earnie.

P.S.: I've been chosen by upper management to attend a 2 day training
class.  I'll not be attending mail during the day this Monday and
Tuesday,  Jan 28th and 29th.  I'll try to get to it in the evening but
that might not be possible.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


_______________________________________________
MinGW-users mailing list
Min...@li...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Hi when i suggested the deletion of GLX_DEPTH_SIZE, 12
from ..., I am wrong, after "talk" with Brian 
I think, you should try 
GLX_DEPTH_SIZE, 1



Citando Lily Tse <lt...@ch...>:

} hi,
} 	i already ran xdpyinfo. However, i am not sure how
} to interpret
} the information to know whether or not TrueColor
} visuals can be
} seen.  Also, i am not sure how to modify the program
} so that it can run
} with TrueColor.
} Someone suggested the deletion of GLX_DEPTH_SIZE, 12
} from 
} static int snglBuf[] = {GLX_RGBA, GLX_DEPTH_SIZE, 12,
} GLX_RED_SIZE, 1,
} None};
} and 
} static dblBuf[] = {GLX_RGBA, GLX_DEPTH_SIZE, 12,
} GLX_RED_SIZE, 1, None};
} in the program.  
} I did what he suggested.  However, i get the same
} error
} message. I am attaching a copy of the
} program code "glw.c" and the output of running
} xdpyinfo.  Please take a
} look at both of these files and give me further
} advices on how to solve
} the "Error: no support for non-TrueColor visual." 
} Thanks for all your
} time.
} 
} LT
} 
} > Lily Tse wrote:
} > > 
} > > hi,
} > >   i tried compiling a file name "glw.c" on
} Solaris.  The executable was
} > > generated.  However, when i run the executable, i
} get the error message
} > > "Error: no support for non-TrueColor visual". 
} Does anyone know what this
} > > message mean and how this problem can be solved? 
} Thanks
} > 
} > Run xdpyinfo or glxinfo and look if any PseudoColor
} or StaticColor
} > visuals are listed.
} > 
} > You're probably running with a 24-bit or
} 16-bit/pixel display configuration.
} > This basically limits you to TrueColor and
} DirectColor visuals since nobody
} > has hardware with 16 or 24-bit color look-up
} tables.
} > 
} > You'll probably have to run your display at 8bpp in
} order to get around
} > that error, or modify the application itself so it
} can run with TrueColor.
} > 
} > -Brian
} > 
} 
}        						       
Lily Tse
} 					
	lt...@ch...
} 



Sérgio Monteiro Basto
		

--------------------------------------------
Webmail da rede SAPO - http://webmail.sapo.pt/

Lily Tse wrote:
> 
> hi Brian,
>         first of all, thanks for your helpful and prompt reply.  The
> TrueColor error has been resolved.  Now I have some other questions to
> ask.  I downloaded mesa-4.0 for the Linux, HPUX, and Solaris platforms.
> In each of those packets, ther's a widgets-mesa/demos directory that
> contains some demo files.  All of them can be compiled and the executables
> can be generated.  However, only one executable can be run.  All the
> other executables gave me error messages when I ran them.  In HPUX, the
> error message is "sh: 23837 Bus error"; in Solaris, "Segmentation
> Fault"; and in Linux, it doesn't give me any output.  Also, the file that
> i have the True Color Visual problem with, "glw.c", can run in
> Solaris now, after following your suggestion.  But I get a similar
> problem as described above when I ran it in
> Linux.  The executable shows me no output.  Do you know why this is
> happening and how it can be to solved?

edit widgets-mesa/include/GL/MesaDrawingAreaP.h and delete this line
from near the end of the file:

#define AVOID_MESABUFFER_INTERFACE 1

Then, do:

cd widgets-mesa/
make clean
make



I have no idea what AVOID_MESABUFFER_INTERFACE was intended for
(I didn't write the code) but it causes bad things.

-Brian

hi Brian,
	first of all, thanks for your helpful and prompt reply.  The
TrueColor error has been resolved.  Now I have some other questions to
ask.  I downloaded mesa-4.0 for the Linux, HPUX, and Solaris platforms.
In each of those packets, ther's a widgets-mesa/demos directory that
contains some demo files.  All of them can be compiled and the executables
can be generated.  However, only one executable can be run.  All the
other executables gave me error messages when I ran them.  In HPUX, the
error message is "sh: 23837 Bus error"; in Solaris, "Segmentation
Fault"; and in Linux, it doesn't give me any output.  Also, the file that
i have the True Color Visual problem with, "glw.c", can run in
Solaris now, after following your suggestion.  But I get a similar
problem as described above when I ran it in
Linux.  The executable shows me no output.  Do you know why this is
happening and how it can be to solved?  
Thanks....  
  

       						       Lily Tse
						lt...@ch...

You never said if you're using Mesa or Sun's OpenGL.  But since you're
posting here, I'll assume Mesa.

Try the following before running the program:

setenv MESA_RGB_VISUAL "TrueColor 8"

or

export MESA_RGB_VISUAL="TrueColor 8"

depending on the shell you're using.

This environment variable will force Mesa to choose an 8-bit TrueColor
visual (which xdpyinfo reports that you have) instead of an 8-bit
PseudoColor visual.

The reason Mesa prefers a PseudoColor visual over a TrueColor visual
is to eliminate colormap flashing.  xpyinfo reports that your screen
has one colormap and that the default/root visual is PseudoColor.
If Mesa were to choose any visual besides the 8-bit PseudoColor visual
then you'd see colormap flashing whenever focus goes in or out of
your OpenGL window (because colormaps can't be shared among windows
with different visual classes).

In this case, you'll just have to put up with colormap flashing
since the program won't run any other way.  Of course, you could
modify the program to do something more intelligent in the
getShareableColormap() function.

Another possibility is to try running your X display at 16 or 24 bpp.
But I have no idea what kind of graphics hardware you have.

-Brian



Lily Tse wrote:
> 
> hi,
>         i already ran xdpyinfo. However, i am not sure how to interpret
> the information to know whether or not TrueColor visuals can be
> seen.  Also, i am not sure how to modify the program so that it can run
> with TrueColor.
> Someone suggested the deletion of GLX_DEPTH_SIZE, 12 from
> static int snglBuf[] = {GLX_RGBA, GLX_DEPTH_SIZE, 12, GLX_RED_SIZE, 1,
> None};
> and
> static dblBuf[] = {GLX_RGBA, GLX_DEPTH_SIZE, 12, GLX_RED_SIZE, 1, None};
> in the program.
> I did what he suggested.  However, i get the same error
> message. I am attaching a copy of the
> program code "glw.c" and the output of running xdpyinfo.  Please take a
> look at both of these files and give me further advices on how to solve
> the "Error: no support for non-TrueColor visual."  Thanks for all your
> time.
> 
> LT
> 
> > Lily Tse wrote:
> > >
> > > hi,
> > >   i tried compiling a file name "glw.c" on Solaris.  The executable was
> > > generated.  However, when i run the executable, i get the error message
> > > "Error: no support for non-TrueColor visual".  Does anyone know what this
> > > message mean and how this problem can be solved?  Thanks
> >
> > Run xdpyinfo or glxinfo and look if any PseudoColor or StaticColor
> > visuals are listed.
> >
> > You're probably running with a 24-bit or 16-bit/pixel display configuration.
> > This basically limits you to TrueColor and DirectColor visuals since nobody
> > has hardware with 16 or 24-bit color look-up tables.
> >
> > You'll probably have to run your display at 8bpp in order to get around
> > that error, or modify the application itself so it can run with TrueColor.
> >
> > -Brian
> >
> 
>                                                        Lily Tse
>                                                 lt...@ch...
> 
>   ------------------------------------------------------------------------------
>             Name: glw.c
>    glw.c    Type: text (TEXT/PLAIN)
>         Encoding: BASE64
> 
>            Name: xdpy
>    xdpy    Type: text (TEXT/PLAIN)
>        Encoding: BASE64

hi,
	i already ran xdpyinfo. However, i am not sure how to interpret
the information to know whether or not TrueColor visuals can be
seen.  Also, i am not sure how to modify the program so that it can run
with TrueColor.
Someone suggested the deletion of GLX_DEPTH_SIZE, 12 from 
static int snglBuf[] = {GLX_RGBA, GLX_DEPTH_SIZE, 12, GLX_RED_SIZE, 1,
None};
and 
static dblBuf[] = {GLX_RGBA, GLX_DEPTH_SIZE, 12, GLX_RED_SIZE, 1, None};
in the program.  
I did what he suggested.  However, i get the same error
message. I am attaching a copy of the
program code "glw.c" and the output of running xdpyinfo.  Please take a
look at both of these files and give me further advices on how to solve
the "Error: no support for non-TrueColor visual."  Thanks for all your
time.

LT

> Lily Tse wrote:
> > 
> > hi,
> >   i tried compiling a file name "glw.c" on Solaris.  The executable was
> > generated.  However, when i run the executable, i get the error message
> > "Error: no support for non-TrueColor visual".  Does anyone know what this
> > message mean and how this problem can be solved?  Thanks
> 
> Run xdpyinfo or glxinfo and look if any PseudoColor or StaticColor
> visuals are listed.
> 
> You're probably running with a 24-bit or 16-bit/pixel display configuration.
> This basically limits you to TrueColor and DirectColor visuals since nobody
> has hardware with 16 or 24-bit color look-up tables.
> 
> You'll probably have to run your display at 8bpp in order to get around
> that error, or modify the application itself so it can run with TrueColor.
> 
> -Brian
> 

       						       Lily Tse
						lt...@ch...

S=E9rgio Monteiro Basto wrote:
>=20
> Brian Paul wrote <br...@tu...>:
> }
> } I'm not sure I understand you.  If you comment out
> } the
> } GLX_DEPTH_SIZE, 24, elements you're telling GLX that
> } you
> } don't need a depth (Z) buffer.  So,
> } glEnable(GL_DEPTH_TEST)
> } without a depth buffer doesn't make much sense (in
> } fact
> } Mesa warns you if you try this, if the MESA_DEBUG env
> } var
> } is set).
> }
> } As far as I can tell, the program does exactly what
> } it's
> } supposed to do.
> }
> } -Brian
> }
> Ok, I do need depth,
> I supposed the dblbuf[], is to help GLX choose the best visual,
> not to "tell don't need a depth (Z) buffer", and glEnable()
> enables or tell need depth (Z) buffer.
> you are right!
> but if I don?t know the depth size,
> the problem is exactly, must give one size,
>  because for example if I want the application works in
> different computers that have different depth sizes?
> or can I use dblbuf[] with just GLX_DEPTH_SIZE without 24 ?

Use 1.  That tells GLX to choose the visual with the deepest
Z buffer.  See the man page for glXChooseVisual at:
http://www.opengl.org/developers/documentation/man_pages/hardcopy/GL/html=
/glx/xchoosevisual.html

-Brian

Hi.

Well, I don't think that this is a hardware-problem, because it worked
well with Mesa 3.4. It is true that Voodoo1 had only 4MB ram in total,
which was shared for framebuffer ans textures (I think 2MB for each). 
Voodoo2 has 12MB - 8MB for textures and 4MB for framebuffer. That should
be enough to run 800x600 in 16bit with 16bit Z-buffer, which was my
prefered mode.
So I still think, that it's a software problem.

Jens Leuschner

Brian Paul wrote <br...@tu...>:
} 
} I'm not sure I understand you.  If you comment out
} the
} GLX_DEPTH_SIZE, 24, elements you're telling GLX that
} you
} don't need a depth (Z) buffer.  So,
} glEnable(GL_DEPTH_TEST)
} without a depth buffer doesn't make much sense (in
} fact
} Mesa warns you if you try this, if the MESA_DEBUG env
} var
} is set).
} 
} As far as I can tell, the program does exactly what
} it's
} supposed to do.
} 
} -Brian
} 
Ok, I do need depth,
I supposed the dblbuf[], is to help GLX choose the best visual, 
not to "tell don't need a depth (Z) buffer", and glEnable() 
enables or tell need depth (Z) buffer.
you are right!
but if I don’t know the depth size,
the problem is exactly, must give one size,
 because for example if I want the application works in 
different computers that have different depth sizes?
or can I use dblbuf[] with just GLX_DEPTH_SIZE without 24 ?

thank you
Sérgio Monteiro Basto
P.S: I think the example is good to be in MesaGlxDemos	


--------------------------------------------
Webmail da rede SAPO - http://webmail.sapo.pt/