>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 address@hidden 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
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.