20010302: Default color depth on McIDAS-LINUX

>From: "Watson, Dave" <address@hidden>
>Organization: CSU/CIRA
>Keywords: 200103022246.f22MkUL23927 McIDAS-X Linux visual

Dave,

>I have a PC that is running Unidata McIDAS 7.704 on LINUX (Red Hat 7).
>When I start McIDAS with the -verbose switch, I get McIDAS starting with
>the desktop graphics colors as the default and not the pseudocolor
>8-bit.  My goal is for McIDAS-LINUX to run 250 frames in 8-bit color
>mode.  The system has 256MB RAM and a 8MB ATI graphics card.

OK.  Is RedHat 7 running XFree86 4.0?  What is the result of an
xdpyinfo run from the Unix command prompt (this must be run
from the console)?  When I run thins on our RedHat 7.0 system I
only find one visual.  Do you see more than one visual?  Only
having one visual is what I would expect to see from experience with
XFree86 on pre-7 RedHat Linux systems.

>If I set my display to use 16-bit I get the following message:
>
>Using default 16 deep TrueColor visual (64 entry colormap)
>mcimage: number of graphics colors plus image colors cannot be more than
>62
>mcimage: attempting to guess a good vaue
>Using 8 graphics colors, 100 image colors
>Using pixmap buffers
>mcimage: Using slow processing for Z-32 images

I get almost the same message on our RedHat 7 system.  The only difference
is that I get the message:

mcimage: Using slow processing for Z-16 images and I do not get the
message about "Using pixmap bufferes".

>If I set the display to 24-bit I get this message:
>
>Using default 24 deep TrueColor visual (256 entry colormap)
>Using 17 graphics colors, 100 image colors
>Using pixmap buffers
>mcimage: Using slow processing for Z-32 images

Hmm...  strange.  I run in 24-bit mode on my RedHat 6.2 system at home
and do not get messages about needing to use fewer graphics and image
colors.

>If I set the display to 8-bit I get strange colors and messages

Which window manager are you using?  Your comment about strange colors
leads me to believe that your window manager and other applications are
using most/all of the available colors and forcing McIDAS to start
using a private colormap.  What were the strange messages?

>With the display set to 24-bit the system gets 'bogged down', RAM fills
>up.

I assume that the system gets bogged down due to the much greater demand
for memory followed by the OS doing a lot of swapping.

>Is there something I'm missing to get McIDAS to start with the
>default 8-bit?

According to what I have been led to believe, the McIDAS image window
was designed to try to use the 8-bit pseudocolor visual (if it exists)
by default.  One site reported some strange behavior on their DEC Alpha
(OSF/1 4.0F) system: their image window was a strange redish color
until the user made it get the focus by moving/clicking the mouse on
it.  Also, the user noted that they would get a red flash when shutting
down the window manager (at logout).  The solution to their problem was
to add the -displayVisualMode flag to their .mcidasrc file.  I don't
think that this same approach should help you with your problem since
this flag is designed to force McIDAS to use the default visual instead
of the pseudocolor 8-bit one that you want.

>Is it a problem with the graphics card?

I don't think so.  I use an 8 MB ATI Expert@Play card in my RedHat 6.2
Linux box at home and get good results.  I don't however run with many
frames, so my experience will be different from yours.

>I'm a LINUX "newbie", so I could easily overlook something

I don't think that you are, or, at least, your email does not suggest
that you are overlooking anything obvious.  The xdpyinfo output may,
however, shed some light on what visuals are available.  If there is
only one, this would be why your system is not using the 8-bit
pseudo color one when you are set for 16 or 24-bit depths.

I would be interested in hearing what, if any, change you see if you
specify the -displayVisualMode flag in your .mcidasrc file.  I would
add this to the very bottom of the file and then stop and restart
your McIDAS-X session.

>Thanks,

Sorry I couldn't be of more help.

I must tell you that RedHat 7 is not fully supported by me, and it is
totally unsupported by SSEC.  In addition to the changes in inetd
services (RH 7 no longer has an inetd daemon; it was replaced by xinetd
AND the configuration setup is totally different), I have recently
found that RedHat 6.2 and 7.0 Linux systems can not reliably serve
sounding data through the remote ADDE server.  I have been fighting
this problem for over three weeks now, and have no feeling for what is
happening.  I strongly suspect that the OS is _for some unknown reason_
terminating the socket connection between the client that is requesting
the sounding data (for Skew-Ts, Hodographis, upper air listings) and
the server that is providing it.  I can not discern any good reason why
this may be happening.  Interestingly, I do NOT see the problem on
RedHat 5.2 systems or on other Unix OSes running on Intel-based
platforms (e.g., no problems are seen when using Solaris x86 2.[78] or
FreeBSD 4.2)

>**********************************************************************
>Dave Watson
>Colorado State University
>Cooperative Instute for Research in the Atmosphere - CIRA
>email: address@hidden
>web: http://www.cira.colostate.edu/
>Ph: (970) 491-8470
>**********************************************************************

Tom Yoksas