* [9fans] refresh problems with drawterm on x (freebsd)? @ 2003-03-05 17:59 Russ Cox 2003-03-05 12:36 ` Philippe Anel 2003-03-05 18:46 ` andrey mirtchovski 0 siblings, 2 replies; 31+ messages in thread From: Russ Cox @ 2003-03-05 17:59 UTC (permalink / raw) To: 9fans 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] refresh problems with drawterm on x (freebsd)? 2003-03-05 17:59 [9fans] refresh problems with drawterm on x (freebsd)? Russ Cox @ 2003-03-05 12:36 ` Philippe Anel 2003-03-05 18:46 ` andrey mirtchovski 1 sibling, 0 replies; 31+ messages in thread From: Philippe Anel @ 2003-03-05 12:36 UTC (permalink / raw) To: 9fans 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, ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] refresh problems with drawterm on x (freebsd)? 2003-03-05 17:59 [9fans] refresh problems with drawterm on x (freebsd)? Russ Cox 2003-03-05 12:36 ` Philippe Anel @ 2003-03-05 18:46 ` andrey mirtchovski 2003-03-05 18:50 ` Dan Cross 2003-03-05 21:36 ` [9fans] refresh problems with drawterm on x (freebsd)? anyrhine 1 sibling, 2 replies; 31+ messages in thread From: andrey mirtchovski @ 2003-03-05 18:46 UTC (permalink / raw) To: 9fans 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. > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] refresh problems with drawterm on x (freebsd)? 2003-03-05 18:46 ` andrey mirtchovski @ 2003-03-05 18:50 ` Dan Cross 2003-03-07 1:55 ` Kenji Arisawa 2003-03-05 21:36 ` [9fans] refresh problems with drawterm on x (freebsd)? anyrhine 1 sibling, 1 reply; 31+ messages in thread From: Dan Cross @ 2003-03-05 18:50 UTC (permalink / raw) To: 9fans 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] refresh problems with drawterm on x (freebsd)? 2003-03-05 18:50 ` Dan Cross @ 2003-03-07 1:55 ` Kenji Arisawa 2003-03-07 6:14 ` andrey mirtchovski ` (2 more replies) 0 siblings, 3 replies; 31+ messages in thread From: Kenji Arisawa @ 2003-03-07 1:55 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] refresh problems with drawterm on x (freebsd)? 2003-03-07 1:55 ` Kenji Arisawa @ 2003-03-07 6:14 ` andrey mirtchovski 2003-03-07 23:12 ` Russ Cox 2003-03-08 6:45 ` Kenji Arisawa 2 siblings, 0 replies; 31+ messages in thread From: andrey mirtchovski @ 2003-03-07 6:14 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] refresh problems with drawterm on x (freebsd)? 2003-03-07 1:55 ` Kenji Arisawa 2003-03-07 6:14 ` andrey mirtchovski @ 2003-03-07 23:12 ` Russ Cox 2003-03-08 0:06 ` Geoff Collyer 2003-03-08 6:45 ` Kenji Arisawa 2 siblings, 1 reply; 31+ messages in thread From: Russ Cox @ 2003-03-07 23:12 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] refresh problems with drawterm on x (freebsd)? 2003-03-07 23:12 ` Russ Cox @ 2003-03-08 0:06 ` Geoff Collyer 0 siblings, 0 replies; 31+ messages in thread From: Geoff Collyer @ 2003-03-08 0:06 UTC (permalink / raw) To: 9fans 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] refresh problems with drawterm on x (freebsd)? 2003-03-07 1:55 ` Kenji Arisawa 2003-03-07 6:14 ` andrey mirtchovski 2003-03-07 23:12 ` Russ Cox @ 2003-03-08 6:45 ` Kenji Arisawa 2003-03-13 9:55 ` Jeff Sickel 2 siblings, 1 reply; 31+ messages in thread From: Kenji Arisawa @ 2003-03-08 6:45 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] refresh problems with drawterm on x (freebsd)? 2003-03-08 6:45 ` Kenji Arisawa @ 2003-03-13 9:55 ` Jeff Sickel 2003-03-13 12:11 ` Kenji Arisawa 0 siblings, 1 reply; 31+ messages in thread From: Jeff Sickel @ 2003-03-13 9:55 UTC (permalink / raw) To: 9fans 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] refresh problems with drawterm on x (freebsd)? 2003-03-13 9:55 ` Jeff Sickel @ 2003-03-13 12:11 ` Kenji Arisawa 2003-03-13 13:58 ` [9fans] Drawterm on MacOS X; weird colormap? Kenji Arisawa 0 siblings, 1 reply; 31+ messages in thread From: Kenji Arisawa @ 2003-03-13 12:11 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] Drawterm on MacOS X; weird colormap? 2003-03-13 12:11 ` Kenji Arisawa @ 2003-03-13 13:58 ` Kenji Arisawa 0 siblings, 0 replies; 31+ messages in thread From: Kenji Arisawa @ 2003-03-13 13:58 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] refresh problems with drawterm on x (freebsd)? 2003-03-05 18:46 ` andrey mirtchovski 2003-03-05 18:50 ` Dan Cross @ 2003-03-05 21:36 ` anyrhine 2003-03-05 20:18 ` Russ Cox 1 sibling, 1 reply; 31+ messages in thread From: anyrhine @ 2003-03-05 21:36 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] refresh problems with drawterm on x (freebsd)? 2003-03-05 21:36 ` [9fans] refresh problems with drawterm on x (freebsd)? anyrhine @ 2003-03-05 20:18 ` Russ Cox 2003-03-05 21:55 ` anyrhine 0 siblings, 1 reply; 31+ messages in thread From: Russ Cox @ 2003-03-05 20:18 UTC (permalink / raw) To: 9fans the port numbers were already configurable. i use drawterm -c tcp!plan9.bell-labs.com!87 all the time. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] refresh problems with drawterm on x (freebsd)? 2003-03-05 20:18 ` Russ Cox @ 2003-03-05 21:55 ` anyrhine 2003-03-06 15:38 ` Philippe Anel 0 siblings, 1 reply; 31+ messages in thread From: anyrhine @ 2003-03-05 21:55 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] refresh problems with drawterm on x (freebsd)? 2003-03-05 21:55 ` anyrhine @ 2003-03-06 15:38 ` Philippe Anel 2003-03-06 14:08 ` Russ Cox 0 siblings, 1 reply; 31+ messages in thread From: Philippe Anel @ 2003-03-06 15:38 UTC (permalink / raw) To: 9fans 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, ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] refresh problems with drawterm on x (freebsd)? 2003-03-06 15:38 ` Philippe Anel @ 2003-03-06 14:08 ` Russ Cox 2003-03-06 14:16 ` Russ Cox 0 siblings, 1 reply; 31+ messages in thread From: Russ Cox @ 2003-03-06 14:08 UTC (permalink / raw) To: 9fans 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? ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] refresh problems with drawterm on x (freebsd)? 2003-03-06 14:08 ` Russ Cox @ 2003-03-06 14:16 ` Russ Cox 2003-03-07 16:19 ` Ralph Corderoy 0 siblings, 1 reply; 31+ messages in thread From: Russ Cox @ 2003-03-06 14:16 UTC (permalink / raw) To: 9fans > 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] refresh problems with drawterm on x (freebsd)? 2003-03-06 14:16 ` Russ Cox @ 2003-03-07 16:19 ` Ralph Corderoy 2003-03-07 14:15 ` Russ Cox 0 siblings, 1 reply; 31+ messages in thread From: Ralph Corderoy @ 2003-03-07 16:19 UTC (permalink / raw) To: 9fans 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/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] refresh problems with drawterm on x (freebsd)? 2003-03-07 16:19 ` Ralph Corderoy @ 2003-03-07 14:15 ` Russ Cox 2003-03-10 10:18 ` Ralph Corderoy 0 siblings, 1 reply; 31+ messages in thread From: Russ Cox @ 2003-03-07 14:15 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] refresh problems with drawterm on x (freebsd)? 2003-03-07 14:15 ` Russ Cox @ 2003-03-10 10:18 ` Ralph Corderoy 0 siblings, 0 replies; 31+ messages in thread From: Ralph Corderoy @ 2003-03-10 10:18 UTC (permalink / raw) To: 9fans 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/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* [9fans] Drawterm on MacOS X; weird colormap? @ 2003-01-22 19:44 Dan Cross 2003-01-22 19:54 ` Russ Cox ` (2 more replies) 0 siblings, 3 replies; 31+ messages in thread From: Dan Cross @ 2003-01-22 19:44 UTC (permalink / raw) To: 9fans 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] Drawterm on MacOS X; weird colormap? 2003-01-22 19:44 [9fans] Drawterm on MacOS X; weird colormap? Dan Cross @ 2003-01-22 19:54 ` Russ Cox 2003-02-22 14:23 ` Moroo Jun 2003-01-22 22:39 ` Axel Belinfante 2003-01-23 1:02 ` geoff 2 siblings, 1 reply; 31+ messages in thread From: Russ Cox @ 2003-01-22 19:54 UTC (permalink / raw) To: 9fans 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] Drawterm on MacOS X; weird colormap? 2003-01-22 19:54 ` Russ Cox @ 2003-02-22 14:23 ` Moroo Jun 2003-02-22 17:02 ` Dan Cross 0 siblings, 1 reply; 31+ messages in thread From: Moroo Jun @ 2003-02-22 14:23 UTC (permalink / raw) To: 9fans [-- 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: ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] Drawterm on MacOS X; weird colormap? 2003-02-22 14:23 ` Moroo Jun @ 2003-02-22 17:02 ` Dan Cross 2003-02-22 17:08 ` andrey mirtchovski ` (2 more replies) 0 siblings, 3 replies; 31+ messages in thread From: Dan Cross @ 2003-02-22 17:02 UTC (permalink / raw) To: 9fans > 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] Drawterm on MacOS X; weird colormap? 2003-02-22 17:02 ` Dan Cross @ 2003-02-22 17:08 ` andrey mirtchovski 2003-02-22 19:41 ` Axel Belinfante 2003-02-23 7:58 ` Moroo Jun 2003-03-05 14:34 ` Moroo Jun 2 siblings, 1 reply; 31+ messages in thread From: andrey mirtchovski @ 2003-02-22 17:08 UTC (permalink / raw) To: 9fans 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... ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] Drawterm on MacOS X; weird colormap? 2003-02-22 17:08 ` andrey mirtchovski @ 2003-02-22 19:41 ` Axel Belinfante 0 siblings, 0 replies; 31+ messages in thread From: Axel Belinfante @ 2003-02-22 19:41 UTC (permalink / raw) To: 9fans 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] Drawterm on MacOS X; weird colormap? 2003-02-22 17:02 ` Dan Cross 2003-02-22 17:08 ` andrey mirtchovski @ 2003-02-23 7:58 ` Moroo Jun 2003-03-05 14:34 ` Moroo Jun 2 siblings, 0 replies; 31+ messages in thread From: Moroo Jun @ 2003-02-23 7:58 UTC (permalink / raw) To: 9fans [-- 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++) ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] Drawterm on MacOS X; weird colormap? 2003-02-22 17:02 ` Dan Cross 2003-02-22 17:08 ` andrey mirtchovski 2003-02-23 7:58 ` Moroo Jun @ 2003-03-05 14:34 ` Moroo Jun 2 siblings, 0 replies; 31+ messages in thread From: Moroo Jun @ 2003-03-05 14:34 UTC (permalink / raw) To: 9fans > 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] Drawterm on MacOS X; weird colormap? 2003-01-22 19:44 [9fans] Drawterm on MacOS X; weird colormap? Dan Cross 2003-01-22 19:54 ` Russ Cox @ 2003-01-22 22:39 ` Axel Belinfante 2003-01-23 1:02 ` geoff 2 siblings, 0 replies; 31+ messages in thread From: Axel Belinfante @ 2003-01-22 22:39 UTC (permalink / raw) To: 9fans 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! ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] Drawterm on MacOS X; weird colormap? 2003-01-22 19:44 [9fans] Drawterm on MacOS X; weird colormap? Dan Cross 2003-01-22 19:54 ` Russ Cox 2003-01-22 22:39 ` Axel Belinfante @ 2003-01-23 1:02 ` geoff 2 siblings, 0 replies; 31+ messages in thread From: geoff @ 2003-01-23 1:02 UTC (permalink / raw) To: 9fans 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? ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2003-03-13 13:58 UTC | newest] Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-03-05 17:59 [9fans] refresh problems with drawterm on x (freebsd)? Russ Cox 2003-03-05 12:36 ` Philippe Anel 2003-03-05 18:46 ` andrey mirtchovski 2003-03-05 18:50 ` Dan Cross 2003-03-07 1:55 ` Kenji Arisawa 2003-03-07 6:14 ` andrey mirtchovski 2003-03-07 23:12 ` Russ Cox 2003-03-08 0:06 ` Geoff Collyer 2003-03-08 6:45 ` Kenji Arisawa 2003-03-13 9:55 ` Jeff Sickel 2003-03-13 12:11 ` Kenji Arisawa 2003-03-13 13:58 ` [9fans] Drawterm on MacOS X; weird colormap? Kenji Arisawa 2003-03-05 21:36 ` [9fans] refresh problems with drawterm on x (freebsd)? anyrhine 2003-03-05 20:18 ` Russ Cox 2003-03-05 21:55 ` anyrhine 2003-03-06 15:38 ` Philippe Anel 2003-03-06 14:08 ` Russ Cox 2003-03-06 14:16 ` Russ Cox 2003-03-07 16:19 ` Ralph Corderoy 2003-03-07 14:15 ` Russ Cox 2003-03-10 10:18 ` Ralph Corderoy -- strict thread matches above, loose matches on Subject: below -- 2003-01-22 19:44 [9fans] Drawterm on MacOS X; weird colormap? Dan Cross 2003-01-22 19:54 ` Russ Cox 2003-02-22 14:23 ` Moroo Jun 2003-02-22 17:02 ` Dan Cross 2003-02-22 17:08 ` andrey mirtchovski 2003-02-22 19:41 ` Axel Belinfante 2003-02-23 7:58 ` Moroo Jun 2003-03-05 14:34 ` Moroo Jun 2003-01-22 22:39 ` Axel Belinfante 2003-01-23 1:02 ` geoff
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).