plib-users

Re: [Plib-users] Fwd: Re: flightgear problem

[Steve B. <sjb...@ai...>]

al...@tu... wrote:

> Redhat has done quite a lot for Linux imho and they are free to choose any Compiler
> version they like and no matter what teir decision is, I dont think it justifies an
> insult like "becoming another microsoft", which is probably the worst insult possible
> in the free software world. (If anybody can come up with a better one , tell us :)

Well, RedHat chose that comiler version AGAINST THE ADVICE OF THE AUTHORS.  That is a terrible
thing to do.  If you have any better explanation of why they would do that against the advice
of both the GCC and Kernel teams - I'd like to hear it.  Was it incompetance or was it
malevolance?

I don't know whether you are a software engineer or not - but imagine someone came along today
and copied whatever the current state of your project code was out of your directory and started
shipping it as a product - expecting you to support the resulting buggy mess in your own time.

I think you'd have a right to be pretty outraged by that.  RedHat had a legal right to do what
they did - but it was deeply contrary to good Internet etiquette.  The authors of GCC have a
reputation to preserve and RedHat made it look like they put out a substandard product when
in fact this was not a "released" version of the code at all.  By their actions, RH have also
caused me MANY hours of support effort trying to discover what's broken only to eventually
find that it's something caused by that damned stupid compiler decision.

> So can we just calm down and keep this type of stuff at the absolut minimum on
> the mailinglist ? This would be rather positive for the Signal/Noise ratio.

Normally I'd agree that it was off-topic but in this case, it has a direct bearing on the
performance of *MY* product - and indirectly on *MY* reputation.  When people say that PLIB
is broken - and it isn't - I think I have a right to explain in some detail *WHY* it's not
broken and advise people what to do about it.  My advice is to drop RedHat and pick a better
distro.  If you paid for RedHat then you may also have paid for customer support - and if
so, you should make FULL use of it and have THEM worry about why Mesa doesn't work with their
distro.

That's my best advice for people who have this problem.

> We can of course meet on IRC to flame about this, thats where holy distributions wars
> belong. Its also a lot more fun in realtime :)

I would prefer to avoid distro wars - but passing on the information that there is a
problem with one specific distro that affects everyone on the PLIB list (and getting into the
details of why) is not something I consider off-topic.   Since it's *MY* mailing list,
I get to do that kind of thing.

(PS: I detest IRC)
 
----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net       http://tuxaqfh.sf.net
           http://prettypoly.sf.net http://tuxkart.sf.net
           http://freeglut.sf.net   http://toobular.sf.net

Re: [Plib-users] Fwd: Re: flightgear problem

[<al...@tu...>]

I can understand why Plib - Developers/Users are annoyed about the problems with Plib and Redhat and that includes me, but lets face it there: will always be bugs and wrong decisions. 
And other Distributions had their share of problems as well.

Suse for example messed something up with X binary/lib versions which caused problems with SDL. Something I had to find out the hard way when trying to demonstrate a SDL application to a customer on one of their computers which was using this version of Suse. Not one of my pleasant memories...

I really dislike statements like "This or that high prestige group has done that"
This is more something I expect from a politician than from someone on an oss mailinglist. 
I dont know anybody who could speak for a group so vague as "power users"

Redhat has done quite a lot for Linux imho and they are free to choose any Compiler version they like and no matter what teir decision is, I dont think it justifies an insult like "becoming another microsoft", which is probably the worst insult possible in the free software world.
(If anybody can come up with a better one , tell us :)

So can we just calm down and keep this type of stuff at the absolut minimum on the mailinglist ? This would be rather positive for the Signal/Noise ratio.

We can of course meet on IRC to flame about this, thats where holy distributions wars belong. Its also a lot more fun in realtime :)

Re: [Plib-users] Fwd: Re: flightgear problem

[Steve B. <sjb...@ai...>]

pieter bonne wrote:
> 
> greetings,
> 
> First of all, thanks for such a lengthy response.. It's all quite clear to me
> now.. So in a nutshell, the problem I am experiencing is due to a bug in that
> version of mesa.. I can't really comprehend how such an important call can
> get bugged, but anyway.. Due to that bug, the context doesn't "seem" ready to
> flightgear (using plib)..

Well, there are two reason why that may have sneaked through

  * It only seems to affect RedHat 7.x and Mandrake 8 and most 'power users'
    have abandoned those two distro's following the gcc debacle.  Hence none
    of the Mesa developers are likely to have tested under RedHat to any great
    degree.

  * As you have noticed, many other programs (Quake for instance) do not bother
    to check that the current rendering context is valid.  The only reason that
    PLIB really needs to do it is that it's used by a hundred applications and
    I have no control over whether one or other of them is breaking the rules.
    Hence I need to protect the library from false allegations by doing that test.
    Quake has no need to do that - they know that they open the OpenGL window
    and that it opened without error and hence there *MUST* be a valid rendering
    context.   PLIB cannot be certain that this has happened if that application's
    author screwed up.

> I don't think the fact of the 2.96 compiler has anything to do with all
> this.. All packages I installed are compiled by this compiler!

Yes - but the problem only shows up on RedHat/Mandrake and the only thing that's
really obviously in common that could possibly have an effect is the C compiler.

You *are* aware of the 2.96/2.97 compiler "issues" - right?   The deal is (in
a nutshell) that the last released version of the GCC product was 2.95 - they
were working towards the major new 3.0.0 release but didn't get there in time
to make the RedHat 7.0 release date.  What RedHat did was to grab the "weekly
snapshot" of the pre-3.0 CVS load and release that into the world.  The GCC
team objected - RedHat didn't listen.  The Kernel team said that the kernel
wouldn't compile with 2.96 so RedHat also released the 2.95 compiler under
the name 'kgcc' - which you'll have on your disk.  However since 2.95 and 2.96
can't share the same libraries (and 2.96 can't share with 3.0 either), you can't
just recompile things like PLIB and Mesa using kgcc.

So basically, they TOTALLY screwed up RH 7.0.  Everyone complained bitterly
but *AMAZINGLY* they didn't go back to 2.95 in RH 7.1 - so the GCC team
(who get most of their funding from RedHat) gave this "bogus" version the
number 2.97...but it's still just as broken.  Mandrake (as usual) blindly
followed RedHat's lead - so Mandrake 8.0 is also "broken".

It is unsuprising under the circumstances that none of the serious developers
out there are particularly inclined to try to diagnose problems that only
affect RedHat 7.x or Mandrake 8.x under these circumstances.

Personally, I think RedHat is becoming like another Microsoft - deliberately
using incompatible versions to lock people into their software distro - hoping
that their market share is large enough to lock people in.

They shouldn't be allowed to get away with this - so, I recommend that you
keep RedHat's support lines as busy as possible with these complaints - either
that or switch to Debian, SuSE, Slackware or one of the smaller distro's.

----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net       http://tuxaqfh.sf.net
           http://prettypoly.sf.net http://tuxkart.sf.net
           http://freeglut.sf.net   http://toobular.sf.net

Re: [Plib-users] Fwd: Re: flightgear problem

[pieter b. <xa...@gm...>]

greetings,

First of all, thanks for such a lengthy response.. It's all quite clear to me 
now.. So in a nutshell, the problem I am experiencing is due to a bug in that 
version of mesa.. I can't really comprehend how such an important call can 
get bugged, but anyway.. Due to that bug, the context doesn't "seem" ready to 
flightgear (using plib).. 

I don't think the fact of the 2.96 compiler has anything to do with all 
this.. All packages I installed are compiled by this compiler!

Fact is that XFree gl-parts and Mesa drivers must me "optimized" or 
something, in order to get direct rendering to work, and that's the main 
problem I'm facing now.. However, I will overcome (or perhaps do a hack (I 
won't distribute..:) )

thanks again!
-xas-

On Saturday 25 August 2001 03:05, you wrote:
> pieter bonne wrote:
> > behold, a problem propably related to plib..
> > in addition: FlightGear _does_ work when I downgrade mesa, but I lose 3d
> > acceleration by doing this.. is there a problem with plib and mesa?
>
> You shouldn't lose 3D accelleration when you downgrade Mesa - that just
> means that you didn't install the downgraded version correctly.
>
> I explained at some length what this problem is about last night - the
> conclusion:
>
>   * This is a Mesa problem - not a PLIB problem.
>     You have shown that by the fact that a downgraded
>     Mesa works OK with FGFS/PLIB.
>
> > : >> FATAL: ssgInit called without a valid OpenGL context. <<
> >
> > This is really a plib problem that affects FlightGear.  Plib always
> > checks for a valid GL context before it begins rendering, and it's
> > obviously failing.  We haven't quite figured out what's causing this.
>
> PLIB is absolutely entitled to check that the OpenGL rendering context
> is valid before starting rendering.
>
> > : I run mandrake8, heavily customized. kernel 2.4.8enterprise (mandrake
> > : package update), bleeding edge version of XFree4.1 and Mesa-3.4.2-3 &
> > : plib-1.4.2-1 (else I wouldn't have been able to compile I believe? ;)..
>
> Mandrake 8 and RedHat 7.xx are both based on the same crappy C/C++ compiler
> version. It wouldn't at all suprise me if that ended up being the problem
> that's showing up in Mesa.  I've not heard a single problem report from
> users of other distro's.
>
> > : One interresting sidenote is that Quake3, Rune, Heretic (1 and 2),
> > : gltron and other opengl accelerated programs (like xmms visualisations
> > : ie) all work with this configuration!! Could you help me out here?
>
> Those probably don't check for a valid context - they just go ahead and
> render anyway.
>
> > All reports we've had before now where specific to RedHat, but you are
> > using Mandrake...interesting.
>
> Mandrake have always taken the RedHat distribution as their starting point.
>
> In a sense, Mandrake 8 is just RedHat 7 with some minor variations.
>
> >  All I can tell you is that some folks
> > have had success downgrading Mesa.  I think one person had a conflict
> > between the xfree4 mesa libs and the "official" mesa libs.  i haven't
> > experienced this problem, myself.
>
> You do have to be VERY careful about removing the old OpenGL libs and
> headers - having both on the disk at the same time is disasterous.
>
> > The easiest way to test this is to use a plib example (from the
> > sources).  Once the plib examples work, FlightGear will work.  I will
> > try to add a FAQ entry for this (even though I don't know the solution
> > to the problem).
>
> Good plan.
>
> > You may also want to join the plib-users@ list to get some help with
> > plib internals.  I'm baffled at why Quake3 and Rune will work, but plib
> > apps won't.  :-/
>
> I'll paste in my reply from last night since you evidently missed it:
>
> Steve Baker wrote:
> > Cameron Moore wrote:
> > > Why do non-plib apps like Quake3, Rune, and gltron work while plib ones
> > > do not?  I mean, how can these non-plibs apps render without a valid
> > > context?  If they can't, how are they getting a valid context when plib
> > > isn't?  Or if it's possible to render without a valid context, why do
> > > we care if one exists (playing devil's advocate)?
> >
> > In OpenGL you are NOT ALLOWED TO MAKE ANY OPENGL CALLS WITHOUT A VALID
> > RENDERING CONTEXT.
> >
> > It's a rule - and that's that.
> >
> > Now, IIRC, in one broken Mesa version, the query function that checks
> > whether there is a valid OpenGL context or not is BROKEN...it says
> > "no valid context" even when there is one.  That's a bug in that version
> > of Mesa - and it needs to be fixed.
> >
> > So, if your application doesn't CHECK for a valid context - but happens
> > to have one anyway, it'll work just fine - even on the broken version of
> > Mesa.  However, if such an application were ever to fail to get a valid
> > context, it would crash mysteriously and without a good error message.
> >
> > HOWEVER, there is another class of "bugs" in OpenGL implementations that
> > you have to watch for.  Some of them tolerate you making *some* OpenGL
> > calls
> > before the rendering context has been created.  That's not exactly a bug
> > because correctly working OpenGL applications don't do that - and broken
> > OpenGL applications are just broken anyway.
> >
> > So, in the light of all that, you might ask why PLIB goes and checks that
> > the rendering context is valid.  Well, before we added that, people would
> > do all sorts of illegal things like loading texture maps before they'd
> > opened up an OpenGL window (a rendering context).  In particular they'd
> > try to call ssgInit() before they had a valid rendering context.  That
> > was a VERY BAD THING because the 'permissive' OpenGL implementations
> > would allow this and those programs would seem to work perfectly on the
> > authors computer - and then crash mysteriously on other people's machines
> > because they had OpenGL implementations that couldn't tolerate the error.
> >
> > This made life VERY difficult.  You'd write a program at home, test it
> > to death on your machine, post it to the internet and get stacks of
> > complaints from people who would claim that it crashed without an error
> > message.
> >
> > So, as a service to mankind, ssgInit (and puInit and IIRC, fntInit) all
> > check that there is a valid rendering context - and if there isn't
> > they'll complain and refuse to continue.  That means that even if your
> > OpenGL implementation is a 'tolerant' one, you'll find the error in your
> > program and fix it so that other people will be able to run it too.
> >
> > I think that's "A Good Thing" - and since we've added it, the number of
> > mysterious crashes inside PLIB on startup have been reduced *GREATLY*
> > because people now get a good error message instead.
> >
> > Now, along comes an OpenGL implementation with a bug in it...what should
> > I do?
> >
> > My decision:   Tell people to FIX THE BUG!!
> >
> > I'm not about to remove a valuable bug-tracer that's proved useful
> > (especially to PrettyPoly which has a very hard time with keeping the
> > startup sequence right and maintaining a valid OpenGL rendering context
> > at all times).
> >
> > CONCLUSION:
> >
> > PLIB is not in error here...it works very well on other versions of Mesa
> > and on non-Mesa OpenGL implementations.
> >
> > So - I make no apologies - please bitch and whine to the Mesa team (only
> > be gentle with Brian Paul - he's not getting paid to maintain Mesa
> > anymore
> >
> > :-(  ...so we have to be nice to him if we want to get things fixed! :-)
> >
> > FOOTNOTE:
> >
> > If you are *desperate*, look for 'glXGetCurrentContext' in
> > src/ssg/ssg.cxx, src/fnt/fntTXF.cxx and src/pui/pu.cxx and make the
> > necessary *HACK* - but please don't distribute that hack to all and
> > sundry because it'll make our lives hell again.  If it were me, I'd go to
> > an earlier or later version of Mesa - who knows what else is broken as a
> > consequence of this?
>
> ----------------------------- Steve Baker -------------------------------
> HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
> HomePage : http://web2.airmail.net/sjbaker1
> Projects : http://plib.sf.net       http://tuxaqfh.sf.net
>            http://prettypoly.sf.net http://tuxkart.sf.net
>            http://freeglut.sf.net   http://toobular.sf.net
>
>
>
> _______________________________________________
> plib-users mailing list
> pli...@li...
> http://lists.sourceforge.net/lists/listinfo/plib-users

Re: [Plib-users] Fwd: Re: flightgear problem

[Steve B. <sjb...@ai...>]

Cameron Moore wrote:
>
> > > : I run mandrake8, heavily customized. kernel 2.4.8enterprise (mandrake
> > > : package update), bleeding edge version of XFree4.1 and Mesa-3.4.2-3 &
> > > : plib-1.4.2-1 (else I wouldn't have been able to compile I believe? ;)..
> >
> > Mandrake 8 and RedHat 7.xx are both based on the same crappy C/C++ compiler
> > version. It wouldn't at all suprise me if that ended up being the problem
> > that's showing up in Mesa.  I've not heard a single problem report from
> > users of other distro's.
> >
> > > All reports we've had before now where specific to RedHat, but you are
> > > using Mandrake...interesting.
> >
> > Mandrake have always taken the RedHat distribution as their starting point.
> >
> > In a sense, Mandrake 8 is just RedHat 7 with some minor variations.
> 
> Actually, Pieter sent more info[1] the flightgear-users list saying:
> 
>   "To get my direct rendering to work, I installed redhat packages on
>   my mandrake system ..."
> 
> Aha!!  That's actually good news.  Mandrake is not broken as it first
> seemed from Pieter's report.  :-)

Well - I wouldn't be *too* hopeful about that.  Amongst the many dumb
things RedHat did in 7.x, I think pretty much all of them were promptly
mimiced by Mandrake in their 8.x release.

Certainly the horribly wrong 2.96/2.97 compiler "releases" that RedHat
distributed have been seen in Mandrake 8.

> And to set the record straight, Mandrake does *not* start with Red Hat
> packages.  It did in it's infancy, but hasn't done so since the Mdk 5.x
> releases, IIRC.  They do their own packages from scratch now.

Well, I don't know about that - but they seem to have made all the same
stoopid decisions.  I don't know whether that's good or not!
 
----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net       http://tuxaqfh.sf.net
           http://prettypoly.sf.net http://tuxkart.sf.net
           http://freeglut.sf.net   http://toobular.sf.net

Re: [Plib-users] Fwd: Re: flightgear problem

[Cameron M. <li...@to...>]

* sjb...@ai... [2001.08.24 10:14]:
> pieter bonne wrote:
> > : >> FATAL: ssgInit called without a valid OpenGL context. <<
> > 
> > This is really a plib problem that affects FlightGear.  Plib always
> > checks for a valid GL context before it begins rendering, and it's
> > obviously failing.  We haven't quite figured out what's causing this.
> 
> PLIB is absolutely entitled to check that the OpenGL rendering context
> is valid before starting rendering.

I understand that and didn't mean to make it sound like plib was broken.
Poor choice of wording...

> > : I run mandrake8, heavily customized. kernel 2.4.8enterprise (mandrake
> > : package update), bleeding edge version of XFree4.1 and Mesa-3.4.2-3 &
> > : plib-1.4.2-1 (else I wouldn't have been able to compile I believe? ;)..
> 
> Mandrake 8 and RedHat 7.xx are both based on the same crappy C/C++ compiler
> version. It wouldn't at all suprise me if that ended up being the problem
> that's showing up in Mesa.  I've not heard a single problem report from
> users of other distro's.
> 
> > All reports we've had before now where specific to RedHat, but you are
> > using Mandrake...interesting.
> 
> Mandrake have always taken the RedHat distribution as their starting point.
> 
> In a sense, Mandrake 8 is just RedHat 7 with some minor variations.

Actually, Pieter sent more info[1] the flightgear-users list saying:

  "To get my direct rendering to work, I installed redhat packages on
  my mandrake system ..."

Aha!!  That's actually good news.  Mandrake is not broken as it first
seemed from Pieter's report.  :-)

And to set the record straight, Mandrake does *not* start with Red Hat
packages.  It did in it's infancy, but hasn't done so since the Mdk 5.x
releases, IIRC.  They do their own packages from scratch now.

[1] http://www.geocrawler.com/lists/3/SourceForge/11854/0/6468891/
-- 
Cameron Moore

Re: [Plib-users] Fwd: Re: flightgear problem

[Steve B. <sjb...@ai...>]

pieter bonne wrote:

> behold, a problem propably related to plib..
> in addition: FlightGear _does_ work when I downgrade mesa, but I lose 3d
> acceleration by doing this.. is there a problem with plib and mesa?

You shouldn't lose 3D accelleration when you downgrade Mesa - that just
means that you didn't install the downgraded version correctly.

I explained at some length what this problem is about last night - the
conclusion:

  * This is a Mesa problem - not a PLIB problem.
    You have shown that by the fact that a downgraded
    Mesa works OK with FGFS/PLIB.

> : >> FATAL: ssgInit called without a valid OpenGL context. <<
> 
> This is really a plib problem that affects FlightGear.  Plib always
> checks for a valid GL context before it begins rendering, and it's
> obviously failing.  We haven't quite figured out what's causing this.

PLIB is absolutely entitled to check that the OpenGL rendering context
is valid before starting rendering.
 
> : I run mandrake8, heavily customized. kernel 2.4.8enterprise (mandrake
> : package update), bleeding edge version of XFree4.1 and Mesa-3.4.2-3 &
> : plib-1.4.2-1 (else I wouldn't have been able to compile I believe? ;)..

Mandrake 8 and RedHat 7.xx are both based on the same crappy C/C++ compiler
version. It wouldn't at all suprise me if that ended up being the problem
that's showing up in Mesa.  I've not heard a single problem report from
users of other distro's.

> : One interresting sidenote is that Quake3, Rune, Heretic (1 and 2), gltron
> : and other opengl accelerated programs (like xmms visualisations ie) all
> : work with this configuration!! Could you help me out here?

Those probably don't check for a valid context - they just go ahead and render
anyway.

> All reports we've had before now where specific to RedHat, but you are
> using Mandrake...interesting.

Mandrake have always taken the RedHat distribution as their starting point.

In a sense, Mandrake 8 is just RedHat 7 with some minor variations.

>  All I can tell you is that some folks
> have had success downgrading Mesa.  I think one person had a conflict
> between the xfree4 mesa libs and the "official" mesa libs.  i haven't
> experienced this problem, myself.

You do have to be VERY careful about removing the old OpenGL libs and
headers - having both on the disk at the same time is disasterous.
 
> The easiest way to test this is to use a plib example (from the
> sources).  Once the plib examples work, FlightGear will work.  I will
> try to add a FAQ entry for this (even though I don't know the solution
> to the problem).

Good plan.
 
> You may also want to join the plib-users@ list to get some help with
> plib internals.  I'm baffled at why Quake3 and Rune will work, but plib
> apps won't.  :-/

I'll paste in my reply from last night since you evidently missed it:

Steve Baker wrote:

> Cameron Moore wrote:
> 
> > Why do non-plib apps like Quake3, Rune, and gltron work while plib ones
> > do not?  I mean, how can these non-plibs apps render without a valid
> > context?  If they can't, how are they getting a valid context when plib
> > isn't?  Or if it's possible to render without a valid context, why do we
> > care if one exists (playing devil's advocate)?
> 
> In OpenGL you are NOT ALLOWED TO MAKE ANY OPENGL CALLS WITHOUT A VALID
> RENDERING CONTEXT.
> 
> It's a rule - and that's that.
> 
> Now, IIRC, in one broken Mesa version, the query function that checks
> whether there is a valid OpenGL context or not is BROKEN...it says
> "no valid context" even when there is one.  That's a bug in that version
> of Mesa - and it needs to be fixed.
> 
> So, if your application doesn't CHECK for a valid context - but happens
> to have one anyway, it'll work just fine - even on the broken version of
> Mesa.  However, if such an application were ever to fail to get a valid
> context, it would crash mysteriously and without a good error message.
> 
> HOWEVER, there is another class of "bugs" in OpenGL implementations that
> you have to watch for.  Some of them tolerate you making *some* OpenGL
> calls
> before the rendering context has been created.  That's not exactly a bug
> because correctly working OpenGL applications don't do that - and broken
> OpenGL applications are just broken anyway.
> 
> So, in the light of all that, you might ask why PLIB goes and checks that
> the rendering context is valid.  Well, before we added that, people would
> do all sorts of illegal things like loading texture maps before they'd
> opened up an OpenGL window (a rendering context).  In particular they'd
> try to call ssgInit() before they had a valid rendering context.  That
> was a VERY BAD THING because the 'permissive' OpenGL implementations
> would allow this and those programs would seem to work perfectly on the
> authors computer - and then crash mysteriously on other people's machines
> because they had OpenGL implementations that couldn't tolerate the error.
> 
> This made life VERY difficult.  You'd write a program at home, test it
> to death on your machine, post it to the internet and get stacks of
> complaints from people who would claim that it crashed without an error
> message.
> 
> So, as a service to mankind, ssgInit (and puInit and IIRC, fntInit) all
> check that there is a valid rendering context - and if there isn't they'll
> complain and refuse to continue.  That means that even if your OpenGL
> implementation is a 'tolerant' one, you'll find the error in your program
> and fix it so that other people will be able to run it too.
> 
> I think that's "A Good Thing" - and since we've added it, the number of
> mysterious crashes inside PLIB on startup have been reduced *GREATLY*
> because people now get a good error message instead.
> 
> Now, along comes an OpenGL implementation with a bug in it...what should
> I do?
> 
> My decision:   Tell people to FIX THE BUG!!
> 
> I'm not about to remove a valuable bug-tracer that's proved useful (especially
> to PrettyPoly which has a very hard time with keeping the startup sequence
> right and maintaining a valid OpenGL rendering context at all times).
> 
> CONCLUSION:
> 
> PLIB is not in error here...it works very well on other versions of Mesa and
> on non-Mesa OpenGL implementations.
> 
> So - I make no apologies - please bitch and whine to the Mesa team (only
> be gentle with Brian Paul - he's not getting paid to maintain Mesa anymore
> :-(  ...so we have to be nice to him if we want to get things fixed! :-)
> 
> FOOTNOTE:
> 
> If you are *desperate*, look for 'glXGetCurrentContext' in src/ssg/ssg.cxx,
> src/fnt/fntTXF.cxx and src/pui/pu.cxx and make the necessary *HACK* - but
> please don't distribute that hack to all and sundry because it'll make our
> lives hell again.  If it were me, I'd go to an earlier or later version of
> Mesa - who knows what else is broken as a consequence of this?
> 

----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net       http://tuxaqfh.sf.net
           http://prettypoly.sf.net http://tuxkart.sf.net
           http://freeglut.sf.net   http://toobular.sf.net

[Plib-users] Fwd: Re: flightgear problem

[pieter b. <xa...@gm...>]

greetings,

behold, a problem propably related to plib..
in addition: FlightGear _does_ work when I downgrade mesa, but I lose 3d
acceleration by doing this.. is there a problem with plib and mesa?

kind regards,
xas

----------  Forwarded Message  ----------

Subject: Re: flightgear problem
Date: Thu, 23 Aug 2001 12:13:13 -0500
From: Cameron <ca...@un...>
To: pieter bonne <xa...@gm...>
Cc: fli...@li...

* xa...@gm... [2001.08.23 04:52]:
: Hello there!

Hello.  I'm Cc'ing this to the flightgear-users@ list.

: I get a rather mysterious startup-error with both hand-compiled and
: pre-compiled(mkd) versions of FlightGear 0.7.8 :
:
: bash-2.04$ fgfs
: FlightGear:  Version 0.7.8
:
: Scanning for root: command line
: fg_root = /usr/local/lib/FlightGear
: Reading global preferences
: Reading properties from /usr/local/lib/FlightGear/preferences.xml
: Base is /usr/local/lib/FlightGear/preferences.xml
: Dir is /usr/local/lib/FlightGear
: Reading properties from /usr/local/lib/FlightGear/keyboard.xml
: Base is /usr/local/lib/FlightGear/preferences.xml
: Dir is /usr/local/lib/FlightGear
: Reading properties from /usr/local/lib/FlightGear/joysticks.xml
: Finished Reading global preferences
: Processing command line arguments
: Opening a window: 800x600
: Mesa DRI VoodooBanshee 20010501 x86/MMX
: Max texture size = 256
: Depth buffer bits = 16
:
: >> FATAL: ssgInit called without a valid OpenGL context. <<

This is really a plib problem that affects FlightGear.  Plib always
checks for a valid GL context before it begins rendering, and it's
obviously failing.  We haven't quite figured out what's causing this.

: I run mandrake8, heavily customized. kernel 2.4.8enterprise (mandrake
: package update), bleeding edge version of XFree4.1 and Mesa-3.4.2-3 &
: plib-1.4.2-1 (else I wouldn't have been able to compile I believe? ;)..
: One interresting sidenote is that Quake3, Rune, Heretic (1 and 2), gltron
: and other opengl accelerated programs (like xmms visualisations ie) all
: work with this configuration!! Could you help me out here?
:
: Thanks on forehand..
: -xas- (aka Pieter Bonne)

All reports we've had before now where specific to RedHat, but you are
using Mandrake...interesting.  All I can tell you is that some folks
have had success downgrading Mesa.  I think one person had a conflict
between the xfree4 mesa libs and the "official" mesa libs.  i haven't
experienced this problem, myself.

The easiest way to test this is to use a plib example (from the
sources).  Once the plib examples work, FlightGear will work.  I will
try to add a FAQ entry for this (even though I don't know the solution
to the problem).

You may also want to join the plib-users@ list to get some help with
plib internals.  I'm baffled at why Quake3 and Rune will work, but plib
apps won't.  :-/
--
cameron
[ Why are there interstate highways in Hawaii? ]

-------------------------------------------------------

--
"...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and
the Ugly)."
(By Matt Welsh)

Re: [Plib-users] GL context fecal matter

[Steve B. <sjb...@ai...>]

Cameron Moore wrote:

> Why do non-plib apps like Quake3, Rune, and gltron work while plib ones
> do not?  I mean, how can these non-plibs apps render without a valid
> context?  If they can't, how are they getting a valid context when plib
> isn't?  Or if it's possible to render without a valid context, why do we
> care if one exists (playing devil's advocate)?

In OpenGL you are NOT ALLOWED TO MAKE ANY OPENGL CALLS WITHOUT A VALID
RENDERING CONTEXT.

It's a rule - and that's that.

Now, IIRC, in one broken Mesa version, the query function that checks
whether there is a valid OpenGL context or not is BROKEN...it says
"no valid context" even when there is one.  That's a bug in that version
of Mesa - and it needs to be fixed.

So, if your application doesn't CHECK for a valid context - but happens
to have one anyway, it'll work just fine - even on the broken version of
Mesa.  However, if such an application were ever to fail to get a valid
context, it would crash mysteriously and without a good error message.

HOWEVER, there is another class of "bugs" in OpenGL implementations that
you have to watch for.  Some of them tolerate you making *some* OpenGL
calls
before the rendering context has been created.  That's not exactly a bug
because correctly working OpenGL applications don't do that - and broken
OpenGL applications are just broken anyway.

So, in the light of all that, you might ask why PLIB goes and checks that
the rendering context is valid.  Well, before we added that, people would
do all sorts of illegal things like loading texture maps before they'd
opened up an OpenGL window (a rendering context).  In particular they'd
try to call ssgInit() before they had a valid rendering context.  That
was a VERY BAD THING because the 'permissive' OpenGL implementations
would allow this and those programs would seem to work perfectly on the
authors computer - and then crash mysteriously on other people's machines
because they had OpenGL implementations that couldn't tolerate the error.

This made life VERY difficult.  You'd write a program at home, test it
to death on your machine, post it to the internet and get stacks of
complaints from people who would claim that it crashed without an error
message.

So, as a service to mankind, ssgInit (and puInit and IIRC, fntInit) all
check that there is a valid rendering context - and if there isn't they'll
complain and refuse to continue.  That means that even if your OpenGL
implementation is a 'tolerant' one, you'll find the error in your program
and fix it so that other people will be able to run it too.

I think that's "A Good Thing" - and since we've added it, the number of
mysterious crashes inside PLIB on startup have been reduced *GREATLY*
because people now get a good error message instead.

Now, along comes an OpenGL implementation with a bug in it...what should
I do?

My decision:   Tell people to FIX THE BUG!!

I'm not about to remove a valuable bug-tracer that's proved useful (especially
to PrettyPoly which has a very hard time with keeping the startup sequence
right and maintaining a valid OpenGL rendering context at all times).

CONCLUSION:

PLIB is not in error here...it works very well on other versions of Mesa and
on non-Mesa OpenGL implementations.

So - I make no apologies - please bitch and whine to the Mesa team (only
be gentle with Brian Paul - he's not getting paid to maintain Mesa anymore
:-(  ...so we have to be nice to him if we want to get things fixed! :-)

FOOTNOTE:

If you are *desperate*, look for 'glXGetCurrentContext' in src/ssg/ssg.cxx,
src/fnt/fntTXF.cxx and src/pui/pu.cxx and make the necessary *HACK* - but
please don't distribute that hack to all and sundry because it'll make our
lives hell again.  If it were me, I'd go to an earlier or later version of
Mesa - who knows what else is broken as a consequence of this?

----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net       http://tuxaqfh.sf.net
           http://prettypoly.sf.net http://tuxkart.sf.net
           http://freeglut.sf.net   http://toobular.sf.net

[Plib-users] GL context fecal matter

[Cameron M. <li...@to...>]

Hello all,
I had a FlightGear user email me yesterday having the same old "can't
find a valid GL context" error message.  The email is available in the
archives[1] if you want more details.  I don't understand the internals
of this works and wanted to get an explanation from those of you who
do.  Here goes...

Why do non-plib apps like Quake3, Rune, and gltron work while plib ones
do not?  I mean, how can these non-plibs apps render without a valid
context?  If they can't, how are they getting a valid context when plib
isn't?  Or if it's possible to render without a valid context, why do we
care if one exists (playing devil's advocate)?

[1] http://www.geocrawler.com/lists/3/SourceForge/11854/0/6466433/
-- 
Cameron Moore

[Plib-users] Missing plib-users archives.

[Steve B. <sjb...@ai...>]

I just got this back from the SourceForge bug tracker in response
to this recent business of phplib-users and plib-users being all
messed up in the GeoCrawler mail list archives:

> Date: 2001-08-21 18:18
> Sender: moorman
> Logged In: YES 
> user_id=152443
> 
> Greetings,
> 
> This issue is currently under the review of the
> SourceForge.net site director.  The SourceForge.net team is
> currently in the process of evaluating the current status of
> Geocrawler and reviewing pending issues with the Geocrawler
> site.  Additional information will be posted to this support
> request once it becomes available.
>
> Thank you,
> 
> Jacob Moorman
> Quality of Service Manager, SourceForge

Not much help or comfort I'm afraid.

   :-(

----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net       http://tuxaqfh.sf.net
           http://prettypoly.sf.net http://tuxkart.sf.net
           http://freeglut.sf.net   http://toobular.sf.net

Re: [Plib-users] ANNOUNCING: PLIB 1.5.1, PLIB Demos.

[Dave M. <dp...@ef...>]

looks like this is the function you want...

void slScheduler::setMaxConcurrent ( int mc )

-- dave

----- Original Message -----
From: Michael Wessels
To: pli...@li...
Sent: Saturday, August 11, 2001 9:52 AM
Subject: Re: [Plib-users] ANNOUNCING: PLIB 1.5.1, PLIB Demos.


Hi Steve,

you wrote:
  * Added support for >3 simultaneous sounds in SL.
    (You have to explicitly enable that though - it's not
    the default)


Where in SL I can enable this feature ? I have not found information in the
docu.
Michael

Re: [Plib-users] ANNOUNCING: PLIB 1.5.1, PLIB Demos.

[Michael W. <michael.wessels@z.zgs.de>]

Hi Steve,


you wrote:

>   * Added support for >3 simultaneous sounds in SL.
>     (You have to explicitly enable that though - it's not
>     the default)
>
>

Where in SL I can enable this feature ? I have not found information in the docu.

Michael

Re: [Plib-users] sgCompareVec* documented incorrectly?

[Steve B. <sjb...@ai...>]

Arnt Karlsen wrote:
> 
> On Thu, 09 Aug 2001 11:45:27 -0500, Steve Baker <sjb...@ai...>
> wrote in <3B7...@ai...>:
> 
> >
> > We knew about this error already - but didn't want to just change
> > sgCompareVecN in PLIB 1.4.x because we were not sure whether any
> > packages relied upon the broken behavior...then we just forgot to
 
> ..do these include SimGear and FlightGear?

I doubt it.

> ..for SimGear and FlightGear, should we use plib 1.4.x
> or 1.5.x ?

We use the Linux kernel team's convention of using an even
number in the second digit of the version number to indicate
a "stable" release with an odd number indicating a 'beta' test
version.

So I'd hope that *developers* of FlightGear would regularly
test against PLIB 1.5.x so that they don't get any nasty suprises
when 1.6.x appears.

End users of FGFS should use 1.4.x since they are only interested
in something that works well right *NOW* and PLIB 1.5.x could well
have bugs, be hard to install or be incompatible with the latest
FGFS...that's why its 'in beta'.

----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net       http://tuxaqfh.sf.net
           http://prettypoly.sf.net http://tuxkart.sf.net
           http://freeglut.sf.net   http://toobular.sf.net

Re: [Plib-users] sgCompareVec* documented incorrectly?

[Arnt K. <ar...@c2...>]

On Thu, 09 Aug 2001 11:45:27 -0500, Steve Baker <sjb...@ai...>
wrote in <3B7...@ai...>:

> 
> We knew about this error already - but didn't want to just change
> sgCompareVecN in PLIB 1.4.x because we were not sure whether any
> packages relied upon the broken behavior...then we just forgot to

..do these include SimGear and FlightGear?

> fix it!
> 
> It'll be fixed in the next 1.5.x release - and it's fixed in CVS

..1.5.2?  Due when?

> right now.
> 
> Sorry!

..for SimGear and FlightGear, should we use plib 1.4.x 
or 1.5.x ?

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)

  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

Re: [Plib-users] sgCompareVec* documented incorrectly?

[Steve B. <sjb...@ai...>]

lo...@sl... wrote:
> 
> Unless I'm misunderstanding C++/PLIB it appears that the sgCompareVec*
> functions are documented incorrectly.
> 
> http://plib.sourceforge.net/sg/index.html
> 
> says that sgCompareVec* returns TRUE if the vectors being compared are
> equal.  But sg.h sure looks like it is returning -1 or 1 if the vectors
> are not "equal".  Unless TRUE == 0 in C++/PLIB the documentation appears
> incorrect.

Yes - you are correct, there is a code error (the documentation is OK).

Please use sgEqualVecN to test for exact equality - or if you need a
tolerance for slight inequality, do:

  if ( sgDistanceSquaredVecN ( ... ) < tol*tol )

...which does the right thing.

We knew about this error already - but didn't want to just change
sgCompareVecN in PLIB 1.4.x because we were not sure whether any
packages relied upon the broken behavior...then we just forgot to
fix it!

It'll be fixed in the next 1.5.x release - and it's fixed in CVS
right now.

Sorry!

----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net       http://tuxaqfh.sf.net
           http://prettypoly.sf.net http://tuxkart.sf.net
           http://freeglut.sf.net   http://toobular.sf.net

[Plib-users] Re: sgCompareVec* documented incorrectly?

[<lo...@sl...>]

On Wed, 8 Aug 2001 pli...@li... wrote:

>
> Today's Topics:
>
>    1. sgCompareVec* documented incorrectly? (lo...@sl...)
>    2. Re: sgCompareVec* documented incorrectly? (Wolfram Kuss)

>
> <lo...@sl...> wrote:
>
> >Please correct me if I'm wrong...
>
> You are right. There was already some discussion about this, starting
> at:
> http://www.geocrawler.com/archives/3/1868/2001/5/200/5737189/
> IMHO, we should create a new function and deprecate (sp?) the old one.
> Unfortunately, some of us are just now quite busy with PPE ...

Somewhat off-topic but the geocrawler search engine apparently sucks.  If
you search for sgCompareVec or sgCompareVec2 you get no results.  Yet
sgCompareVec2 is clearly in the message you pointed me to...

Something for everyone to remember when looking for old PLIB messages.

Jeff Long

Re: [Plib-users] sgCompareVec* documented incorrectly?

[Wolfram K. <w_...@rz...>]

<lo...@sl...> wrote:

>Please correct me if I'm wrong...

You are right. There was already some discussion about this, starting
at:
http://www.geocrawler.com/archives/3/1868/2001/5/200/5737189/
IMHO, we should create a new function and deprecate (sp?) the old one.
Unfortunately, some of us are just now quite busy with PPE ...

>Jeff Long

Bye bye,
Wolfram.

[Plib-users] sgCompareVec* documented incorrectly?

[<lo...@sl...>]

Unless I'm misunderstanding C++/PLIB it appears that the sgCompareVec*
functions are documented incorrectly.

http://plib.sourceforge.net/sg/index.html

says that sgCompareVec* returns TRUE if the vectors being compared are
equal.  But sg.h sure looks like it is returning -1 or 1 if the vectors
are not "equal".  Unless TRUE == 0 in C++/PLIB the documentation appears
incorrect.

Please correct me if I'm wrong...

Jeff Long

PGP public key at http://www.slothmud.org/~long/long.gpg

RE: [Plib-users] Error compiling plib-1.4.2

[<ea...@un...>]

N Vine writes:

> >ea...@un... writes:
> 
> >I've just tried compiling plib-1.4.2 using Cygwin (1.1.7) and got the 
> >following error:
> 
> >Can anyone give me any idea what to do about it in order to get 
> >plib compiled ?
> 
> uninstall your version of Cygwin
> 
> goto http://www.cygwin.com
> click on "install cygwin now"
> 

Thanks, thats sorted it.

Cheers - Dave

--
David Luff
Engines Research Group
University of Nottingham
0115-9513814
dav...@no...

RE: [Plib-users] Error compiling plib-1.4.2

[Norman V. <nh...@ca...>]

>ea...@un... writes:

>I've just tried compiling plib-1.4.2 using Cygwin (1.1.7) and got the 
>following error:

>Can anyone give me any idea what to do about it in order to get 
>plib compiled ?

uninstall your version of Cygwin

goto http://www.cygwin.com
click on "install cygwin now"

Cheers

Norman

[Plib-users] Error compiling plib-1.4.2

[<ea...@un...>]

Hi all,

I've just tried compiling plib-1.4.2 using Cygwin (1.1.7) and got the 
following error:

netSocket.cxx: In method 'int netSocket::bind(const cchar *, int)':
netSocket.cxx:202: passing 'const sockaddr *' as argument 2 of 
'bind(int, sockaddr *, int)' discards qualifiers

Can anyone give me any idea what to do about it in order to get 
plib compiled ?

Thanks - Dave

--
David Luff
Engines Research Group
University of Nottingham
0115-9513814
dav...@no...

[Plib-users] Re: [Flightgear-users] ..ran '/usr/local/bin/gl-info'...

[Arnt K. <ar...@c2...>]

.Jacek, Cameroon and Curt, it appears I have a mean 
combination of poorly supported video card and Red Hat 
Linux 7.1.  According to ATI, mach64 is not on ATI's 
"todo list", not even for wintendo.  Xfree86.org and 
the DRI-people are looking for people who can do mach64 
acceleration.  

""Øyvind Hagen\" \"" wrote in norwegian, and I translated:
> 
> In article <3B6...@c2...>, "Arnt Karlsen" <ar...@c2...>
> wrote:
> > ..how much texture memory do you feel a flightsim needs, 
> > out of my 8 MB vram, as a starting point?

..here I'd like input on FlightGear requirements

> Like I said, this is hard to know in advance.  Some programs
> (like gears) use none, while other programs use more than 40 MiB.
> Most OpenGL programmer usually do reasonable texture handling, 
> only keeping the neccesary textures in the video card memory.
> However, some drivers fail here.
>
> Texture compression is also nice when you're low on vram,
> but I dont see ATI Rage supporting this.(couldnt see any 
> such extention mentioned when you ran glinfo.)
> 
> Remember that you will be able to play the game even if you 
> dont have enough vram to hold the textures.  You only get 
> lower performance as textures are fed from AGP/system memory.
> 
> > Øyvind Hagen wrote in norwegian, and I translated:
> >> Consequently you cannot run ATI Rage at 1600x1200x16bpp with
> >> HW-accelleration. 3 x 1600 x 1200 x (16bpp/8) = 11250KiB > 8MiB
> >>                                       ^ stencil- & Z-buffer + 2
> >>                                       color buffer
> >
> > ..the "2" became a "3". What is it?
> 
> I forgot Z- & stencil buffers in my last calculation.
> 
> > ..3x800x600x(16/8)=2.75 MB + texture memory on top of that?
> 
> Yup, this is what you should go for. Run 800x600x16 on your other X
> server.
> 
> > ..a 50/50 split between texture and everything else -> 964x724.
> >
> > ..another possibility is 1280X1024, which needs 7.5 MB vram and gives 512 kB
> > texture memory?
> 
> Believe me, far below what you need...
> 
> > ..anyone else who know/have heard/believes/feels anything about 
> > other buffers than those Øyvind has mentioned, which are suppprted 
> > by ATI Rage IIC agp 8MB???
> 
> ATI Rage, afaik, supports _only_ front & back buffer, Z-buffer &
> stencilbuffer.
> 
> Other nice handy buffers include accumulations buffer, pbuffer, multi
> color buffers. Then fun extras include extra set of font & back buffers
> which can be used for stereoscopic effects (3D with LCD glasses) or
> regular red/blue 3D glasses. All these buffers are supported by the 
> more mature cards.
> 
> Remember, we only speak of _hardware_ buffers. Some of these buffers 
> available for ATI Rage, but only in SW( which defeats the whole point.)
>
> 
> > ..X v4.x.x appears to make its own modelines on the fly.
> > How do I overrule the modeline generator in X v4.1.0?
> 
> No idea.
> 

..to fill in the good people of the FlightGear, plib 
user mailing lists and news:no.it.os.unix.linux.diverse:

..os: Red Hat 7.1 with all known erratas to date,
I run XFree86-4.1.0-0.9.1 from rawhide at 
1600x1200x24bpp@60Hz on a 8MB ATI Rage IIC agp card, 
screen is an half burned Sony GDM-2038 that needs a
custom modeline to "yaw" it back in, from 1/3 out.

..this "yaw" trick is needed for _all_ modelines.

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)

  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

Re: [Plib-users] Re: [Flightgear-users] ..ran '/usr/local/bin/gl-info'...

[Steve B. <sjb...@ai...>]

Arnt Karlsen wrote:

> [arnt@Lena demos]$ gears
> 118 frames in  5.013 seconds = 23.539 FPS

> [arnt@Lena demos]$ glinfo

> GL_RENDERER: Mesa GLX Indirect
               ^^^^^^^^^^^^^^^^^
               Not good!  You don't seem
              to have hardware accelleration.

This accounts for the distinctly S-L-O-W frame rates you are
getting out of the simplest OpenGL program on the planet.

> direct rendering: No
                    ^^
                 Also not good.
                 Indirect Rendering == S-L-O-W

> ..firm diagnosis, I guess.  How should I fix it?

Remove **ALL** traces of OpenGL and Mesa from your machine.

   find / -name lib\*GL.\* -print

...Erase the lot...*NO* mercy.

Re-install Mesa from the Mesa web site...from the sources...not
some possibly dubious RedHat version. (Remember what these guys
distributed as a C compiler?  Do you trust them to get you
a good version of the Mesa library?)

Maybe wipe out Xfree86 and re-install that.

We could go back and forth trying to find out exactly what
got screwed up - BUT THIS IS THE WRONG MAILING LIST FOR
OPENGL
PROBLEM DIAGNOSIS.

It's screwed up - it's not PLIB's problem (we already knew that
actually) - we don't fix that stuff here.
 
> ..I have "FATAL: puInit called without a valid OpenGL context"

I still don't understand this message - you clearly *DO* have OpenGL,
but it may be that it's failing because we are demanding a DIRECT
rendering context and you have some weird indirect one.  You aren't
going to get any kind of performance with this setup anyway...so it's
got to go.

> on all plib_examples-1.4.1 tests except:

> /usr/local/source/plib_examples-1.4.1/src/sg/sg_quat_test
> /usr/local/source/plib_examples-1.4.1/src/sl/example
> /usr/local/source/plib_examples-1.4.1/src/sl/mod_demo
> /usr/local/source/plib_examples-1.4.1/src/util/test_dir
> ...which works ok,

(None of those use OpenGL)

> /usr/local/source/plib_examples-1.4.1/src/ssg/load_save/save
> which segfaulted and dumped core,

This one does use OpenGL - dunno why it core dumps though...
ooohhh!  It doesn't call ssgInit!!! Naughty!  So instead of
hitting the trap that says it couldn't get an OpenGL context,
it tries to use the (non-existant) OpenGL context and crashes
instead.

I'll fix that bug right now - but that'll only make it produce
the same polite error message that the other SSG programs generate.

> and:
> /usr/local/source/plib_examples-1.4.1/src/ssg/majik/majik_demo
> which :"Majik_Demo: Joystick with at least two axes required.".

True.
 
> ..on Red Hat 7.1,the standard plib setup accepts this without
> warnings. SimGear and FlightGear does not catch this error on
> install,  FG simply dies "without a valid OpenGL context".
> As the "mail-stream" linux distro (count them!), this distro
> should be tested out, before release of sw.

Eh?  Oh - you mean "Main Stream".  Well, RedHat's 7.0 and 7.1 releases
are totally fscked because of their apalling choice of C and C++
compiler.  They *SUCK* right now...and it has always been the case
that "Linux Is Not RedHat".

As to whether we should test with RedHat - well, "we" are a bunch of
individuals who write this software for our own amusement in our
spare time - we have no *OBLIGATION* to test anything on anything.

I wouldn't run RedHat 7.x on one of my machines if you paid me to.
It's a pile of pooh - and I'll stick with SuSE 7.1 thanks!
When RedHat get their act together again, probably one or more
PLIB developers will use it and PLIB will be tested on RedHat
on a regular basis - but I don't have the power to force my
fellow developers to run crappy distro's just to test with.

Actually, RedHat 7.x and PLIB *DO* work together if both are
installed correctly.  You have software only rendering - and
only in INDIRECT mode - even with the simplest of Mesa demo
programs.  Your OpenGL/Mesa is **NOT** correctly installed.

Whether that's your fault or RedHat's fault or a stray
Cosmic Ray that hit your RAM chip at the precise moment
you were installing it...I don't know.

So:

  * Not PLIB's fault - hence end this thread on this
    mailing list please.

  * Mesa **NOT** correctly installed...go fix it.

> ..here, I would like some more verbosity.

The message we emit reflects *ALL* the information we have.

I ask the X server  "Do you have an OpenGL rendering context?"
and it says "No"...so my message is passing on to you
*ALL* the information I have at hand.  There isn't anything
more to say.  Nothing in X or OpenGL can tell my program what
it was that you or RedHat screwed up...it ain't there - and
that's all I know.

> Also installing non-native software in '/usr' as plib do,
> should happen in the distro-native software package format.

As it happens, I had a LONG discussion with the RedHat guy who
is assigned to track PLIB and it was he who asked me to move
PLIB out of /usr/local/plib and into /usr/lib way back in
PLIB 1.0.xx days.  I can't maintain a "distro-native software
package format" because that would require me to have a row
of a dozen computers here at home - one running each Linux
distro that is out there *just* so I could make RPM's and
APT-GET's and SPM's and christ knows what other stuff.

What you PAY for when you buy a copy of RedHat, SuSE, Mandrake
or whatever is the cost to package source packages like PLIB
into RPM's that work together.  I don't regard it as my job
to do that.

I release a source tarball - that's UTTERLY portable and
that one file is enough for Windoze 95/98/2000/NT/ME, every
flavor of Linux, Free/Open/NetBSD, MacOS, OS-X, BeOS, IRIX,
Solaris, etc.

If it's not good enough for you - go write your own graphics
library!  (Heck - that's what I did!)

> ..I have a Chinese 3 axis usb joystick with a "throttle" slider,
> 4 buttons, one throw switch, and a 4-way hat trim switch, and
> 2 rc radio type stick trim potmeters on the bottom.
> 
> ..never used. ;-)  Spoon-feed me, the joystick newbie:
> How do I get this one working?

Well, if the Linux driver supports it, and if you installed it
right - it'll "just work" with PLIB - there is no special
magic.  If the Linux driver doesn't support it, neither will
PLIB.

You can find out whether it's working using the js_demo program
which is in examples/src/js/js_demo

If it's not working - please ask your question on the Linux
joystick mailing list.
    
         lin...@at...

(USB sticks are kinda tricky...but I have one that works at
work on SuSE 7.1 - so it's possible)

> ..to fill in the good people of the plib user mailing list

> 1600x1200x24bpp@60Hz on a 8MB ATI Rage IIC agp card,

Hmmm - is that chip actually supported by Mesa?

If not - that may go some way to explaining your problem?

----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net     http://tuxaqfh.sf.net  http://tuxkart.sf.net
           http://agtoys.sf.net   http://prettypoly.sf.net
           http://freeglut.sf.net http://toobular.sf.net

[Plib-users] Re: [Flightgear-users] ..ran '/usr/local/bin/gl-info'...

[Arnt K. <ar...@c2...>]

On Thu, 02 Aug 2001 12:39:03 +0200, Jacek Marczewski
<mar...@to...> wrote in <3B6...@to...>:

> Arnt Karlsen wrote:
> 
> >>
> >>As a good test of hardware acceleration you can use test programs from Mesa.
> >>Install Mesa-demos packet which you already have and run for example 
> >>'gears' and 'fire' (there are a lot of other tests).
> >>
> >
> >..how?  In '/usr/share/Mesa-demos/src' I have 'books/', 
> >'demos/', and 'xdemos/'.  In all 3 I have 'Makefile*'s 
> >README's and a lot of '*.c' files.  
> >
> I asume you installed Mesa-demos from rpm. In that case just type in as 
> a user  /gears /and run it.

..ROTFLMAO!!!  
 
[arnt@Lena demos]$ gears
118 frames in  5.012 seconds = 23.543 FPS
143 frames in  5.026 seconds = 28.452 FPS
143 frames in  5.020 seconds = 28.486 FPS
142 frames in  5.011 seconds = 28.338 FPS
118 frames in  5.013 seconds = 23.539 FPS

[arnt@Lena demos]$ glinfo
GL_VERSION: 1.2 Mesa 3.4.2
GL_EXTENSIONS: GL_ARB_multitexture GL_EXT_abgr GL_EXT_blend_color
GL_EXT_blend_minmax GL_EXT_blend_subtract
GL_RENDERER: Mesa GLX Indirect
GL_VENDOR: VA Linux Systems, Inc.
GLU_VERSION: 1.1 Mesa 3.4.2
GLU_EXTENSIONS: GL_EXT_abgr
GLUT_API_VERSION: 3
GLUT_XLIB_IMPLEMENTATION: 15

[arnt@Lena xdemos]$ glxinfo
display: :0.0  screen:0
direct rendering: No
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
client glx vendor string: SGI
client glx version string: 1.2
client glx extensions:
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
GLX extensions:
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
OpenGL vendor string: VA Linux Systems, Inc.
OpenGL renderer string: Mesa GLX Indirect
OpenGL version string: 1.2 Mesa 3.4.2
OpenGL extensions:
    GL_ARB_multitexture, GL_EXT_abgr, GL_EXT_blend_color,
    GL_EXT_blend_minmax, GL_EXT_blend_subtract
glu version: 1.1 Mesa 3.4.2
glu extensions:
    GL_EXT_abgr
 
   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------
0x23 24 tc  0 24  0 r  y  .  8  8  8  0  0 16  0  0  0  0  0  0 0 None
0x24 24 tc  0 24  0 r  y  .  8  8  8  0  0 16  8 16 16 16  0  0 0 None
0x25 24 dc  0 24  0 r  y  .  8  8  8  0  0 16  0  0  0  0  0  0 0 None
0x26 24 dc  0 24  0 r  y  .  8  8  8  0  0 16  8 16 16 16  0  0 0 None


..firm diagnosis, I guess.  How should I fix it?

..I have "FATAL: puInit called without a valid OpenGL context"
on all plib_examples-1.4.1 tests except:
/usr/local/source/plib_examples-1.4.1/src/sg/sg_quat_test       
/usr/local/source/plib_examples-1.4.1/src/sl/example
/usr/local/source/plib_examples-1.4.1/src/sl/mod_demo
/usr/local/source/plib_examples-1.4.1/src/util/test_dir 
...which works ok, 
/usr/local/source/plib_examples-1.4.1/src/ssg/load_save/save
which segfaulted and dumped core,
and:
/usr/local/source/plib_examples-1.4.1/src/ssg/majik/majik_demo
which :"Majik_Demo: Joystick with at least two axes required.".

..on Red Hat 7.1,the standard plib setup accepts this without 
warnings. SimGear and FlightGear does not catch this error on 
install,  FG simply dies "without a valid OpenGL context".
As the "mail-stream" linux distro (count them!), this distro
should be tested out, before release of sw.


..here, I would like some more verbosity.
Also installing non-native software in '/usr' as plib do,
should happen in the distro-native software package format.
For Red Hat 7.1, I would like a '.spec' file in the tarball,
so I first can 'rpm --tarbuild' it into a src.rpm, then I'd 
'rpm --rebuild' to build the binary rpm, and then 'rpm -ivh'.
Debian and Slackware people might want to do the same.


..I have a Chinese 3 axis usb joystick with a "throttle" slider, 
4 buttons, one throw switch, and a 4-way hat trim switch, and
2 rc radio type stick trim potmeters on the bottom.  

..never used. ;-)  Spoon-feed me, the joystick newbie: 
How do I get this one working? 


..to fill in the good people of the plib user mailing list 
and news:no.it.os.unix.linux.diverse:
Red Hat 7.1 with all known erratas to date,
I run XFree86-4.1.0-0.9.1 from rawhide at 
1600x1200x24bpp@60Hz on a 8MB ATI Rage IIC agp card, 
screen is an half burned Sony GDM-2038 that needs a
custom modeline to "yaw" it back in, from 1/3 out.
AMD k6-2 450MHz w 128 MB ram, can also set up clusters
made from any combination of AMD k6-2 200MHz w 128MB, 
Intel PII 233 MHz w 96MB, Intel P90 w 96MB and 5 IBM
thinkpad 760ED P120? w 32 MB each, and an Intergraph
6040 as a two screen display node.  WireGL?

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)

  Scenarios always come in sets of three: 
  best case, worst case, and just in case.