[Flightgear-devel] Key Bindings

2004-11-02 Thread Aaron Wilson


I just compiled the latest stable source 0.9.6 and the keyboard commands
were not working.  The only way I could get them to fire the
"binded" command was to set the keys to repeatable (i.e.
true).  Has anyone else had
this problem? 
Thanks,

Aaron I. Wilson
AST: Computer Engineer
TEL:  (304) 367-8299
FAX:  (304) 367-8203
[EMAIL PROTECTED]

http://www.ivv.nasa.gov/



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Multiheaded video cards?

2004-11-02 Thread John Wojnaroski

- Original Message -
From: "Curtis L. Olson" <[EMAIL PROTECTED]>
To: "FlightGear developers discussions" <[EMAIL PROTECTED]>
Sent: Tuesday, November 02, 2004 10:37 AM
Subject: [Flightgear-devel] Multiheaded video cards?


> I periodically get asked about multiheaded video cards for FlightGear.
> My standard answer is that I don't know for sure, but I suspect they
> wouldn't work well for FlightGear.  However, the questions keep coming
> and I feel like I'm not able to give a really good answer.
>
> So can anyone help me out?  For instance, has anyone tried one of these
> sorts of cards?
>
> http://www.matrox.com/mga/products/parhelia/series.cfm
>
> What kind of opengl support is available under linux?

The displays on the 747 sim use GeForce 5200 multiheaded displays. Nvidia
provides an XF86Config file that is just about "plug and play" for driving
two monitors. As near as I can tell the opengl support is just fine, define
the screen size to your taste (like 2048 x 768) and the hardware does the
rest. For my displays that works great for positioning the PFD/ND/EICAS/ etc
onto the flightdeck.
>
>
> Has anyone played around with any of these options who can report
> success or failure or something in between?  What kind of performance
> are you getting?
>
A while back I set up FlightGear on two machines where the master ran one
copy of fgfs and used the network stuff to send data to the second machine
with two distinct socket address that connected to the two slaved versions
of fgfs with the view for the left monitor offset 55 degrees lect and the
right monitor view offset to the right. I did not do any exhaustive testing
or frame rate analysis based on what was being depicted.
As I recall it was a bare KSFO field with most of the options like random
objects, clouds, etc turned off. Can't remember the fps on the main but the
two slaves fgfs's (running on a P4, 2.8Ghz, 512M memory) clocked around
26-30fps.

And did not spend any time trying to analyze the geometry or rendering math
to determine any distortions if you tried to stretch a 55 degree FOV over
two monitors or the increased distortion away from the center if you changed
the value to 110 degrees

Regards
John W.


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Multiheaded video cards?

2004-11-02 Thread Jon Stockill

Jon S Berndt said:
> I recall a couple years ago I was running two 17" monitors off of a
> dual head nVidia GeForce MX400 card. When I ran FlightGear, the window
> took up the entire width (two screens) as if the two monitors were one
> wide screen.

You, confirmed - you get a single virtual screen spread across 2 monitors,
both accelerated. In most cards with dual monitor + tv outputs though the
second monitor output shares a RAMDAC with the tv output, so you can only
use one or the other - there's no chance of using 3 outputs.

-- 
Jon Stockill
[EMAIL PROTECTED]


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Multiheaded video cards?

2004-11-02 Thread Chris Metzler
On Tue, 02 Nov 2004 12:37:40 -0600
"Curtis L. Olson" <[EMAIL PROTECTED]> wrote:
>
> I periodically get asked about multiheaded video cards for FlightGear.  
> My standard answer is that I don't know for sure, but I suspect they 
> wouldn't work well for FlightGear.  However, the questions keep coming 
> and I feel like I'm not able to give a really good answer.
> 
> So can anyone help me out?  For instance, has anyone tried one of these 
> sorts of cards?
> 
> http://www.matrox.com/mga/products/parhelia/series.cfm
> 
> What kind of opengl support is available under linux?

I haven't used these cards.  However, the card I used before the one
I have now was the immediate predecessor to the Parahelia, the Matrox
Millenium G550.  It was equipped for multihead, but I never used it.

What I can tell you, though, is that DRI and OpenGL support for Matrox
cards under Linux sucks rocks.  First of all, Matrox' drivers are open,
and their proprietary HAL module doesn't really buy you anything, so
you'd naively think to be in good shape.  Wrong, though.  As of early
summer, Matrox was not actively maintaining their Linux drivers.  The
G series and Parhelia series forums at forum.matrox.com are filled with
complaints, requests for driver updates, etc., with no real responses.
See this thread:

 http://forum.matrox.com/mga/viewtopic.php?t=10864&highlight=

for just a taste.  There's a lot more there too.  Personally, I had
constant hard lockups requiring a full system reset, with lots of
DMA idle timeout messages to my X log, whenever I tried flightgear
for very long with the Matrox card.  From other messages in the Matrox
forums, and the DRI/X.org/XF86 mailing lists and bugzillas, that
wasn't so unusual.

Well, since their drivers are open, maybe someone else can fix things?
Unfortunately, at least up until late summer (when I gave up on Matrox),
the contributors to the DRI project responsible for working on the Matrox
drivers weren't active, and nobody else was picking it up.  Matrox
bug reports were getting acknowledged but no one was working on them.

Furthermore, Matrox doesn't provide a Linux-compatable OpenGL, so you
have to use the Mesa libs.  That isn't really such a bad thing compared
to the issues above; but if the difference between nVidia's libGL and
the Mesa libGL are indicative, it's another performance hit.

I don't mean to knock Matrox completely.  I think their 2D performance
is absolutely fantastic.  But they're a bad choice for 3D work even under
Windows, so I'm told; while from personal experience, they're awful for
3D under Linux, and they really don't seem to care about it.  Their
response to questions on the topic is often simply "we're sorry, but
OpenGL is unsupported under Linux."

No info re: your other questions, which were the meat of your post, I
know, sorry.

-c

-- 
Chris Metzler   [EMAIL PROTECTED]
(remove "snip-me." to email)

"As a child I understood how to give; I have forgotten this grace since I
have become civilized." - Chief Luther Standing Bear


pgps4LY9e50B3.pgp
Description: PGP signature
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Multiheaded video cards?

2004-11-02 Thread Jon S Berndt
On Tue, 02 Nov 2004 12:37:40 -0600
 "Curtis L. Olson" <[EMAIL PROTECTED]> wrote:
Has anyone played around with any of these options who can report 
success or failure or something in between?  What kind of performance 
are you getting?
I recall a couple years ago I was running two 17" monitors off of a 
dual head nVidia GeForce MX400 card. When I ran FlightGear, the window 
took up the entire width (two screens) as if the two monitors were one 
wide screen.

Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] Multiheaded video cards?

2004-11-02 Thread Curtis L. Olson
I periodically get asked about multiheaded video cards for FlightGear.  
My standard answer is that I don't know for sure, but I suspect they 
wouldn't work well for FlightGear.  However, the questions keep coming 
and I feel like I'm not able to give a really good answer.

So can anyone help me out?  For instance, has anyone tried one of these 
sorts of cards?

   http://www.matrox.com/mga/products/parhelia/series.cfm
What kind of opengl support is available under linux?
I have always assumed that to render 3 views to 3 monitors, I'd have to 
run through the render loop 3 times, once for each view.  Each time 
through would do a different view frustum cull, etc. etc.  (Note that 
the trick of making one big window and stretching it across all 2 or 3 
displays is not acceptable because we'd like to cover a larger field of 
view than you can realistically do in one window without severe 
distortion.) Also there might be space between each display that would 
need to be accounted for in the config for each display (field of view, 
view center offset, etc.)

So would I need to run 3 copies of flightgear on the same machine?  
Could I modify flightgear some how to draw three different views/windows 
from a single application?  What tricks do people use to most 
effectively leverage multi-headed opengl displays?

Has anyone played around with any of these options who can report 
success or failure or something in between?  What kind of performance 
are you getting?

Thanks,
Curt.
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] plib CVS compatibility

2004-11-02 Thread Arthur Wiebe
On Tue, 02 Nov 2004 18:39:07 +0100, Boris Koenig <[EMAIL PROTECTED]> wrote:
> Arthur Wiebe wrote:
> > I tried, the problem is that it doesn't build on OSX without fixing
> > the source code in some areas, which I tried but it didn't work. The
> > only way I could get it to build was to get plib from CVS which seems
> > to work.
> 
> If any FlightGear dependcy is taken from CVS it's often a good idea
> tosimply grab the other dependencies from CVS, too -in fact it is even
> a requirement for FlightGear(devel)/SimGear(devel).
> 
> 
> Boris

I did. I got both plib and simgear from from CVS.

-- 


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] plib CVS compatibility

2004-11-02 Thread Boris Koenig
Arthur Wiebe wrote:
I tried, the problem is that it doesn't build on OSX without fixing
the source code in some areas, which I tried but it didn't work. The
only way I could get it to build was to get plib from CVS which seems
to work.
If any FlightGear dependcy is taken from CVS it's often a good idea 
tosimply grab the other dependencies from CVS, too -in fact it is even
a requirement for FlightGear(devel)/SimGear(devel).


Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] plib CVS compatibility

2004-11-02 Thread Arthur Wiebe
On Tue, 2 Nov 2004 16:02:45 + (UTC), Martin Spott
<[EMAIL PROTECTED]> wrote:
> Arthur Wiebe wrote:
> 
> > I have built plib from CVS and installed it, but it seems simgear is
> > not compatible with  it or something. Or else there is a problem with
> > my installation.
> 
> Would you mind trying the latest PLIB release (1.8.3) instead ?
> 
> Martin.
> --
>  Unix _IS_ user friendly - it's just selective about who its friends are !

I tried, the problem is that it doesn't build on OSX without fixing
the source code in some areas, which I tried but it didn't work. The
only way I could get it to build was to get plib from CVS which seems
to work.
-- 


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] FG Input

2004-11-02 Thread Magdalena Bugajska
I need to customize the source of the input to FG, i.e. I have a 
specialized input device which would basicaly replace the keyboard.

As far as I can tell the control-mode is specified through option
/sim/control-mode and bindings are defined in appropriate xml file,
but I cannot find the place in code that chooses the input source
during the simulation.  In input.cxx all of them seemed to be initialized.
What am I missing?
Thanks,
Magda
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] plib CVS compatibility

2004-11-02 Thread Martin Spott
Arthur Wiebe wrote:

> I have built plib from CVS and installed it, but it seems simgear is
> not compatible with  it or something. Or else there is a problem with
> my installation.

Would you mind trying the latest PLIB release (1.8.3) instead ?

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] 6-digit airport code

2004-11-02 Thread Martin Spott
"Curtis L. Olson" wrote:

> FlightGear code generally parses on white space rather than column 
> position so I would suspect we'd be ok, however I can't guarantee 100% 
> success.  What is the purpose of 6 digit codes?

Apparently there are two sorts of ICAO (OACI) codes in France. Those
whose format is pretty common to us:

  http://www.fna.asso.fr/_fichiers/france2.pdf

 and something that was new to me - until this morning:

  http://www.fna.asso.fr/_fichiers/france1.pdf

These 6-digit codes are not that uncommon in France, if you google for

  St. Avold LF5723

then you'll actually find several hits for airfields that are nowhere
else associated with any other ICAO code,

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] plib CVS compatibility

2004-11-02 Thread Arthur Wiebe
I have built plib from CVS and installed it, but it seems simgear is
not compatible with  it or something. Or else there is a problem with
my installation.

checking plib/ul.h usability... no
checking plib/ul.h presence... yes
configure: WARNING: plib/ul.h: present but cannot be compiled
configure: WARNING: plib/ul.h: check for missing prerequisite headers?
configure: WARNING: plib/ul.h: see the Autoconf documentation
configure: WARNING: plib/ul.h: section "Present But Cannot Be Compiled"
configure: WARNING: plib/ul.h: proceeding with the preprocessor's result
configure: WARNING: plib/ul.h: in the future, the compiler will take precedence
configure: WARNING: ## -- ##
configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists.  ##
configure: WARNING: ## -- ##
checking for plib/ul.h... yes
checking for plib 1.6.0 or newer... wrong version
configure: error: Install plib 1.6.0 or later first...

I'm using Mac OS X. Does anyone know anything about this, and if you
do give me a hint? :)
Thanks.

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] 6-digit airport code

2004-11-02 Thread Curtis L. Olson
Jon Stockill wrote:
Martin Spott wrote:
Hello,
Robin has some 3-digit airport codes in his database and they appear
not to cause any trouble. Does anyone have an idea what will happen
with 6-digit codes ?

I'd expect problems somewhere - shorter codes shouldn't cause 
problems, but longer ones are bound to run into field length problems 
*somewhere*.

FlightGear code generally parses on white space rather than column 
position so I would suspect we'd be ok, however I can't guarantee 100% 
success.  What is the purpose of 6 digit codes?

Thanks,
Curt.
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] 6-digit airport code

2004-11-02 Thread Jon Stockill
Martin Spott wrote:
Hello,
Robin has some 3-digit airport codes in his database and they appear
not to cause any trouble. Does anyone have an idea what will happen
with 6-digit codes ?
I'd expect problems somewhere - shorter codes shouldn't cause problems, 
but longer ones are bound to run into field length problems *somewhere*.

--
Jon Stockill
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] 6-digit airport code

2004-11-02 Thread Martin Spott
Hello,
Robin has some 3-digit airport codes in his database and they appear
not to cause any trouble. Does anyone have an idea what will happen
with 6-digit codes ?

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Locating an airport control tower

2004-11-02 Thread Martin Spott
"David Luff" wrote:

> [...] The trouble with these
> float->int rounding bugs is that they seem to be OS or compiler specific,
> so I can't always reproduce them.

I'm gonna reproduce any error you like for you  ;-)
I think I'll add some more feature requests along the way  :-)

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Command line debugger

2004-11-02 Thread Martin Spott
Martin Spott wrote:

> Qt for instance - where the current 3.3.3 release does _not_ compile
> out of the box. There is a Qt-3.0.3 freeware package, but QGIS for
> example requires a 3.1.x of higher.

Yup, Nekochan has them:

  ftp://ftp.nekochan.net/pub/downloads/Nekoware/beta/

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Command line debugger

2004-11-02 Thread Martin Spott
Erik Hofman wrote:

> No, but ...
> http://www.cise.ufl.edu/depot/software/software-irix.Programming.shtml#ddd-3.0.92

The link is dead, the 'irix' directory has been removed and 'ddd' is no
more present  :-(

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Command line debugger

2004-11-02 Thread Martin Spott
Erik Hofman wrote:

> Ouch! That requires quite a number of dependencies to be compiled also.

Qt for instance - where the current 3.3.3 release does _not_ compile
out of the box. There is a Qt-3.0.3 freeware package, but QGIS for
example requires a 3.1.x of higher. KDE freeware packages are available
for KDE-1.0 

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] St. Elmo's Fire

2004-11-02 Thread Boris Koenig
David Culp wrote:
> [...]
If I change the time-of-day to something darker the panel code darkens and redens 
everything, which ruins the effect.
> [...]
That's exactly something I have also observed, in particular with
self-illuminating instruments - something like a basic LCD or TFT
shouldn't be subject to general panel darkening, as it has its own
illuminiation - I looked into David's (Megginson) sources and it seems
one would either need to define areas on the panel/screen that aren't
darkened, or -preferably- (in my opinion) provide an additional
parameter to layers that are not subject to panel-darkening.
And for your St. Elmo's Fire it would probably be benefitting if you
could add some diffuse effects, too - I think that's beyond the
capablities of the current XML-instrument code !?
My questions are:
  Can the instrument darkening/redening be turned off per-instrument?
currently not - I'm afraid, at least that's the conclusion that I came
up with ...

  Should we have a seperate screen-drawing subsystem that draws "windscreen   
effects", like St. Elmo's Fire, rain, snow, glare?
I like the idea
-
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] St. Elmo's Fire

2004-11-02 Thread Christian Mayer
David Culp schrieb:
I've been playing with modeling St. Elmo's Fire as an instrument:
http://home.comcast.net/~davidculp2/stelmo-clear-sky.jpg
http://home.comcast.net/~davidculp2/stelmo-in-clouds.jpg
which is convenient, but has some problems.  The main problem here is that 
it's barely visible inside of clouds, where one would expect to see it.  If I 
change the time-of-day to something darker the panel code darkens and redens 
everything, which ruins the effect.

Then of course there's the problem of setting up a boolean property that 
randomly, and rapidly, is "true", in order to model "flickering".  
To increase contrast, you could draw the lines in black for one frame, 
then white for a few frames and then balck again for one frame.

This works at least for normal lightning (but it can be that it won't 
work here)

CU,
Christian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Command line debugger

2004-11-02 Thread Erik Hofman
Jon S Berndt wrote:
On Mon, 01 Nov 2004 21:09:39 +0100
 Erik Hofman <[EMAIL PROTECTED]> wrote:
Jon S Berndt wrote:
Is anyone aware of a command line C++ code debugger? Particularly one 
that runs under IRIX?

If you mean something like gdb for Linux: xdb
Erik

Has anyone used ddd?
No, but ...
http://www.cise.ufl.edu/depot/software/software-irix.Programming.shtml#ddd-3.0.92
> Does KDevelop compile under IRIX? Can it be forced
to do so?
Ouch! That requires quite a number of dependencies to be compiled also.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] ATI 9200 Direct Rendering problem on Linux (was

2004-11-02 Thread Martin Spott
Martin Spott wrote:

> I could 'lend' you my 'xorg.conf' that I use on a customers's PeeCee if
> you are ready to wait until tuesday,

  http://document.ihg.uni-duisburg.de/Misc/xorg.conf.r200

I states "SaX generated" but most of the stuff is the result of manual
editing  :-)

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] ATI 9200 Direct Rendering problem on Linux (was AI Carrier)

2004-11-02 Thread Arnt Karlsen
On Mon, 1 Nov 2004 19:53:15 -0500, Ampere wrote in message 
<[EMAIL PROTECTED]>:
> 
> On November 1, 2004 02:23 pm, Arnt Karlsen wrote:
> > ..and your log mentions "Acceleration enabled".  ;-)
> 
> When I type glxinfo | grep rendering, I got:
> direct rendering: No

..huh?  'glxgears ' says?  I also like to see lspci -v et al 
like in your first log zip ball, or a unified diff from those.

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d