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

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

[Philippe Anel]

At 12:59 05/03/03 -0500, you wrote:
>Has anyone else encountered refresh problems
>using drawterm on XFree86 / FreeBSD?  A few people
>here have intermittent problems but we can't seem
>to characterize them.

Hi,

I don't know if it is related, but I've problems with
drawterm on XFree86 (4.2) and FreeBSD (4.7) (on a
dual PIII 450 + Matrox G200 PCI).
It seems that only a glyph out of three is drawn.

I hadn't the time to figure out why, because I was as
busy as a bee with my job, and I only passed a few hours
writting the plan9 ati/radeon driver.

Anyway if I can help ... don't think twice about it.

         Philippe, 

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

[Russ Cox]

Has anyone else encountered refresh problems
using drawterm on XFree86 / FreeBSD?  A few people
here have intermittent problems but we can't seem
to characterize them.

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

[andrey mirtchovski]

Text will just disappear from acme and terminal windows. I wouldn't even be
able to see the text in the menu options (though the green rectangle still 
appears)

Is there a newer version of drawterm for bsd I could try?

andrey

On Wed, 5 Mar 2003, Russ Cox wrote:

> Has anyone else encountered refresh problems
> using drawterm on XFree86 / FreeBSD?  A few people
> here have intermittent problems but we can't seem
> to characterize them.
> 

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

[Dan Cross]

Russ wrote:
> Has anyone else encountered refresh problems
> using drawterm on XFree86 / FreeBSD?  A few people
> here have intermittent problems but we can't seem
> to characterize them.
> 

To which Andrey replied:
> Text will just disappear from acme and terminal windows. I wouldn't even be
> able to see the text in the menu options (though the green rectangle still 
> appears)
> 
> Is there a newer version of drawterm for bsd I could try?

The problem Andrey reports is the problem I've had under MacOS X.
Well, that and the colormap thing.  I've not seen it under FreeBSD,
though I've probably got a slightly older version of drawterm installed
here.

	- Dan C.

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

[Russ Cox]

the port numbers were already configurable.
i use

	drawterm -c tcp!plan9.bell-labs.com!87

all the time.

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

[anyrhine]

andrey mirtchovski wrote:

> Text will just disappear from acme and terminal windows. I wouldn't even be
> able to see the text in the menu options (though the green rectangle still 
> appears)

I'm having similar problems with linux and a slow (128k) network
connection, but it seems to be hardware dependent (possibly even
XFree86 bug?). On all <500MHz workstations with Matrox G200 display
card at our department I have a problem that after connecting with
drawterm, all characters of a font don't work (some do). After cat'ing
a file with lots of different characters and resizing the window a few times,
I'm able to get all the characters working. The ritual has to be repeated
for each font.

On newer 1.3-2.4GHz systems with Matrox G400 or G450 graphics I am
not able to reproduce this, but have the problem you described instead.
Unfortunately I can't remember did only the acme's font stop working, or
was it all fonts. I'll try to check this tomorrow.

Also, the drawterm I'm using isn't the binary in plan9 distribution, but
one built by myself (with gcc 2.96) from the source at sources. I had to
do this because I needed to make the port numbers configurable to get
around a firewall.

Using the same binary in the same network with the cpu server, and
with ati graphics, I have experienced neither of the problems, though
I've used it more.

	-Aki

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

[anyrhine]

> the port numbers were already configurable.
> i use
> 
> 	drawterm -c tcp!plan9.bell-labs.com!87
> 
> all the time.

Stupid me. I remember I tried that, but most likely forgot some 's
and so the !-marks got eaten by bash, and then didn't bother to
read the source deeper than drawterm.c :) Thanks.

	-Aki

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

[Russ Cox]

i don't think that needs to be #ifdef FREEBSD.
i made the change on sources.

what about your old drawterm binary didn't work?

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

[Russ Cox]

> what about your old drawterm binary didn't work?

never mind, i should read my mail.  still, the drawterm
code that is on sources is what i've been trying to use,
and it still has the glyph refresh problem.

it seems pretty clear that painting the background is
completing after painting the foreground characters,
but the question is why.  we have the same problem with the
accelerated hardware drivers -- drawing the background
is an accelerated op so you have to issue it and then wait
for it to complete before trying to draw the text.
i did not realize that sequential X calls can overlap
like that, but empirically, they must.

yesterday i tried inserting calls to XSync() after issuing
the XFillRectangle calls, but that didn't help.  i still need
to try XFlush.  i really wish the documentation were better.

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

[Philippe Anel]

Hi,

After a replica/pull, I've recompiled drawterm on FreeBSD,
and now, it works. (The drawterm which don't work is the binary
one in plan9 distribution).
Here is a little diff needed to compile drawterm ...

diff devip-unix.c devip-unix.c.old
8,11d7
< #ifdef FREEBSD
< #include <netinet/tcp.h>	// TCP_NODELAY
< #endif

	Philippe,

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

[Kenji Arisawa]

Hello.

Dan Cross said:
> To which Andrey replied:
>> Text will just disappear from acme and terminal windows. I wouldn't 
>> even be
>> able to see the text in the menu options (though the green rectangle 
>> still
>> appears)
>>
>> Is there a newer version of drawterm for bsd I could try?
>
> The problem Andrey reports is the problem I've had under MacOS X.
> Well, that and the colormap thing.


You will find my drawterm screen shot of MacOS X at 
http://plan9.aichi-u.ac.jp/drawterm/fig1.png
I believe the problem is simply in a colormap.
More important is: I cannot send any control character code.

Kenji Arisawa

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

[andrey mirtchovski]

> You will find my drawterm screen shot of MacOS X at 
...

I like plan9 screenshots.. we should have more of those, just for fun!
...proving that "themes" do not a window manager make :)

here's an old one of mine:

http://homepage.usask.ca/~aam396/p9.gif

I wish I had saved the one with 'devtv' displaying an f1 qualification on a
machine that had no idea such things as tv tuners for PC's existed :)

andrey

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

[Russ Cox]

> I'm coming into the conversation part-way through here, but if you're
> saying you've an X client doing XDrawText() and XFillRectangle() Xlib
> calls, or you're generating the equivalent protocol, there's no way that
> the operations should be done out of order.

I'm an X client doing:

	XFillRectangle
	XGetSubImage
	XPutImage

in that order, and it appears that the XFillRectangle sometimes completes
after the XPutImage.

It certainly seems X server dependent, but I attributed that to
some cards have an accelerated XFillRectangle and some not.

Russ

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

[Ralph Corderoy]

Hi Russ,

> it seems pretty clear that painting the background is completing after
> painting the foreground characters, but the question is why.  we have
> the same problem with the accelerated hardware drivers -- drawing the
> background is an accelerated op so you have to issue it and then wait
> for it to complete before trying to draw the text.  i did not realize
> that sequential X calls can overlap like that, but empirically, they
> must.

I'm coming into the conversation part-way through here, but if you're
saying you've an X client doing XDrawText() and XFillRectangle() Xlib
calls, or you're generating the equivalent protocol, there's no way that
the operations should be done out of order.

> yesterday i tried inserting calls to XSync() after issuing the
> XFillRectangle calls, but that didn't help.  i still need to try
> XFlush.  i really wish the documentation were better.

X protocol is asynchronous, but the order is maintained.  You can watch
the protocol by putting a `snooper' in the middle, but if you find a
filled rectangle drawn before the text is covering it then it suggests
an X server bug, probably specific to the graphic card's driver.  A
mixture of accelerated and non-accelerated ops are the driver's problem,
not the X client's or the device independent parts of the X server.

Does this only occur with a specific X server?  If multiple people are
seeing it with different graphic cards/X servers, then it suggests a
client bug, possibly a dodgy Graphics Context results in the
text-drawing not changing any pixels.

Cheers,

-- 
Ralph Corderoy.      http://inputplus.co.uk/ralph/     http://troff.org/

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

[Russ Cox]

> You will find my drawterm screen shot of MacOS X at 
> http://plan9.aichi-u.ac.jp/drawterm/fig1.png
> I believe the problem is simply in a colormap.
> More important is: I cannot send any control character code.

Geoff Collyer did the work to get drawterm going
under Mac OS X.  I'm assuming control characters
worked for him.

Are you running your screen in 8-bit mode?
That seems very unlikely, so I doubt that your
problem is actually a colormap.  I'm not sure
what the problem is, though.  The pale yellow
and pale blue that acme uses are just about as
different as could be, yet they appear to be the
same saturated yellow in your screen shot.
Very strange.

Russ

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

[Geoff Collyer]

I got drawterm running under a pre-release version of Mac OS 10.2.  I
had problems that sound like the ones others are having now; Russ
thought at the time that they were X server bugs, so I didn't pursue
fixes.  I had problems at all colour depths.  The work-around I
usually used was to start a graphical program, usually sam, and then
exit from it.  That often restored the whole drawterm.

I think I was able to send and receive control characters.

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

[Kenji Arisawa]

I said:
 >More important is: I cannot send any control character code.

I have two X11 in MacOS X
1. XDarwin
	XonX Contributes to XFree86 4.2
	http://sourceforge.net/projects/xonx/
	the logo is shown at: 
http://plan9.aichi-u.ac.jp/drawterm/xdarwin-logo.png
2. X11
	recently supported by Apple.
	the logo is shown at: http://plan9.aichi-u.ac.jp/drawterm/x11-logo.png
I examined control character problem using these two systems.
The conclusion is:
	XDarwin is buggy. unable to send control code.
	X11 is no problem.

Thanks,

Kenji Arisawa

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

[Ralph Corderoy]

Hi Russ,

> > I'm coming into the conversation part-way through here, but if
> > you're saying you've an X client doing XDrawText() and
> > XFillRectangle() Xlib calls, or you're generating the equivalent
> > protocol, there's no way that the operations should be done out of
> > order.
> 
> I'm an X client

And proud of it?

> doing:
> 
> 	XFillRectangle
> 	XGetSubImage
> 	XPutImage
> 
> in that order, and it appears that the XFillRectangle sometimes
> completes after the XPutImage.

You could try trimming a couple of pixels off the filled rectangle all
the way around so you can see the text peeking out if it truely is
happening that way.

> It certainly seems X server dependent, but I attributed that to some
> cards have an accelerated XFillRectangle and some not.

As I said before, any `acceleration' under the X server's cover doesn't
alter the model presented to the client.  I suggest contacting the X
server people.

Cheers,

-- 
Ralph Corderoy.      http://inputplus.co.uk/ralph/     http://troff.org/

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

[Jeff Sickel]

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

jas

Kenji Arisawa <arisawa@ar.aichi-u.ac.jp> wrote:
> 2. X11
> 	recently supported by Apple.
> 	the logo is shown at: http://plan9.aichi-u.ac.jp/drawterm/x11-logo.png
> I examined control character problem using these two systems.
> The conclusion is:
> 	XDarwin is buggy. unable to send control code.
> 	X11 is no problem.

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

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?

[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?

[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?

[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?

[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?

[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?

[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] 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?

[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.  

[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.