52634 2004-05-31 15:31 0000 Eterm has "ghost boxes" and other visual issues on AMD64 2004-07-17 19:49:44 0000 1 1 1 Unclassified Gentoo Linux Applications unspecified AMD64 Linux RESOLVED FIXED http://forums.gentoo.org/viewtopic.php?t=139496&highlight= P2 minor --- 1 BonezTheGoon@gmail.com vapier@gentoo.org amd64@gentoo.org trey@blancher.net BonezTheGoon@gmail.com 2004-05-31 15:31:45 0000 When using Eterm on an AMD64 build with GCC-3.4.0-r1 (atleast that's what I'm using it may be a more broad problem than that) it does not give the expected results. In almost every character slot where there should be a blank space there is instead a character "ghost box" -- see the linked forum thread for more details Reproducible: Always Steps to Reproduce: 1.Setup an AMD64 based system 2.Emerge Eterm 3.Try to use it Actual Results: Eterm is so ugly it is not really usable Expected Results: A nice to use Eterm trey@blancher.net 2004-06-01 23:31:04 0000 I get the same thing, and it's not limited to GCC-3.4.0-r1. I'm running GCC 3.3.3 on x86_64 and I get the same thing. BonezTheGoon@gmail.com 2004-06-04 20:20:16 0000 First of all I should have been MUCH more specific. This is the x11-terms/eterm I am talking about (not that anyone misunderstood at all, I'm just trying to clarify) Next on my agenda is that I found an interesting behavior that I thought might spark an idea in the head of a more educated and/or experienced person. If you launch Eterm and you list the contents of the current directory (or really just otherwise fill the screen with output so that you get plenty of these "ghost boxes") then you move another window over top of it you can "erase" the ghost boxes much like you would use an erase tool in a drawing program. Once erased they will easily come back once you try to interact again with the session in the terminal window. Not too exciting but I was surprised by the outcome, and thought it _might_ be helpful. BonezTheGoon@gmail.com 2004-06-04 20:25:02 0000 Hey I am using x.org's release of X windows. Has anyone tried this on Xfree86 on an AMD64 platform, or has anyone tried Eterm on an x86 platform running x.org's release? Maybe we (I) have incorrectly assigned and named this bug. Any thoughts? I will try on x86 with x.org as soon as I can, but I'm doing too much on my AMD64 right now to bother with testing on it (more than I have to I mean.) Regards, BonezTheGoon lv@gentoo.org 2004-06-05 13:01:08 0000 not a gcc-porting bug slam@parasite.tzo.net 2004-07-07 21:37:29 0000 Created an attachment (id=34976) fix in MEMSET macro in libast.h for (at least) AMD64 (64 bit) I found what I believe to be the problem (it fixes it on my system). It's the MEMSET macro in libast.h (installed as /usr/include/libast.h) that eterm uses. The macro assumes that a long is no more than 32 bits, when on AMD64 it's 64 bits. Once this patch has been applied, you must rebuild eterm. herbs@gentoo.org 2004-07-08 01:14:24 0000 yep, the patch works for me. No more annoying little boxes. vapier@gentoo.org 2004-07-08 08:09:43 0000 i'll take this upstream then, thanks :) lv@gentoo.org 2004-07-08 10:50:07 0000 i've added this patch to libast. it only applies if on a 64bit system for now, as i havent tested this on a 32bit box :) slam@parasite.tzo.net 2004-07-08 16:18:46 0000 I just compiled Eterm in a chroot 32 bit environment with the libast patch. It works fine in 32 bit. It should, the shift operation I added in the patch should basically do nothing in a 32 bit environment. BonezTheGoon@gmail.com 2004-07-08 18:21:13 0000 This patch works and is now in portage, if you have problems like this with your Eterm I suggest running an emerge sync and then emerge libast next re-emerge Eterm. I am marking this bug fixed. vapier@gentoo.org 2004-07-08 18:54:48 0000 i havent taken this upstream yet :P chris@nukes.ltd.uk 2004-07-10 03:30:46 0000 Transparancy doesn't seem to work on x86 either.. slam@parasite.tzo.net 2004-07-10 04:03:19 0000 Hmmm I don't have any problems with transparency in 64 or 32 bit Eterm (32 bit chroot x86 environment). Works fine here. vapier@gentoo.org 2004-07-10 08:44:04 0000 transparency works fine; sounds like a bug in your settings vapier@gentoo.org 2004-07-14 20:42:54 0000 could you guys try this patch ? Index: include/libast.h =================================================================== RCS file: /cvsroot/enlightenment/eterm/libast/include/libast.h,v retrieving revision 1.51 diff -u -r1.51 libast.h --- include/libast.h 29 Jun 2004 21:18:07 -0000 1.51 +++ include/libast.h 15 Jul 2004 02:55:40 -0000 @@ -1137,7 +1137,7 @@ #endif /* Fast memset() macro contributed by vendu */ -#if (SIZEOF_LONG == 8) +#if !defined(SIZEOF_LONG) || (SIZEOF_LONG == 8) /** UNDOCUMENTED */ # define MEMSET_LONG() (l |= l<<32) #else slam@parasite.tzo.net 2004-07-17 17:34:52 0000 I just tested your changes against libast 0.5-r2 and can confirm that it works in 64 and 32 bit. Obviously I didn't look real hard at what was going on in there ... your fix is the (more) correct solution :) Sorry it took me awhile to test it ... Jason vapier@gentoo.org 2004-07-17 18:54:28 0000 np ... that patch isnt from me, it's from upstream maintainer ... it really is a kludge around the problem anyways ... the problem is much deeper and has been fixed properly in the upcoming 0.6 release thanks for confirming it; upstream maintainer just wanted a confirmation :) slam@parasite.tzo.net 2004-07-17 19:49:44 0000 Cool. Just glad to see it fixed ... :) 34976 2004-07-07 21:37 0000 fix in MEMSET macro in libast.h for (at least) AMD64 (64 bit) libast_memset_64bit_fix.diff text/plain LS0tIGxpYmFzdC5oCTIwMDItMDktMzAgMTA6NDM6MzguMDAwMDAwMDAwIC0wNTAwCisrKyAvdXNy L2luY2x1ZGUvbGliYXN0LmgJMjAwNC0wNy0wNyAyMjoyNjo0My4wMjk3MTIxOTYgLTA1MDAKQEAg LTMzNyw2ICszMzcsNyBAQAogICAgICAgICAvKiBmaWxsIGwgd2l0aCBjLiAqLyBcCiAgICAgICAg IGwgPSAoYykgfCAoYyk8PDg7IFwKICAgICAgICAgbCB8PSBsPDwxNjsgXAorICAgICAgICBsIHw9 IGw8PDMyOyBcCiAgICAgICAgIE1FTVNFVF9MT05HKCk7IFwKICBcCiAgICAgICAgIC8qIGZpbGwg aW4gMS1ieXRlIGNodW5rcyB1bnRpbCBib3VuZGFyeSBvZiBsb25nIGlzIHJlYWNoZWQuICovIFwK