Go Back   nV News Forums > Linux Support Forums > NVIDIA Linux

Newegg Daily Deals

Reply
 
Thread Tools
Old 12-30-08, 12:41 PM   #1
LinUser
Registered User
 
Join Date: Dec 2008
Posts: 2
Default PseudoColor and X color allocation

We have a dual head system running on a RedHat Linux Enterprise Client OS with version 2.6.18-92.1.22.el5. Each head is a flat-panel monitor that is driven by
separate Quadros NVS 290 NVIDIA graphics cards. We are thus using two graphics cards and only one output from each card talks to a single screen. Please see attached xorg.conf file.

I have a graphics application that uses a PseudoColor visual to perform dynamic reads and writes to a colormap utilizing overlay planes. This application expects a default writable colormap and a default pseudocolor visual. It runs on a dedicated monitor. No other graphics/GUI based application shares the same monitor (and color resources).

I have tweaked xorg.conf to make an 8 bit PseudoColor visual on this monitor the default. I can verify this by looking at the output of xdpyinfo. However, with this setup all 256 colorcells seem to be used up even before my application starts up. I have replaced the GNOME window manager with the Motif Window Manager and the Tab Window Manager. This results in an improvement of sorts, I can then allocate up to 11 colors in 4 overlay planes via XallocColorCells. However, to operate with full functionality, my application needs to allocate 13 colors in 4 overlay planes (i.e, 208 out of the available 256 color cells).

I have tried editing the .mwmrc and the .twmrc files to specify a minimal set of colors to use for my window sessions. However, this does not work. It appears that both window managers pre-allocate a certain number of colors in the colormap no matter what the resource settings are.


My questions are:

1) Am I correct in assuming that the Window manager is the application that is hogging most of the available color cells in the default colormap? Is there anyway that I can programmatically query the hardware colormap to identify the processes that are consuming the color cells? Is there a window manager that consumes less color cells than the TWM?

2) Does my Quadros NVS 290 NVIDIA graphics card come with the ability to simultaneously support a 24 bit truecolor visual as well as an 8 bit pseudocolor visual? In my xorg.conf file, I have experimented with options “Dac8bit”,
“OverlayDefaultVisual" , "CIOverlay", and "Overlay". The “DefaultDepth” option in the screen subsection of xorg.conf seems to control the depth of all available visuals (ie, I can only get 8 bit pseudocolor and 8 bit truecolor visuals activated at the same time. Even here, I cannot make the 8 bit truecolor visual the default). I am running version 7.1.1 of the Xorg server.

If I can get my system to support both 24 bit truecolor visuals and 8 bit pseudocolor visuals, I can make the 24 bit truecolor visual the default and have my graphics application use a private colormap based on the 8 bit pseudocolor non-default visual.

3) Does my Quadros NVS 290 NVIDIA graphics card support multiple hardware colormaps? If so, how do I activate this feature?
LinUser is offline   Reply With Quote
Old 12-30-08, 12:58 PM   #2
LinUser
Registered User
 
Join Date: Dec 2008
Posts: 2
Default Re: PseudoColor and X color allocation

I am attaching xorg.conf and xdpyinfo.txt as a reply to my own post.
Attached Files
File Type: txt xdpyinfo.txt (17.5 KB, 233 views)
File Type: txt xorg.conf.txt (3.2 KB, 366 views)
LinUser is offline   Reply With Quote
Old 12-30-08, 01:16 PM   #3
pe1chl
Registered User
 
Join Date: Aug 2003
Posts: 1,026
Default Re: PseudoColor and X color allocation

From the old 8-bit color days I remember that the windowmanagers had a feature to re-load the color table when an application gets focus. So even when your wm or another application allocated all the colors, the application could still get its own colors.
The effect on the screen was weird. When you clicked in a window (or moved the mouse into it) the whole screen became garbled and the contents of the window appeared correct. And the situation reversed when you selected another window.
But it must be 10 years since I last used 8-bit color...
pe1chl is offline   Reply With Quote
Old 01-27-09, 07:58 AM   #4
pmfento
Registered User
 
Join Date: Jan 2009
Posts: 2
Default Re: PseudoColor and X color allocation

We may be experiencing a similar problem. We are running Solaris 10 on Ultra25 (not Intel) platform and the graphics adapter is Sun's XVR-300. The problem we have is an application that needs to run under PseudoColor mode but cannot allocate color cells. An intriguing thing is that it works fine if we don't load Solaris patches. So there is something in the 20 or 30 patches that is pushing us into this problem state. Have pored over the configuration data like Xservers but cannot find any culprit. The "unpatched" Solaris 10 load is at level
118833-33 vs. the "patched" version (which is busted) is at
118833-36
Who knows if your problem and mine are the same.
pmfento is offline   Reply With Quote
Old 02-02-09, 10:28 AM   #5
pmfento
Registered User
 
Join Date: Jan 2009
Posts: 2
Default Re: PseudoColor and X color allocation

Tried changing the windowmanager from CDE to TWM and there is a dramatic
increase in the number of colors that I can allocate. I've resorted to running
"xv" to show me how many colors are available. (right click on the xv splash screen
to get the control window and at the bottom of it, it displays how many colors it
was able to allocate which is the number available.)

So now I'm trying to figure out how to tame CDE's color needs.
Since I didn't have these color problems
before I loaded Solaris Recommended patches, I am guessing that one of the patches
did a CDE configuration tweak that pushed me into this situation.
pmfento is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 02:07 PM.


Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright ©1998 - 2014, nV News.