[9fans] Drawterm on MacOS X; weird colormap?

[9fans] Drawterm on MacOS X; weird colormap?

[Dan Cross]

Hey, when running sam or acme under Drawterm on MacOS X (using the X
server from apple), the colors are all messed up (and it's almost
impossible to use).  In particular, the background sort of looks like a
slimey yellow color, and the foreground gets kind of reddish.  It's
reminiscent of running drawterm (or any other program that uses a big
colormap) on an 8-bit X display.  Has anyone else seen this?  And does
anyone know how to fix it, or if it is fixable?  (Geoff?)  Thanks!

	- Dan C.

Re: [9fans] Drawterm on MacOS X; weird colormap?

[Russ Cox]

It sounds like the RGB triples are being used as BGR.
You could put prints in screen-x11.c:/^initmap to
see what's going on, and then reverse the sense of 
the test to get the opposite behavior.

You might try running colors.  The upper right corner
should be red.  

Re: [9fans] Drawterm on MacOS X; weird colormap?

[Moroo Jun]

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

On 2003.01.23, at 04:54, Russ Cox wrote:
> It sounds like the RGB triples are being used as BGR.
> You could put prints in screen-x11.c:/^initmap to
> see what's going on, and then reverse the sense of
> the test to get the opposite behavior.

Does anybody fix this problem?

Here is my quick dirty change for XDarwin 1.1 (XFree86 4.2) with OS X
10.1.5.

One Question:
This patch looks fine except 'sam'.
When I start sam with short file, no text or pop up menu appers.
If I start sam with longer than screen length text, there is no problems.

[-- Attachment #2: patch --]
[-- Type: application/octet-stream, Size: 1859 bytes --]

*** drawtermorg/screen-x11.c	Tue Jul 25 05:28:15 2000
--- drawterm/screen-x11.c	Sat Feb 22 22:52:20 2003
***************
*** 339,345 ****
  				xscreenchan = RGB24;
  				break;
  			case 32:
! 				xscreenchan = CHAN4(CIgnore, 8, CRed, 8, CGreen, 8, CBlue, 8);
  				break;
  			}
  		}
--- 339,345 ----
  				xscreenchan = RGB24;
  				break;
  			case 32:
! 				xscreenchan = CHAN4(CBlue, 8, CGreen, 8, CRed, 8, CIgnore, 8);
  				break;
  			}
  		}
*** drawtermorg/devip-unix.c	Wed May 22 14:57:07 2002
--- drawterm/devip-unix.c	Fri Feb 21 22:56:49 2003
***************
*** 4,9 ****
--- 4,10 ----
  #include <netinet/in.h>
  #include <netdb.h>
  #include <errno.h>
+ #include <netinet/tcp.h>

  #include "lib9.h"
  #include "sys.h"
*** drawtermorg/mkfile	Sat Apr 27 01:51:09 2002
--- drawterm/mkfile	Fri Feb 21 22:55:13 2003
***************
*** 1,5 ****
  #CONF=FreeBSD
! #CONF=FreeBSD-power	# MAC OSX
  #CONF=Irix
  #CONF=Linux
  #CONF=OSF1
--- 1,5 ----
  #CONF=FreeBSD
! CONF=FreeBSD-power	# MAC OSX
  #CONF=Irix
  #CONF=Linux
  #CONF=OSF1
*** drawtermorg/libmemdraw/draw.c	Tue Jul 25 10:23:47 2000
--- drawterm/libmemdraw/draw.c	Sat Feb 22 22:54:03 2003
***************
*** 1577,1582 ****
--- 1577,1583 ----
  _rgbatoimg(Memimage *img, ulong rgba)
  {
  	ulong chan;
+ 	ulong chanfake;
  	int d, nb;
  	ulong v;
  	uchar *p, r, g, b, a, m;
***************
*** 1587,1593 ****
  	b = rgba>>8;
  	a = rgba;
  	d = 0;
! 	for(chan=img->chan; chan; chan>>=8){
  		nb = NBITS(chan);
  		switch(TYPE(chan)){
  		case CRed:
--- 1588,1599 ----
  	b = rgba>>8;
  	a = rgba;
  	d = 0;
! 	if (img->depth == 32) {
! 		chanfake=XRGB32; //XDarwin
! 	} else {
! 		chanfake=img->chan;
! 	}
! 	for(chan=chanfake; chan; chan>>=8){
  		nb = NBITS(chan);
  		switch(TYPE(chan)){
  		case CRed:

Re: [9fans] Drawterm on MacOS X; weird colormap?

[Dan Cross]

> Does anybody fix this problem?

No, it was still broken until I applied your fix; reversing the sense
of the RGB triples does the trick for most programs, but see below.

> Here is my quick dirty change for XDarwin 1.1 (XFree86 4.2) with OS X
> 10.1.5.
>
> One Question:
> This patch looks fine except 'sam'.
> When I start sam with short file, no text or pop up menu appers.
> If I start sam with longer than screen length text, there is no problems.

I don't have the sam problem, though at times all the text in a window
sort of `disappears', that is, becomes the same color as the
background.  Normally if I start up something like sam and then quit
it, it comes back.  I do notice that, with your fix, when I try to page
an image (say, a jpg), the RGB values are again mixed up.  When I try
page with the older version of drawterm, page displays the jpg
correctly.

	- Dan C.

Re: [9fans] Drawterm on MacOS X; weird colormap?

[andrey mirtchovski]

On Sat, 22 Feb 2003, Dan Cross wrote:

> I don't have the sam problem, though at times all the text in a window
> sort of `disappears', that is, becomes the same color as the
> background.  Normally if I start up something like sam and then quit
> it, it comes back.  I do notice that, with your fix, when I try to page


this happens with freebsd's drawterm too, though I have not tried a recent
binary...

Re: [9fans] Drawterm on MacOS X; weird colormap?

[Axel Belinfante]

To come back to a different drawterm related thing for which
a fix would be welcome (other than what I did: reorder the
screen depths tried to avoid the byte order detection check):

it happens that drawterm is not able to detect the X server byte
order on the solaris 2.8 X server (the comment in the code
about the why/how of the current byte order detection scheme
in the code is nice to read, but that does change this situation)

Axel.

Re: [9fans] Drawterm on MacOS X; weird colormap?

[Moroo Jun]

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


> it, it comes back.  I do notice that, with your fix, when I try to page
> an image (say, a jpg), the RGB values are again mixed up.  When I try
> page with the older version of drawterm, page displays the jpg
> correctly.

I made new patch. Please apply this for original drawterm.
But this patch has 'sam' problem yet. Also 'page' pop up menu.

[-- Attachment #2: patch --]
[-- Type: application/octet-stream, Size: 1302 bytes --]

*** drawtermorg/devip-unix.c	Wed May 22 14:57:07 2002
--- drawterm/devip-unix.c	Fri Feb 21 22:56:49 2003
***************
*** 4,9 ****
--- 4,10 ----
  #include <netinet/in.h>
  #include <netdb.h>
  #include <errno.h>
+ #include <netinet/tcp.h>

  #include "lib9.h"
  #include "sys.h"
*** drawtermorg/mkfile	Sat Apr 27 01:51:09 2002
--- drawterm/mkfile	Fri Feb 21 22:55:13 2003
***************
*** 1,5 ****
  #CONF=FreeBSD
! #CONF=FreeBSD-power	# MAC OSX
  #CONF=Irix
  #CONF=Linux
  #CONF=OSF1
--- 1,5 ----
  #CONF=FreeBSD
! CONF=FreeBSD-power	# MAC OSX
  #CONF=Irix
  #CONF=Linux
  #CONF=OSF1
*** drawtermorg/libmemdraw/draw.c	Tue Jul 25 10:23:47 2000
--- drawterm/libmemdraw/draw.c	Sun Feb 23 16:46:02 2003
***************
*** 1994,2000 ****
  	if(val == DNofill)
  		return;

! 	bits = _rgbatoimg(i, val);
  	switch(i->depth){
  	case 24:	/* 24-bit images suck */
  		for(y=i->r.min.y; y<i->r.max.y; y++)
--- 1994,2007 ----
  	if(val == DNofill)
  		return;

! 	if (i->depth == 32) {
! 		bits = val;
! 		bits &= 0x00FF00FF;
! 		bits |= (val << 16) & 0xFF000000;
! 		bits |= (val >> 16) & 0x0000FF00;
! 	} else {
! 		bits = _rgbatoimg(i, val);
! 	}
  	switch(i->depth){
  	case 24:	/* 24-bit images suck */
  		for(y=i->r.min.y; y<i->r.max.y; y++)

Re: [9fans] Drawterm on MacOS X; weird colormap?

[Moroo Jun]

> I don't have the sam problem, though at times all the text in a window
> sort of `disappears', that is, becomes the same color as the
> background.  Normally if I start up something like sam and then quit
> it, it comes back.

I tried to check little bit more.

I logged in and open new window, type '$' and 'return', after that 
type '!', '!' didn't appeared.

When I typed '!', drawterm got 'i' message from rio. So I guess that 
this problem is font cache problem.
But unfortunately, I can't find any difference between appeared case and 
disappeared one.

Re: [9fans] Drawterm on MacOS X; weird colormap?

[Axel Belinfante]

This sounds similar to what I got when I run Solaris 
drawterm with 24bit color -- although I forgot about the
exact color shift; my message about it should be in the
archives. I played a bit trying to fix it but never got
the right colors -- now I'm just using drawterm with 8bit
color (I changed the order in which the different color depths
are tried in drawterm, I think).

I'll have a look again using Russ' reply as inspiration.

Axel.


> Hey, when running sam or acme under Drawterm on MacOS X
> (using the X server from apple), the colors are all messed up
> (and it's almost impossible to use).  In particular, the
> background sort of looks like a slimey yellow color, and
> the foreground gets kind of reddish.  It's reminiscent of
> running drawterm (or any other program that uses a big
> colormap) on an 8-bit X display.  Has anyone else seen this?
> And does anyone know how to fix it, or if it is fixable? 
> (Geoff?)  Thanks!

Re: [9fans] Drawterm on MacOS X; weird colormap?

[geoff]

I don't recall seeing that problem, but I was using the XFree86 port
to OS X.  I just downloaded the Apple beta of their port and haven't
done much with it yet; I'll try it out and see how well it works.

How many colours is your display set up for (in the Apple display
preferences)?  Are you seeing this odd behaviour on the attached
monitor itself, or are you using vnc to reach the mac?

Re: [9fans] refresh problems with drawterm on x (freebsd)?

[Kenji Arisawa]

Hello jas,

> Have you tested it on the latest updated X11 from Apple?
> I've been trying to get a clean build of drawterm again, and am only 
> able to
> get the following error:
>
> Trace/BPT trap

I tested the latest update X11 v0.2.1 today.
That's just fine for drawterm. (Yellow color problem exists though)
Your problem might be in your drawterm. Mine is
-rwxr-xr-x  1 arisawa  staff  1142228 May 18  2002 drawterm
MD5 (drawterm) = 1a184580b7c874f47bad89e4c831a912
that is precompiled binary,i.e., drawterm-macosx

Kenji Arisawa

Re: [9fans] Drawterm on MacOS X; weird colormap?

[Kenji Arisawa]

Hello,

The problem with drawterm on MacOS X is not in color map.
You will find a photo at http://plan9.aichi-u.ac.jp/drawterm/fig2.png,
a screen shot of MaxOS X.

Don't conclude that problem is only in weird color in acme.
I observed the problem that were pointed out by someone.
That is, texts in pops menu and windows become sometimes invisible.

Kenji Arisawa