xchat colors (Was Re: [parisc-linux] xfree86 4.2.1-9 build problem)

xchat colors (Was Re: [parisc-linux] xfree86 4.2.1-9 build problem)

[caslivkoff]

Hi Grant,

> yup - I was looking to find the code to and at least print a warning
> so I know that's the problem. I've spent < 1h hunting through the code
> to figure out where the colors for the text box was allocated. Haven't
> found it yet though.

Just to be sure this is indeed a colormap issue, start an X session using twm, then only launch xchat. If the colors are "OK", then it's a pretty good bet that the default colormap is max-ed out.

Also, I've attached is short Xlib program. This will report the number of private color cells remaining in the default colormap.

-chuck

Re: xchat colors (Was Re: [parisc-linux] xfree86 4.2.1-9 build problem)

[Grant Grundler]

On Thu, Aug 14, 2003 at 10:26:38PM +0000, caslivkoff@speakeasy.net wrote:
> Just to be sure this is indeed a colormap issue, start an X session
> using twm, then only launch xchat. If the colors are "OK",
> then it's a pretty good bet that the default colormap is max-ed out.
> 
> Also, I've attached is short Xlib program. This will report the
> number of private color cells remaining in the default colormap.

The attachement didn't make it through.
I got the copy at another email address and put the hppa binary,
source, and "README" in a tarball:
	http://iou.parisc-linux.org/hppa/xcmap.tgz

When running twm on c3k (1280x1024x8), xcmap reports:
| Default visual is 256-color PseudoColor
| 10 private color cells available

Things are worse with fvwm:
| Default visual is 256-color PseudoColor
| 0 private color cells available

It didn't matter which window mangler I used.
Both failed to provide the text color.

xchat2 wants 23 colors - but they don't need to be private though.
Will add some more printks to xchat so I know what/how it's failing.

thanks again for xcmap....handy in this case.

grant

[parisc-linux] Re: xchat colors

[Grant Grundler]

On Thu, Aug 14, 2003 at 10:26:38PM +0000, caslivkoff@speakeasy.net wrote:
> Also, I've attached is short Xlib program. This will report the
> number of private color cells remaining in the default colormap.

moving my .Xdefaults to Xdefaults-ggg got me two more colors with twm
(grand total of 12).

Another clue is messing with color settings in the
preferences gets me something visible in the text box.
Wierd is it mangled the xterm foreground for *new* xterms,
not the existing ones....at least until I restored my .Xdefaults
and opened new xterms.

Seems like I want to figure out how to setup a fixed color
map as suggest earlier by Alan Cox. Or fix xchat so it
doesn't attempt to get writeable colors until someone
messes with the color preferences.

thanks,
grant

Re: [parisc-linux] Re: xchat colors

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1391 bytes --]

On Fri, 2003-08-15 00:16:01 -0600, Grant Grundler <grundler@parisc-linux.org>
wrote in message <20030815061601.GD2989@dsl2.external.hp.com>:
> On Thu, Aug 14, 2003 at 10:26:38PM +0000, caslivkoff@speakeasy.net wrote:
> > Also, I've attached is short Xlib program. This will report the
> > number of private color cells remaining in the default colormap.
> 
> Seems like I want to figure out how to setup a fixed color
> map as suggest earlier by Alan Cox. Or fix xchat so it
> doesn't attempt to get writeable colors until someone
> messes with the color preferences.

Um, maybe this is related to XFree problems in Debian/unstable?
Unstable's current XFree (4.2.1.1) "RENDER" extension (used for
anti-aliasing IIRC) takes a _lot_ of colors for it's own (rumors I
heared talked about > 200 IIRC) so generally, you won't be left with a
useable X in unstable (because with 8bit depth, there's only a hand full
of remaining colors available at all:)

Later X versions allow you to kill the RENDER extension so you'll get
your colors back. But until then...

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [parisc-linux] Re: xchat colors

[Grant Grundler]

On Fri, Aug 15, 2003 at 08:37:18AM +0200, Jan-Benedict Glaw wrote:
> Unstable's current XFree (4.2.1.1) "RENDER" extension (used for
> anti-aliasing IIRC) takes a _lot_ of colors for it's own (rumors I
> heared talked about > 200 IIRC)...

On this note I want to share solving my last problem with xchat
and 8-bit TrueColor. C3k doesn't have anything better at the moment.

The "couriour new" font was getting mangled colors as part of the
effort to anti-alias (what I assume is) a true-type or re-sized font.
Picking a bitmap font like "fixed" too take care of this.
Nice readable letters all in white.

hth,
grant

Re: xchat colors (Was Re: [parisc-linux] xfree86 4.2.1-9 build problem)

[Grant Grundler]

On Thu, Aug 14, 2003 at 10:26:38PM +0000, caslivkoff@speakeasy.net wrote:
> Just to be sure this is indeed a colormap issue,

Ok - it's a color map issue.
I added some printf's to xchat-2.0.3/fe-gtk/palette.c:palette_alloc().

I'll see how hard it is to teach xchat to use it's own color map.

grant

grundler <527>xchat
palette_alloc() cmap has 256 colors
palette_alloc() alloc color failed for 21 (0x0 0x0 0xffff)
palette_alloc() alloc color failed for 20 (0x8c8c 0x1010 0x1010)
palette_alloc() alloc color failed for 19 (0x0 0x0 0x0)
palette_alloc() alloc color failed for 18 (0xc866 0xc866 0xc866)
palette_alloc() alloc color failed for 17 (0x0 0x0 0x0)
palette_alloc() alloc color failed for 16 (0xa4a4 0xdfdf 0xffff)
palette_alloc() alloc color failed for 15 (0x9999 0x9999 0x9999)
palette_alloc() alloc color failed for 14 (0x7777 0x7777 0x7777)
palette_alloc() alloc color failed for 13 (0xeeee 0x2222 0xeeee)
palette_alloc() alloc color failed for 12 (0x0 0x0 0xffff)
palette_alloc() alloc color failed for 11 (0x3333 0xeeee 0xffff)
palette_alloc() alloc color failed for 10 (0x0 0xcccc 0xcccc)
palette_alloc() alloc color failed for 9 (0x3333 0xdede 0x5555)
palette_alloc() alloc color failed for 8 (0xeeee 0xdddd 0x2222)
palette_alloc() alloc color failed for 7 (0xffff 0xaaaa 0x0)
palette_alloc() alloc color failed for 6 (0xbbbb 0x0 0xbbbb)
palette_alloc() alloc color failed for 5 (0xaaaa 0x0 0x0)
palette_alloc() alloc color failed for 4 (0xdddd 0x0 0x0)
palette_alloc() alloc color failed for 3 (0x0 0xcccc 0x0)
palette_alloc() alloc color failed for 2 (0x0 0x0 0xcccc)
palette_alloc() alloc color failed for 1 (0x0 0x0 0x0)
palette_alloc() alloc color failed for 0 (0xcf3c 0xcf3c 0xcf3c)
grundler <528>

Re: xchat colors (Was Re: [parisc-linux] xfree86 4.2.1-9 build problem)

[James Bottomley]

On Fri, 2003-08-15 at 12:21, Grant Grundler wrote:
> On Thu, Aug 14, 2003 at 10:26:38PM +0000, caslivkoff@speakeasy.net wrote:
> > Just to be sure this is indeed a colormap issue,
> 
> Ok - it's a color map issue.
> I added some printf's to xchat-2.0.3/fe-gtk/palette.c:palette_alloc().
> 
> I'll see how hard it is to teach xchat to use it's own color map.

Perhaps take Alan's suggestion instead...give the framebuffer a Direct
or True Colour visual instead of Pseudocolour.

That will look rather strange because you'll only get two or three bits
for each primary, but it will mean that you can't run out of colours.

I'll see if I can figure out how to set this up...the documentation
appears to be a bit sparse [unless Alan has any hints].

James

Re: xchat colors (Was Re: [parisc-linux] xfree86 4.2.1-9 build problem)

[James Bottomley]

On Fri, 2003-08-15 at 13:19, James Bottomley wrote:
> I'll see if I can figure out how to set this up...the documentation
> appears to be a bit sparse [unless Alan has any hints].

OK, the way you do this is to start x and then type xdpyinfo.  As part
of a general list, it should give you all the visuals (including the one
it's picked as the default).

Then, you simply choose the TrueColor visual, count its index down from
the top (starting at zero---note, this isn't the visual id xdpyinfo
gives you) and then feed this back into startx:

startx -- -cc <visual index>

So on the B180, my visuals output looks like:

  number of visuals:    8
  default visual id:  0x29
  visual:
    visual id:    0x27
    class:    PseudoColor
    depth:    8 planes
    available colormap entries:    256
    red, green, blue masks:    0x0, 0x0, 0x0
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x28
    class:    GrayScale
    depth:    8 planes
    available colormap entries:    256
    red, green, blue masks:    0x0, 0x0, 0x0
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x29
    class:    StaticColor
    depth:    8 planes
    available colormap entries:    256
    red, green, blue masks:    0x7, 0x38, 0xc0
    significant bits in color specification:    8 bits
 [...]

So to get the StaticColor visual, I issue

startx -- -cc 2

The colours are slightly off, though (my white has now got a bluish
tinge, but I assume you can find a better visual than the one I chose).

James

Re: xchat colors (Was Re: [parisc-linux] xfree86 4.2.1-9 build problem)

[Alan Cox]

On Gwe, 2003-08-15 at 19:19, James Bottomley wrote:
> I'll see if I can figure out how to set this up...the documentation
> appears to be a bit sparse [unless Alan has any hints].

In the display section

	Visual  "TrueColor"

See man XF86Config

Re: xchat colors (Was Re: [parisc-linux] xfree86 4.2.1-9 build problem)

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1274 bytes --]

On Sat, 2003-08-16 01:43:01 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk>
wrote in message <1060994580.9255.1.camel@dhcp23.swansea.linux.org.uk>:
> On Gwe, 2003-08-15 at 19:19, James Bottomley wrote:
> > I'll see if I can figure out how to set this up...the documentation
> > appears to be a bit sparse [unless Alan has any hints].
> 
> In the display section
> 
> 	Visual  "TrueColor"

Now, after our hero Alan "fixed" our Xfree configury, I can really use
X11 on my B132L+ with Debian unstable:) There are still some little
problems (The "less-than, greater-than and pipe" key doesn't yet work,
and some apps don't seem to correctly work (mozilla-snapshot, dillo),
but we're almost there:) Oh, when I press NumLock (with X11), the
keyboard doesn't respond any longer (I need to shutdown X11 using the
mouse) and "gsckbd_leds: timeout" is logged...

I'm just compiling current CVS, maybe I can fix something.

Happy meeting at Oldenburg!

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: xchat colors (Was Re: [parisc-linux] xfree86 4.2.1-9 build problem)

[Chuck Slivkoff]

On Friday, Aug 15, 2003, at 13:21 US/Eastern, Grant Grundler wrote:

> Ok - it's a color map issue.
> I added some printf's to xchat-2.0.3/fe-gtk/palette.c:palette_alloc().
>
> I'll see how hard it is to teach xchat to use it's own color map.

I recall looking into this once with a GTK+ app. It wasn't trivial. 
Even if you do get it coded, you will likely end-up with colormap 
flashing (aka "technicolor effect") when focus is switched in & out of 
the client window. The Vis-EG has 2 HW LUTs which under HP-UX, would 
prevent the technicolor effect by allowing 2 colormaps to be installed 
in HW simultaneously. But, I don't know if the stifb driver was written 
to take advantage of them both. If you can accept the "off" colors that 
an 8-bit TrueColor default visual would give you (due to the uneven 
3/3/2 split between R/G/B), that would be the easiest solution & would 
ensure that all clients can get the colors they want.

This is on a Visualize-EG, right? Under HP-UX, the Vis-EG (standard on 
the PCI card & optionally on the GSC & integrated versions) has the 
capability of doing 8/8 double-buffering with another 8-bit overlay. It 
would be great if the stifb driver could really take advantage of all 
24-planes (or even 16), but I don't think that's been implemeneted. 
Does anyone know if it's even possible? (I know NeXTStep on the 712 was 
able to somehow squeeze 16-bit graphics out of the supposedly 8-bit 
Artist adapter. Anyone have any idea how this was done?)

BTW, there's a pretty good but somewhat old (May 1996) white-paper here:

   http://www.hp.com/xwindow/sharedInfo/Whitepapers/Visuals/visuals.html

that discusses X11 visuals and the capabilities of some of the HP 
graphics adapters under HP-UX.


-chuck

Re: xchat colors (Was Re: [parisc-linux] xfree86 4.2.1-9 build problem)

[Grant Grundler]

On Sat, Aug 16, 2003 at 11:18:50AM -0400, Chuck Slivkoff wrote:
> If you can accept the "off" colors that 
> an 8-bit TrueColor default visual would give you (due to the uneven 
> 3/3/2 split between R/G/B), that would be the easiest solution & would 
> ensure that all clients can get the colors they want.

Chuck, thanks again!

I can live with off colors since this seems to work.
(thanks again Alan too)

I'll submit a patch to xchat so at least it checks the
gdk return values and complains if it can't get the colors.

thanks,
grant

[parisc-linux] Re: xchat colors

[Grant Grundler]

On Mon, Aug 18, 2003 at 11:08:29PM -0600, Grant Grundler wrote:
> I'll submit a patch to xchat so at least it checks the
> gdk return values and complains if it can't get the colors.

patch submitted to debian bug #200903.
IMHO a pathetic patch. If someone is looking for a very small
project, cleaning up xchat color handling would be a good thing.

I just realized that instead of xchat allocating it's own colors,
it might be nice to prompt the user to select from existing "default"
colors. And reduce the number of colors used overall by xchat.

grant