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

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

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

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

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

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

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

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

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

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

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

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

> 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,

> > 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/