I'm using the Bluecurve gtkrcs to theme GTK apps. After installing xorg-x11-6.8.2-r6, the colors appear to be "too bright". This is what the theme is supposed to look like (xorg-x11-6.8.2-r4): http://217.69.165.143/r4.png This is what it looks like using r6: http://217.69.165.143/r6.png Since the only change between r4 and r6 seems to be a different set of patches, I guess that one of those is responsible for the problem: 1000_all_6.8.2-fix-kbd-on-kernel-2.4.patch 1001_all_6.8.2-sunffb-xaa-extension.patch 1002_all_6.8.2-sunleo-fixes.patch 9924_all_6.8.2-fbmmx-may.patch 9924_all_6.8.2-fix-fbcopy-transparencies.patch 9930_all_6.8.2-fbmmx-gcc4.patch
-r6 contains fixes that should fix up certain rendering paths in fbmmx, but the fixes were not complete. They were included to avoid the issue with incorrect transparencies in applications such as OpenOffice and Wine. Please post your 'emerge info'. I didn't see this behaviour on my Gnome install when I was running 6.8.2-r6, but I wasn't using Bluecurve.
Here's my emerge info output: Gentoo Base System version 1.6.13 Portage 2.0.53 (default-linux/x86/2005.1, gcc-3.4.4, glibc-2.3.5-r2, 2.6.15 i686) ================================================================= System uname: 2.6.15 i686 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i386-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe -msse2 -msse3 -m3dnow" CHOST="i386-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=i686 -pipe -msse2 -msse3 -m3dnow" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://ftp-stud.fht-esslingen.de/Mirrors/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowext X aalib alsa apm arts audiofile avi berkdb bitmap-fonts bzip2 cdparanoia crypt cups curl dvd dvdread eds emboss encode esd expat fam ffmpeg foomaticdb gdbm gif gnome gpm gstreamer gtk gtk2 idn imlib ipv6 java jpeg kde kdeenablefinal lcms libg++ libwww mad mikmod mmx mng motif mp3 mpeg ncurses nls ogg oggvorbis opengl oss pam pcre pdflib perl png python qt quicktime readline sdl spell sse sse2 ssl tcpd tiff truetype truetype-fonts type1-fonts udev vorbis xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
Hmm, I wonder if it's an AMD64 issue. I think the best thing you can try is switch to 7.0. Take a look at http://www.gentoo.org/proj/en/desktop/x/x11/modular-x-howto.xml if you're interested. Also, I'm interested: Why did you choose those CHOST/CFLAGS?
> Hmm, I wonder if it's an AMD64 issue. I was wondering that, too. I'll have a look if that problem appears on a pentium 4, too. > I think the best thing you can try is switch to 7.0. Take a look at > http://www.gentoo.org/proj/en/desktop/x/x11/modular-x-howto.xml if you're > interested. Guess I'll have a look at that, too. I usually like to keep the files in /etc/portage small, but it's probably worth a try. > Also, I'm interested: Why did you choose those CHOST/CFLAGS? I've only had this AMD64 cpu for about 2 weeks, replacing my old Athlon XP system (where I ran -r4). Since I experienced weird freezes with that installation on the new PC (most notably while scrolling in firefox and while watching tv using tvtime), I thought I'd build a new system using kinda generic CFLAGS. I figured -march=i686 doesn't include SSE2, SSE3, and 3dnow instructions, so I added those switches to my CFLAGS :) About the CHOST: Well, according to bug #105809, CHOST should never be changed - so I didn't (I used a stage 1 tarball even though I do know stage 1 installs are deprecated...).
While I certainly make no claim to be an expert on GCC, I believe that CHOST defines what host architecture to target code for. 386 code should work on 80386 and up, etc. So if you set it to 686, it will generate code more suited to your modern processor. The idea is that CHOST should never be changed mid-install if you expect things not to break. Changing the CHOST and then doing a complete rebuild *might* work. And let me know how the 7.0 install turns out. If you still have the same graphical issues, then it's a problem upstream and we'll get it solved there.
Same thing using the modular X.org 7.0.0 build. I still need to check this on a 32 bit cpu in order to rule out an Athlon 64 issue though. I'll post the results as soon as I have them.
If it's an issue in 7.0 then either: 1) That's the way the theme is supposed to look and it's been broken until the fixes were put in, or 2) This bug lies in the upstream code. In the case of 2 you should post a bug on bugs.freedesktop.org .
Waiting for a response, please reopen when you reply.
I'm sorry for taking forever to respond. Apparently, the problem has gone away with xorg-x11-6.8.2-r7. xorg-x11-7.0-r1 is working fine, too.
Alright, let us know if it crops up again.
