Bug 54379 - Cannot allocate flashing colours from the display
Summary: Cannot allocate flashing colours from the display
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
(Show other bugs)
Version: 7.1
Hardware: i386 Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-10-05 08:50 UTC by Need Real Name
Modified: 2007-04-18 16:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-11-02 11:29:53 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
tar includes 4 files. XFreelogs and XF86configs (70.00 KB, patch)
2001-10-23 08:02 UTC, Need Real Name
no flags Details | Diff

Description Need Real Name 2001-10-05 08:50:03 UTC
Description of Problem:
When I connet to HP-UX (via telnet or SHH) and try to open GUI I can't get flashing symbols to flash. I am using 8-bit colours. On RH 7.0 there is NO problem. I have tested different types of machines (i815-chipset, TNT2-chipset) without help. Why colours flash when I use RH7.0 but not when I use RH7.1 ??? 

Version-Release number of selected component (if applicable):

How Reproducible:
Every time.

Steps to Reproduce:
1.telnet hp-ux
2.setenv DISPLAY <myip:0>
3.wakeupmx guimanmx & 

Actual Results:
Warning dialog appears: Unable to allocate flashing colours from the display. No flashing symbols will be displayed on this session.
Then I clik OK and guiman open but no flashing colours!

Expected Results:
Colours should flash.

Additional Information:
I use KDE. Colours won't flash if I use GNOME (RH7.0 and RH7.1) (and thats why we use KDE. KDE is ok.)
I have even installed kernel 2.4.9 and XFree 4.10, without help. This problem makes me grazy!

Comment 1 Mike A. Harris 2001-10-11 19:26:20 UTC
Use a 16 or 24 bit depth.  In 256 color mode, there are a fixed number
of colors available.  I'm betting your old setup used more than 8 bit depth,
and your existing one uses 8 bit.

Am I way off base?  Either way, attach both your X server log, and your
config file using the link below.

Comment 2 Need Real Name 2001-10-23 08:02:07 UTC
Created attachment 34701 [details]
tar includes 4 files. XFreelogs and XF86configs

Comment 3 Need Real Name 2001-10-23 09:46:06 UTC
We MUST use 256 colors on RH 7.0. If we use any other color depth (16,24) 
colours won`t flash. We use KDE because if we use GNOME colours won`t flash.

Comment 4 Need Real Name 2001-11-02 11:29:47 UTC
There is same problem when using RedHat 7.2

Comment 5 Mike A. Harris 2001-11-02 19:33:40 UTC
Ok, then I'm not clear at all on what it is you are reporting as
a problem.  There is no such thing as "flashing colors", in the
sense that XFree86 uses color.  There are different types of "visuals"
used in X.  There 8 bit depth uses a pseudocolor visual.  This is a
paletted video mode, with 256 color slots available.  Applications
must share these slots and/or compete with each other to use the
available colors.  If the running applications require more color
slots (palette entries) than what is currently free, then each application
will use its own private colormap.  As you switch between applications
that are using their own colormaps, the foreground application will
acquire the palette and look normal, and the background and other
apps will have random psychodelic color patters as their windows get
translated to the new colormap.

This can give the appearance of flashing weirdo looking colors as you
move your mouse around the desktop and it changes focus.  It is not
a bug, but is a hardware limitation of 8bit pseudocolor.  Switching
to a 16 or higher bit depth, gets rid of the pseudocolor limitations,
and also the associated flashing that goes along with it.

The only other "flashing" anything that I can think of, is the flashing
text attribute used in terminal emulation software using ANSI/VT100, etc.

If this is in fact what you are talking about, then this is either a
misconfiguration of your terminal software, or the application running
in the term.  Either way, it very much is not an XFree86 bug, as XFree86
doesn't have anything to do with high level stuff like that.

Note You need to log in before you can comment on or make changes to this bug.