Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
OpenOffice is not able to display images with a transparent background. It paints the background in black. I happens since I updated my system yesterday (11/06/05). It's no able to display rightly its own icons, nor images into the Impress, for instance. I've checked dependencies (revdep-rebuild) and there's nothing wrong. Reproducible: Always Steps to Reproduce: 1. Run OpenOffice 2. 3. # emerge --info Portage 2.0.51.22-r1 (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.5-r0, 2.6.10-gentoo-r6 i686) ================================================================= System uname: 2.6.10-gentoo-r6 i686 Intel(R) Pentium(R) M processor 1.60GHz Gentoo Base System version 1.6.12 dev-lang/python: 2.3.5, 2.4.1 sys-apps/sandbox: 1.2.8 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.5 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.18 virtual/os-headers: 2.6.11-r1 ACCEPT_KEYWORDS="x86 ~x86" ACCEPT_LICENSE="" ANT_HOME="/usr/share/ant-core" ARCH="x86" AUTOCLEAN="yes" BASH_ENV="/etc/spork/is/not/valid/profile.env" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -O3 -pipe" CHOST="i686-pc-linux-gnu" CLASSPATH="." CLEAN_DELAY="5" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /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/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CVS_RSH="ssh" CXXFLAGS="-march=pentium4 -O3 -pipe" DISPLAY=":0.0" DISTDIR="/usr/portage/distfiles" EDITOR="/usr/bin/vim" ELIBC="glibc" EMERGE_WARNING_DELAY="10" FEATURES="autoconfig distlocks sandbox sfperms strict" FETCHCOMMAND="/usr/bin/wget -t 5 --passive-ftp -P ${DISTDIR} ${URI}" GCC_SPECS="" GDK_USE_XFT="1" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" GLIBC_SSP_CHECKED="1" GRP_STAGE23_USE="ipv6 pam tcpd readline nls ssl gpm perl python berkdb ncurses" GUILE_LOAD_PATH="/usr/share/guile/1.6" G_BROKEN_FILENAMES="1" HOME="/root" HOSTNAME="acsev-052" INFOPATH="/usr/share/info:/usr/share/binutils-data/i686-pc-linux-gnu/2.16.1/info:/usr/share/gcc-data/i686-pc-linux-gnu/3.4.4/info" JAVAC="/opt/blackdown-jdk-1.4.2.01/bin/javac" JAVA_HOME="/opt/blackdown-jdk-1.4.2.01" JDK_HOME="/opt/blackdown-jdk-1.4.2.01" KDEDIRS="/usr" KDE_MALLOC="1" KERNEL="linux" LESS="-R" LESSOPEN="|lesspipe.sh %s" LOGNAME="root" MAIL="/var/mail/root" MAKEOPTS="-j2" MANPATH="/usr/local/share/man:/usr/share/man:/usr/share/binutils-data/i686-pc-linux-gnu/2.16.1/man:/usr/share/gcc-data/i686-pc-linux-gnu/3.4.4/man::/opt/blackdown-jdk-1.4.2.01/man:/usr/qt/3/doc/man:/opt/vmware/man:/opt/insight/man" MOZILLA_FIVE_HOME="/usr/lib/mozilla" OLDPWD="/usr/include" OPENGL_PROFILE="xorg-x11" PAGER="/usr/bin/less" PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/3.4.4:/opt/blackdown-jdk-1.4.2.01/bin:/opt/blackdown-jdk-1.4.2.01/jre/bin:/usr/qt/3/bin:/usr/kde/3.4/sbin:/usr/kde/3.4/bin:/usr/kde/3.3/sbin:/usr/kde/3.3/bin:/opt/vmware/bin" PKGDIR="/usr/portage/packages" PORTAGE_ARCHLIST="alpha amd64 arm hppa ia64 m68k mips ppc ppc64 ppc-macos ppc-od s390 sh sparc x86 x86-fbsd x86-obsd x86-od"PORTAGE_BINHOST_CHUNKSIZE="3000" PORTAGE_CALLER="emerge" PORTAGE_GID="250" PORTAGE_MASTER_PID="21675" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PRELINK_PATH="" PRELINK_PATH_MASK="/usr/lib/gstreamer-0.8" PWD="/usr/include/libpq" PYTHONPATH="/usr/lib/portage/pym" QMAKESPEC="linux-g++" QTDIR="/usr/qt/3" RESUMECOMMAND="/usr/bin/wget -c -t 5 --passive-ftp -P ${DISTDIR} ${URI}" RPMDIR="/usr/portage/rpm" RSYNC_RETRIES="3" RSYNC_TIMEOUT="180" SGML_CATALOG_FILES="/etc/sgml/sgml-docbook.cat:/etc/sgml/openjade-1.3.2.cat:/etc/sgml/html401.cat:/etc/sgml/sgml-ent.cat:/etc/sgml/xml-simple-docbook-4.1.2.4.cat:/etc/sgml/sgml-docbook-3.0.cat:/etc/sgml/sgml-docbook-3.1.cat:/etc/sgml/sgml-docbook-4.0.cat:/etc/sgml/sgml-docbook-4.1.cat:/etc/sgml/sgml-docbook-4.3.cat:/etc/sgml/sgml-lite.cat:/etc/sgml/dsssl-docbook-stylesheets.cat" SHELL="/bin/bash" SHLVL="1" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" TERM="xterm" USE="x86 X aalib acpi alsa apm arts avi bash-completion berkdb bitmap-fonts bonobo cdr crypt cups curl divx4linux dvd dvdr dvdread eds emboss encode esd fam flac font-server foomaticdb fortran gcj gd gdbm gif gnome gphoto2 gpm gstreamer gtk gtk2 gtkhtml hal i8x0 imagemagick imlib ipv6 java jpeg junit ldap libg++ libwww mad mikmod mmx mono motif mozilla mp3 mpeg mysql nas ncurses nls ntpl odbc ogg oggvorbis opengl pam pdflib perl png postgres python quicktime readline samba sdl slang snmp spell sqlite sse sse2 ssl svg svga synaptics tcltk tcpd tetex tiff transcode truetype truetype-fonts type1-fonts unicode vorbis wifi wmf xine xml xml2 xmms xv xvid zlib userland_GNU kernel_linux elibc_glibc" USER="root" USERLAND="GNU" USE_EXPAND="FRITZCAPI_CARDS FCDSL_CARDS VIDEO_CARDS INPUT_DEVICES LINGUAS USERLAND KERNEL ELIBC" XARGS="xargs -r" XAUTHORITY="/root/.xauthpOwgG7" XINITRC="/etc/X11/xinit/xinitrc" _="/usr/bin/emerge"
Created an attachment (id=61195) [edit] Image showing how OpenOffice displays icons
which packages did you update before the problem occured?
(In reply to comment #2) > which packages did you update before the problem occured? No idea. The suggested by portage (I just did 'emerge --ask --update world')
"No idea" is no good basis for identifying problems... Check /var/log/emerge.log the info should be in there
(In reply to comment #4) > "No idea" is no good basis for identifying problems... Check /var/log/emerge.log > the info should be in there 1118653663: >>> emerge (1 of 18) sys-devel/binutils-config-1.8-r3 to / 1118653752: >>> emerge (2 of 18) net-misc/rsync-2.6.5 to / 1118654373: >>> emerge (3 of 18) dev-db/libpq-8.0.3 to / 1118654601: >>> emerge (4 of 18) dev-db/pgadmin3-1.2.1-r1 to / 1118655280: >>> emerge (5 of 18) x11-misc/ttmkfdir-3.0.9-r3 to / 1118655316: >>> emerge (6 of 18) x11-base/opengl-update-2.2.1 to / 1118655337: >>> emerge (7 of 18) x11-base/xorg-x11-6.8.2-r2 to / 1118660338: >>> emerge (8 of 18) x11-terms/xterm-200-r2 to / 1118660437: >>> emerge (9 of 18) dev-libs/libsigc++-2.0.14 to / 1118660526: >>> emerge (10 of 18) sys-devel/binutils-2.16.1 to / 1118661333: >>> emerge (11 of 18) sys-kernel/gentoo-sources-2.6.11-r11 to / 1118661629: >>> emerge (12 of 18) dev-libs/libpqxx-2.5.1 to /
No one seems to be responsible for these behaivor, does it? I though I could have updated a graphic library, but I didn't. Any idea?
I've got the problem too on my home computer, but not on my office computer. What could be happening is a strange interaction with Xcomposite and alpha visuals (similar to what kuickshow used to have). Unfortunately I don't use openoffice much on my home system so I don't know the causing package either. I did however test disabling both XComposite and XEVIE and that didn't help. The strange thing though is that openoffice has almost no external bindings. I also tried to display the same openoffice over a remote connection and that worked. This means that it is almost certainly either an xorg regression or an xorg induced openoffice regression.
BTW. I'm running 6.8.99.8 on my home machine, and 6.8.2-r1 on the machine I used for remote testing
(In reply to comment #8) > BTW. I'm running 6.8.99.8 on my home machine, and 6.8.2-r1 on the machine I used > for remote testing The error is happening since I updated xorg to 6.8.2-r2. I'll try to downgrade, and If I sucesss I'll report you in order to assign the bug to the gentoo's xorg group.
(In reply to comment #9) > (In reply to comment #8) > > BTW. I'm running 6.8.99.8 on my home machine, and 6.8.2-r1 on the machine I used > > for remote testing > > The error is happening since I updated xorg to 6.8.2-r2. I'll try to downgrade, > and If I sucesss I'll report you in order to assign the bug to the gentoo's xorg > group. I've downgraded my xorg version, and now everything works fine. Currently I'm using 6.8.2-r1 (previously 6.8.2-r2)
*** Bug 96244 has been marked as a duplicate of this bug. ***
WINE is also affected by the bug - some icons in some apps also have black borders. Moreover, in OOImpress some diagrams have a black background in slideshow - mode, semi-transparency doesn't work (both in OO-1.1 and 2.0 beta). This is definately caused by xorg-x11-6.8.2-r2.
*** Bug 96153 has been marked as a duplicate of this bug. ***
I'm experiencing this problem with openoffice-ximian and recent xorg snapshots (6.8.99.3, 6.8.99.5 and 6.8.99.8), although less serious: the only "black" icons are those in Formula Wizards. Wine to the contrary is almost completely broken. Maybe this is related to video card, if I switch from radeon driver (I've got a radeon 7500) to vesa driver icons work again. Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.5-r0, 2.6.12-ck2 i686) ================================================================= System uname: 2.6.12-ck2 i686 AMD Athlon(tm) XP 1700+ Gentoo Base System version 1.6.12 Python: dev-lang/python-2.3.5 [2.3.5 (#1, Jun 3 2005, 18:54:40)] dev-lang/python: 2.3.5 sys-apps/sandbox: [Not Present] sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer" CHOST="i686-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/texmf/web2c /etc/env.d" CXXFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://sunsite.cnlab-switch.ch/ftp/mirror/gentoo/ http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/" LANG="it_IT" LDFLAGS="-Wl,-O1 -Wl,--sort-common -s" LINGUAS="it en_GB de fr" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 16bit 3dnow 3dnowext X a52 aac acpi acpi4linux alsa apache2 audiofile avi bash-completion berkdb bmp bzip2 cdparanoia cdr crypt cups curl dbus divx4linux dlloader dts dv dvd dvdread eds emboss encode faac faad fbcon fbdev ffmpeg firefox flac font-server foomaticdb fortran gd gif glitz gnome gpm gstreamer gtk gtk2 gtkhtml hal imagemagick imlib innodb ithreads java javascript jce jpeg kdeenablefinal lcms libg++ libwww live lzw-tiff mad matroska mmap mmx mmxext mng motif mozilla mozsvg mp3 mpeg mysql ncurses network nls no-old-linux nomac nptl objc ogg oggvorbis opengl pam pdflib perl png ppds python qt quicktime readline real rtc samba sdl sndfile spell sse ssl svg svga tcpd tetex tga theora threads tiff truetype truetype-fonts type1 type1-fonts uptimed usb userlocales videos vidix vorbis win32codecs wmf xchatdccserver xine xml2 xprint xv xvid yv12 zlib video_cards_radeon linguas_it linguas_en_GB linguas_de linguas_fr userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CBUILD, CTARGET, LC_ALL
Here's a list of the added/removed patches: +0487_all_6.8.2-add-relocation-type-10-to-elfloader.patch +1050_all_6.8.2-xft-releasefile-crash.patch -5140_all_6.8.0-radeon-swsusp.patch +5137_all_6.8.2-fix-r128-undefined-write-depth.patch +9003_all_6.8.2-lnx-evdev-keyboard-dont-grab.patch +9913_all_6.8.2-cfbgc-gcc4.patch +9914_all_6.8.2-mmx-gcc4.patch +9915_all_6.8.2-radeon-gcc4.patch +9920_all_6.8.2-fix-write-combining.patch Of those, I suspect it's most likely due to 5140. Could everyone besides Giacomo comment on whether you're using the radeon driver? Also, I'd appreciate if you tried patching 5140 into 6.8.2-r2 and reported back on how it worked.
I can confirm this problem using ATI binaries.
I'm on Nvidia with this problem.
I'm using the radeon driver (with the problem)
Created an attachment (id=62043) [edit] Screenshot of Wine This morning I upgraded to last xorg snapshot in portage (6.8.99.13) and putting back patch 5140 didn't fix the problem. Neither patch 5137 seems to be responsible (at least with snapshot 6.8.99.8). In the attachment there is a screenshot of the problem in firefox 1.0.2 under Wine. Also, I realized that I never noticed the problem before switching from gcc 3.3.x to to gcc 3.4.x, but I can't be sure because both wine and openoffice formulas are tools that I don't use frequently.
I have the same problem. I have 2 graphics cards (and 2 CRTs): 1. nVidia MX400 working on nVidia propriety drivers, 2. TSENG ET6000 working on xorg driver. If OpenOffice (or wine) window is on first display (nVidia) icons have black background, when on second display (tseng) icons display normally.
HI!! I'VE FOUND OUT SOMETHING!! It seems to me very much that it is the problem with the background colors! Some OO toolbar and theme packages states that, if the bk color is brighter then f1f1f1 then it'll be highlighted by black! But they say that f1f1f1 will do. ---> It does not! Try out e1e1e1 and that will do! Have a nice day! Semir (HUN)
Hi again! Actually, c1c1c1 will be the best ... With regards, Semir
Is there any further info on this? How do we fix it?
the bug in xorg-x11 6.8.2-r2 is caused by patch 9914_all_6.8.2-mmx-gcc4.patch. if the patch had been applied in xorg CVS this explains why the snapshots are affected.
Yes, it's been applied to upstream CVS. Please file a bug at bugs.freedesktop.org and post the URL here. Thanks!
https://bugs.freedesktop.org/show_bug.cgi?id=3781
I'm coming from bug #96153 (marked as duplicate of this one). For me, x11-base/xorg-x11-6.8.99.14 (which explicitely excludes patch 9914) *does* have the problem. I still have to use 6.8.2-r1 to get rid of it. Any suggestions ? Should I try excluding other patches and report back ?
You would know this if you read comments #24 and #25.
in case anyone is wondering, the problem still exists with x11-base/xorg-x11-6.8.99.15.
*** Bug 99837 has been marked as a duplicate of this bug. ***
I'm running Gentoo and I confirm the bug in Wine 20050111 and 20050628. Haven't tried with recent versions of wine. I cannot downgrade XOrg-X11 for my graphics card is Intel 915GM, which is only supported in XOrg >6.8.2.
For me, 6.8.2-r2 has the bug, but 6.8.2-r1 is OK, so try the r1 version. BillK
To Vince C: you don't have to install < 6.8.2 but 6.8.2-r1 (not last that's r2). Try it!
*** Bug 100819 has been marked as a duplicate of this bug. ***
*** Bug 100939 has been marked as a duplicate of this bug. ***
Excluding the 9914_all_6.8.2-mmx-gcc4.patch from xorg-x11-6.8.2-r2 seems to solve the problem. Versions 6.8.99* cannot be fixed this way, as said in comment #27. But why not fix the 6.8.2 series?
*** Bug 101228 has been marked as a duplicate of this bug. ***
I can confirm the bug is also on AMD64, not only on x86. My system is up-to-date as of 03. August 2005.
*** Bug 102579 has been marked as a duplicate of this bug. ***
Please build a antipatch into ebuilds so the 9914 "mmx gcc4"-patch is removed by gentoo. Perhaps it has to be an option, i dont know what patch 9914 really does and why it could fail.
I dont understand why xorg-x11-6.8.2-r2 is marked as stable. With bugs as ugly as this one it should go to unstable (and -r1 to stable) This is a "cosmetic" bug, so one would say it isnt important enough and r2 can be marked stable... but we're talking about xorg, xorg's job is to show all graphics in the screen, in a proper manner, and if that isnt done right thats very bad and shouldn't be ignored...
(In reply to comment #41) > I dont understand why xorg-x11-6.8.2-r2 is marked as stable. With bugs as ugly > as this one it should go to unstable (and -r1 to stable) Since it doesn't seem clear enough from the other comments, I'll try to clarify here. This patch has been applied upstream and hence is now officially a part of xorg. Us adding it and marking it stable actually makes us compliant with the next official release of xorg, unless they get it fixed before that release. I don't know the necessity of the patch, but it appears to be a gcc4 compatibility move and could even be more than that. If you want this fixed faster you can watch the upstream bug and give input when necessary.
*** Bug 103514 has been marked as a duplicate of this bug. ***
Well ther are a lot of specifice gentoo patches, can't see why we could not have a USE flag based antipatch for this bug until freedesktop solves it. We are at -r3 and the problem is still there.
Indeed it is, because -r3 was a bump for a security vulnerability.
Ok, but why not adding to the ebuild a simple: patch_exclude 9914_all_6.8.2-mmx-gcc4.patch in the patch_setup() section of the ebuild. Maybe a good idea is making it controlled by a use flag... I'm trying this solution now, on the forum reported it's working. As said the same patch had been excluded from cvs version but problem is still there, in 6.8.2 version instead removing that patch seems solving the problem...
Because that breaks the build with new gcc. The patch is part of CVS, so excluding it doesn't make any sense.
Would stable users even be using the new gcc? I'm not seeing the logic in keeping that patch there in stable xorg-x11.
Well I was thinking to be crazy! A user who use stable sw doesn't mind about that patch and I'm sure he would prefer to have Openoffice and any Wine application working in a good way. Using this patch we are in the situation that not only icons (this is a minor but annoying trouble) but also transparent images can't be viewed correctly. A Impress presentation, a Calc spreadsheet... etc... if there's a transparent image we get black background. That's a priority against user who use gcc 4.0 (just tester I think, they know that that patch is needed and could reapply it). I'm wrong to you?
(In reply to comment #48) > Would stable users even be using the new gcc? I'm not seeing the logic in keeping that patch there in > stable xorg-x11. Everybody not using hard-masked xorg gets 6.8.2.
> Everybody not using hard-masked xorg gets 6.8.2. right, and thats broken! we need a gcc4 useflag, and if this useflag isnt set - the xorg ebuilds for 6.8.2 should not perform the patch for gcc4 - the newer ebuilds should perform a antipatch (because the problem is inside xorg-cvs allready) solve this problem, people that run a stable-system shouldnt patch xorg!
*** Bug 105929 has been marked as a duplicate of this bug. ***
Hello, I know this is set as UPSTREAM however I had new info that I am not really sure is related to this. I have a system at work, and after upgrading to 6.8.2-r3 as the GLSA says, I get what seem to be similar problems with rdesktop-1.4.1. rdesktop is a terminal services application, used for connecting to Windows terminal services. After the upgrade, when I connect to a server, and then run putty and log into a system, my normally green cursor quickly turns black. When I type, it leaves a trail of black on black boxes in place of it, masking my typing entirely. If i press CTL-L it refreshes the screen and I can see what I have typed. If I continue to type, the previous text is readble, but it begins to leave black boxes again. This is not easy to understand, so I have created a very small video. It is mpeg4. I will attach this. I would get the emerge info on this sytem, however, it is off and I am away from work right now. In the past on this system, I had tried a masked version of xorg. 6.8.99.14 I believe. I had this exact same problem, and had to go back to 6.8.2-r1 , just like the folks here. Now that 6.8.2-r3 is installed due to a GLSA, I don't know what to do except wait. Hope this helps.
Created an attachment (id=68667) [edit] small (180KB) mpeg4 video showing these black boxes. When I am not capturing the video, the black boxes are continuous, and NOT broken.
FYI, a much better way to be excluding this patch is to add a line to patch_setup() in the ebuild and keep a copy in your overlay. This way you can benefit from the latest security fixes and such. However, we would much prefer that anyone who understands the code in the patch find the problem and fix it. Because the code is in CVS the next Xorg release *will* contain this patch by default.
I am a little bit unhappy that the last working version xorg-x11-6.8.2-r1 isn't in the tree anymore.
Security policy, most likely. Since -r1 contains a security problem, it gets removed as quickly as possible.
Hi there, the problem persists with xorg-x11-6.8.2-r4... :(
can anyone confirm this problem doesnt occur in combination with gcc4?
As some people have mentioned, you can modify the ebuild yourself to get over the problem. Just in case you can't figure it out, here's a quick howto. This information probably all exists somewhere else, but in case you haven't found it out yet: 1. emerge --sync first, so you have the xorg-x11-6.8.2-r4 ebuild available. 2. In /etc/make.conf, add the line "PORTDIR_OVERLAY=/usr/local/portage" 3. make the following directories: "/usr/local/portage/x11-base/xorg-x11/files/" 4. from /usr/portage/x11-base/xorg-x11 copy "Manifest", "xorg-x11-6.8.2-r4.ebuild", and "files/digest-xorg-x11-6.8.2-r4" to the same structure in /usr/local/portage 5. delete from /usr/local/portage/Manifest the line containing xorg-x11-6.8.99.15-r2 and digest-xorg-x11-6.8.99.15-r2 6. edit /usr/local/portage/xorg-x11-6.8.2-r4.ebuild so that in the function patch_setup, you have the line "patch_exclude 9914_all_6.8.2-mmx-gcc4", eg: ... patch_setup() { einfo "Excluding patches..." # This patch breaks transparancy in openoffice, rdesktop, and # others... Added by Iain Buchanan to local portage overlay. patch_exclude 9914_all_6.8.2-mmx-gcc4 .. 7. `emerge -pv xorg-x11` and you shoud see an "R" if you've already emerged 6.8.2-r4, or a "U" if you haven't yet; followed by a "[1]". Note the reference at the end to /usr/local/portage: $ emerge -pv xorg-x11 These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] x11-base/xorg-x11-6.8.2-r4 -3dfx -3dnow +bitmap-fonts -cjk -debug -dlloader -dmx -doc -font-server -insecure-drivers +ipv6 -minimal +mmx +nls -nocxx +opengl +pam -sdk +sse -static +truetype-fonts +type1-fonts (-uclibc) -xprint +xv 0 kB [1] Total size of downloads: 0 kB Portage overlays: [1] /usr/local/portage That's it! Sorry for the long post, but these are the steps I used to get 6.8.2-r4 _without_ the transparancy problem. I've been using it for a few days now and its as stable as it was before, standard disclaimer applies ;) HTH.
why has this bug status resolved upstream? Real gentoo users are expected to have their own portage overlay ;-) ?
Come on guys, this is getting a teeny bit absurd, don't you think. Now Gentoo no longer provides an X-server AMD64 users can employ unless they are willing to stop using OpenOffice, Wine and maybe other programs (or decide to learn the position of all icons by heart, because those are no longer readable with the current server version). All this because the maintainers reject to remove the one patch which has already been identified months ago as the culprit. The arguments put up in favor of keeping the patch are weak at best: 1) It's in CVS I always though that Version x-r2 meant that it is version x with fixes included for bugs discovered in the mean time. Not that it is version x with all the _bugs_ included which were introduced into newer versions in the mean time. 2) This is the only way to get someone look at the code to find the bug. I always thought that's what unstable versions are for. Oh and not everybody is really into debugging windowing systems, yet everybody now has to live with the bug. 3) But you just have to create an overlay, copy files around, edit them, .... This is supposed to be the stable version, for heavens sake. So, since I downgraded everything early enough to r1 (while it was still available) I now have the choice of adding an overlay (thanks to Iain for the detailed explanation) or staying with an insecure X-server. Is this going to become the norm for using ebuilds from the stable Gentoo branch? Then please tell me now already. BTW, as has been demonstrated by reply #60 this is a problem of the local ebuild not of the upstream. Classification RESOLVED UPSTREAM is therefore wrong.
Emerge info for the system in comment #53 Portage 2.0.51.22-r1 (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.4.20041006-r0, 2.6.13-mm3 i686) ================================================================= System uname: 2.6.13-mm3 i686 Pentium III (Katmai) Gentoo Base System version 1.12.0_pre6 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [enabled] dev-lang/python: 2.2.3-r1, 2.3.4-r1, 2.4.1-r1 sys-apps/sandbox: 1.2.11 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9, 1.8.5-r2, 1.9.6 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.4.19 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium3 -mtune=pentium3 -O2 -pipe" CHOST="i686-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/lib/mozilla/defaults/pref /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium3 -mtune=pentium3 -O2 -pipe" DISTDIR="/var/portage/distfiles" FEATURES="autoconfig buildpkg ccache distlocks notitles sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.osuosl.org/ http://adelie.polymtl.ca/ ftp://cs.ubishops.ca/pub/gentoo ftp://gentoo.risq.qc.ca/ ftp://distro.ibiblio.org/pub/linux/distributions/gentoo/" MAKEOPTS="-j2" PKGDIR="/var/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/var/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="x86 X apache2 apm avi berkdb bitmap-fonts cdr chroot crypt cscope cups curl dvdr eds emboss encode esd fam flac foomaticdb fortran gd gdbm gif gnome gpm gstreamer gtk gtk2 imagemagick imlib java jpeg kde kerberos libg++ libwww mad mikmod mmx motif mozilla mp3 mpeg mysql ncurses nls ogg oggvorbis opengl oss pam pdflib perl png python qt quicktime readline samba sdl slang snmp spell sse ssl svga tcltk tcpd tiff truetype truetype-fonts type1-fonts vorbis xml xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
*** Bug 106831 has been marked as a duplicate of this bug. ***
(In reply to comment #62) > BTW, as has been demonstrated by reply #60 this is a problem of the local > ebuild not of the upstream. Classification RESOLVED UPSTREAM is therefore > wrong. Not true, you're getting it all wrong. Comment 42 explicitely states, and I quote: This patch has been applied upstream and hence is now officially a part of xorg. Us adding it and marking it stable actually makes us compliant with the next official release of xorg, unless they get it fixed before that release. -- Joshua Baergen in Gentoo Bug #96053 To me, it says two things: 1) Without the patch, Gentoo will not be compliant with the next official release of xorg (oh no, don't want that), and 2) If [upstream] don't get it fixed until release, darkness will be declared the new standard. The really sad thing is, this is history repeating: In Bug #49455 somebody questioned the assumption that every Fedora patch on earth should be imported into Gentoo, even those highly Red Hat specific stuffs that did not solve any existing Gentoo problem but instead caused nothing but headaches. But, since devs under the x11@g.o alias wouldn't be where they are today without their superiour X knowledge / coding skills, I'm sure they'll come up with somehing in due time. It's really not that hard, maybe 10-15 minutes with the broken patch or 0 with a simple workaround or without the patch.
Has someone actually tried what happens with USE=-mmx and/or USE=-sse? Does that work, and which one of the combinations then works? Also does someone have any idea where in the patch one should start looking. I'm quite unfamiliar with Xorg and the patch is quite sizeable. Knowing which function is the culprit would narrow the search considerably.
*** Bug 106959 has been marked as a duplicate of this bug. ***
According to duplicate bug in comment #67, it's 9914_all_6.8.2-mmx-gcc4.patch which causes the problem. Did not test, someone give it a try.
I confirm that without this patch all work fine and no black box anymore
We know it's this patch. But it's quite a big patch. I was wondering if someone had taken the effort to find out where in the patch the problem lies.
(In reply to comment #66) > Also does someone have any idea where in the patch one should start looking. The patch re-defines some MMX assembly functions and seems to unify the naming structure to better represent 64-bit objects. There are also a couple new functions added. My guess is the problem lies in the new functions, but I've reviewed the code twice and haven't seen anything (you're right, it's a lot of code). There are a few things I don't perfectly understand, which doesn't help. If you want to look, start in functions related to 'alpha' and 'composite', since those are generally related to transparency.
After looking at 9914_all_6.8.2-mmx-gcc4.patch, I removed the changes to fbpict.c and that made no difference. Then I removed the changes it makes to fbcopy and that seemed to fix the problem. I'm using gcc 3.4.4, CFLAGS="-O3 -march=pentium4 -fomit-frame-pointer -pipe", and mmx and sse USE flags for xorg-x11.
(In reply to comment #72) > Then I removed the changes it makes to fbcopy and that seemed to fix > the problem. But that does not fix everything, you're just not using MMX in direct copies, but the bug still shows if other ROPs are being used. And the patch may not be compliant with the next X11 release anymore :) (could someone in the know please explain what that means?) Man without socks, why don't you attach your modifications here? It seems they fix the problem and give a higher throughput with all XCopyArea functions? Mind if I do?
(In reply to comment #73) > Man without socks, why don't you attach your modifications here? I won't, for the following reasons: 1) In #49455, two core devs advised me not to contribute any code to Gentoo. 2) The general consensus in a thread named "org-x11 GLSA 200509-07. Is bug #96053 fixed in -r3? (black icons)" (08/13/05, gentoo-security) seemed to be that users that don't like that breakage are supposed to run their own ebuilds. 3) Gentoo is greedy. The version I'm using here requires heav modifications to the ebuild. If you look at the headers, the guy who fixed it added his own and his company's copyright notice right there in the header (and since I paid for it, mine too). According to http://dev.gentoo.org/~ciaranm/docs/mw-faq/header.txt that's, although it's general practice, not acceptable for Gentoo. He also used 3 spaces for indentation rather than tabs. Result: there will be a working ebuild in bugzilla, people will be unhappy, start wondering why it's not being used, revolts will happen, uprising, revolution, the end of Gentoo as we know it today. Of course you are free to do everything you want with it as long as it's in accordance with GPL-2. That means you are allowed to attach it here.
(In reply to comment #73) > But that does not fix everything, you're just not using MMX in direct > copies, but the bug still shows if other ROPs are being used. And the > patch may not be compliant with the next X11 release anymore :) The reason why I mentioned it was to suggest that since the new function: fbCopyAreammx doesn't use any of the other MMX functions, it may be a bug in fbCopyAreammx that is causing the problems with OpenOffice icons and Wine (at least on my system). Also, I forgot to mention that I am using the binary Nvidia driver.
(In reply to comment #75) > The reason why I mentioned it was to suggest that since the new function: > fbCopyAreammx doesn't use any of the other MMX functions, it may be a bug in > fbCopyAreammx that is causing the problems with OpenOffice icons and Wine (at > least on my system). > Although after looking at the code a bit more, I'm not so sure now.
Same problem here. Bartron, could you please have a look?
One question... `9914_all_6.8.2-mmx-gcc4.patch' appears to be missing some bits. According to [1] there should be a newer `fbmmx.c' from May 2005 that fixes `fbCompositeSrc_8888x8x8888mmx()', however, diff headers in above patch appear to be as old as February 2005. And indeed, `fbCompositeSrc_8888x8x8888mmx()' as it is does not work correctly... 1. vs7 is copied from src pixmap rather than dst. 2. results are nicely packed into vd0..vd7, but never make their way into the destination pixmap, just as described in [1]. Result being, only odd bits at the start and end of each scanline are actually copied to dst. However... the problem with oo appears to be in XCopyArea() if src and dst drawables are both pixmaps (also exhibited in BlitSpin screensaver... more info shortly...) References: [1] https://bugs.freedesktop.org/show_bug.cgi?id=3781#c6
Created an attachment (id=69594) [edit] diff1.patch
Created an attachment (id=69594) [edit] diff1.patch fbCompositeSrc_8888x8x8888mmx fix, for completenes.
Problem exhibited in oo is, `fbCopyAreammx()' (MMX replacement for `fbBlt()') is a lot less capable than `fbBlt()', specifically, it does not honor gc attributes (`logical function') like it should.
Created an attachment (id=69596) [edit] nice test
Created an attachment (id=69596) [edit] nice test Here's a small program that demonstrates the problem... includes two screenshots taken with working and broken fb driver.
Depending on how attached you are to `9914_all_6.8.2-mmx-gcc4.patch' I'd suggest, in order of preference, 1. find out if there's a more recent, better version of said patch. 2. drop patch altogether. 3. restrict `fbCopyAreammx()' usage even more so it's only used for `GXcopy' operations.
Created an attachment (id=69597) [edit] diff2.patch Fastest possible fix... only use `fbCopyAreammx()' for `GXcopy'. Untested, no warranties.
As stated in a couple places, this issue affects CVS head (I'm running modular with the problem). Any fixes and suggestions you have should go in the upstream bug for review and inclusion. If someone can test bartron's fixes and post affirmative results upstream I'm sure it'll be included without too much fuss.
I can confirm that Bartron's fixes work fine for me. Wine and OpenOffice look good. xorg-6.8.2-r4 $ emerge --info Portage 2.0.51.22-r2 (default-linux/x86/2005.1, gcc-3.4.4, glibc-2.3.5.20050722-r0, 2.6.12- kaktyc5 i686) ============================================================ ===== System uname: 2.6.12-kaktyc5 i686 Celeron (Mendocino) Gentoo Base System version 1.6.13 ccache version 2.3 [enabled] dev-lang/python: 2.3.5, 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 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium2 -pipe -fomit-frame-pointer" CHOST="i686-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/bind /var/qmail/ control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-O2 -march=pentium2 -pipe -fomit-frame-pointer -fvisibility-inlines-hidden" DISTDIR="/home/distfiles/" FEATURES="autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://ftp.citkit.ru/pub/Linux/gentoo/ http://gentoo.osuosl.org" LANG="ru_RU.UTF-8" LDFLAGS="-Wl,-z,now -Wl,-O1 -Wl,--sort-common" LINGUAS="en" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 7zip X alsa apm arts avi bash-completion berkdb bitmap-fonts bluetooth cdparanoia cdr crypt css cups curl dbus dvd dvdr dvdread eds emboss encode fam fbcon flac foomaticdb fortran gdbm gif gpm gtk2 hal imagemagick imlib irmc java jpeg kde kdepim libg++ libwww mad mikmod mmap mmx motif mp3 mpeg musicbrainz ncurses nls nptl nptlonly ogg oggvorbis opengl pam pdflib perl pic png ppds python qt quicktime readline sdl slang sms spell sqlite ssl svga tcltk tcpd tetex theora tidy tiff truetype truetype-fonts type1-fonts unicode usb userlocales vorbis win32codecs xine xml2 xv zlib linguas_en userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LC_ALL, MAKEOPTS
So, is this "coming to an ebuild near you" soon, so I can take it out of my local tree? Because amd64 needs this fix. Just curious.
As soon as we can get a fix upstreamed, we'll be happy to add it.
Can't...resist...any...longer... In comment #84 Joshua Baergen said: > As stated in a couple places, this issue affects CVS head (I'm running > modular with the problem). Any fixes and suggestions you have should go in > the upstream bug for review and inclusion. In comment #87 Donnie Berkholz said: > As soon as we can get a fix upstreamed, we'll be happy to add it. My comment: Josh and Donny, As stated in a couple places, this is a *GENTOO* problem caused by inclusion of *BROKEN* *CVS HEAD*, i.e. *PRE-ALPHA* code into a *NON-BROKEN* *STABLE* version, 6.8.2. If *YOU* insist on using that patch -- that doesn't fix any real problem, mind you -- it is *YOUR* damn duty to fix any resulting problems. If you think upstream is so good at reviewing, why do you suppose *CVS HEAD* is still broken after all these months, or worse, they're still denying the problem even exists? My solution: Everyone on CC, unCC yourself. Bug reporter, change status to NOTABUG. Let's see how well they're doing if they're all alone..........
Lovely. So, if it's a Gentoo problem, rather than unCC-ing everyone and marking this NOTABUG (this is the Gentoo Bugzilla, not the XOrg Bugzilla) ... why don't we put the patch into portage for good and release an r5 of the ebuild?
Almost forgot, thanks for the thourough analysis and the *WORKING* patches, didn't mean to discourage the only person in here who actually knows what he's talking about.
> As stated in a couple places, this is a *GENTOO* problem caused by inclusion > of *BROKEN* *CVS HEAD*, i.e. *PRE-ALPHA* code into a *NON-BROKEN* *STABLE* > version, 6.8.2. If *YOU* insist on using that patch -- that doesn't fix any > real problem, mind you -- it is *YOUR* damn duty to fix any resulting problems. > If you think upstream is so good at reviewing, why do you suppose *CVS HEAD* > is still broken after all these months, or worse, they're still denying the > problem even exists? grow up. the patch was included to make building with gcc4 work. it fixed a real problem. that it introduced another one is upstream's fault, not gentoo's, and therefore the fix should be implemented upstream first. maintaining a large patch set in gentoo of code that is not in upstream is effectively forking X, and is wholly unmaintainable. (cf. debian) if you want to have a debate about what the expected role of the packager is in the development process, fine. however, bugzilla is not a forum, and is not the place for that discussion.
(In reply to comment #91) > > grow up. > > the patch was included to make building with gcc4 work. it fixed a real > problem. that it introduced another one is upstream's fault, not gentoo's, and > therefore the fix should be implemented upstream first. maintaining a large > patch set in gentoo of code that is not in upstream is effectively forking X, > and is wholly unmaintainable. (cf. debian) OK, then I'll chime in here. If this patch was included to fix the problems of a relatively small user-base (gcc4 folks), and it is causing a multitude of problems for the rest of the folks outside of this group, it the maintainers are refusing to remove it, then we already have a logic/triage problem. It seems a USE flag (or other means) should have been created to *selectively enable* the "special" patch for the relatively small user-base of the original problem. Wouldn't that make more sense than the mess this has turned into? > if you want to have a debate about what the expected role of the packager is in > the development process, fine. however, bugzilla is not a forum, and is not the > place for that discussion. No, bugzilla is the place where all of us have come to try and fix a *serious* usability problem with one of the most important business packages in the Gentoo tree. And we've sat here a long time waiting for someone to act like THEY CARE.
fixed in upstream. josh_b or spyderous, when you get a chance, please add bartron's patch to the ebuild.
Thanks Added to 6.8.2-r6. I'll add to 6.8.99.15 later today. Fix won't affect modular just yet. I'll keep 6.8.2-r5 in until I know nothing else gets broken.
I'd just like to give a big thanks to everyone who was patient and understanding during this. You're the people who make us want to work on open source instead of pushing us away from it.
Mr. Jackson, a little "THANK YOU" to the people who saved your ass would have gone a looong way, but since YOU instead choose to resort to PERSONAL ATTACKS against ME, please allow me to return that favor. First, my apologies to everyone else, and for comment #88, but without it we'd be still where we were the day before, NOWHERE. Unfortunaltely, if you look at all the bugs and mistakes made in 7.0-RC0, if they're fixed at the same rate as this one, my grandchildren (they're age 5-10 now) will be long dead until 7.0 reaches a usable state (if you'd been nice I may have told you more, but I'm afraid you'll have to find out yourself now). Firstly, if you plan to make an official statement, please make sure your SHIFT KEY is working. Writing in all lower case makes you look like some AOL kiddie trying to look cool (Which may be acceptable in private mail or on IRC, but not for what appears to be an official statement in the name of X.org). > grow up. Grow up yourself, eh? > the patch was included to make building with gcc4 work. That patch is a misnomer. Care to explain how man lines in it really address compilation issues with gcc4? Care to explain why additional fixes are needed for compilation with gcc4? > maintaining a large patch set in gentoo of code that is not in upstream > is effectively forking X, and is wholly unmaintainable. (cf. debian) I can only wonder why that is. Funny thing is, Debian's 6.9 packages are actually working, and did from the day they where made public. Please do not attack people who actually understand the code they're maintaining. > the Right Thing is to _always_ build all installed libraries with -fPIC, > shared or not. [...] that libtool and debian's shared library policy get > this wrong, just means that they're wrong. Ah, again attacking people who obviously have better knowledge than you. > i think i'm terrified that someone is actually using something besides > GXcopy though. And there goes our last bit of credibility. I think I'm terrified you are terrified that you think that. Welcome to the real world. Without GXcopy you are breaking more real productivity apps than you ever can imagine.
Sorry, meant *without everything but CXcopy*.
@Gordon please, could you show off your childish attitude in a different place? I don't think that the people who subscribed here are interested in useless complaints agaisnt the evil gentoo/X.org developers. For my part I'm removing myself from the bug, since it seems to be fixed. Thanks to bartram for the fix.
This fixed my problem with rdesktop (Comment #53), xorg-x11-6.8.99.15-r3 works great. Thanks a lot!
Now that things have cooled down a bit, I have one more question. Thomas, in Comment #82 you seem to imply that option 3 (fbCopyAreammx() only for GXcopy) is your least favored option. IIRC you told me it was only a quick hack for fixing the OpenOffice breakage, but you don't really like it yourself (forgot the exact reasons)... If you have a bit more time, are there any remaining issues we need to be aware of?
Well, in fact there are a few minor details that still need to be addressed, but I think that should go in a new bug. But first, everyone, is it safe to assume that all major applications are working correctly now? I've seen confirmations for OpenOffice, Wine, and Rdesktop... I believe someone somewhere mentioned another one I don't use myself (scribus, dia?) Now the technical part... According to the specs, `XCopyArea()' must use the following GC attributes: function, plane_mask, subwindow_mode, graphics_exposures, clip_x_origin, clip_y_origin, and clip_mask. `function' is working now, which leaves `plane_mask'. The easiest fix would be to calculate the relevant bits used in a particular depth and check if they are all set, and if not fall back to `fbBlt()' once more. What I personally don't like from a performance point of view, all these tests are done unnecessarily over and over again inside the `nbox' loop. Currently it checks for `alu', `reverse', `upsidedown', `fbHaveMMX()', now `plane_mask'... additionally `fbCopyAreammx()' will return FALSE and fallback to `fbBlt()' for depths other than 16 or 32 (why?), again for every single box, all in all unnecessarily penalizing users on 8-bit displays, who probably won't be using the fastes machines in the first place. (To speed things up a bit, could someone in touch with xorg upstream find out why things are done that way? Are there plans to add some of the missing functionality to `fbCopyAreammx()' itself? Do you prefer a local patch that at least restores the X11-spec conformance bit in 6.8.2?)
I'm sure you have put a lot of thought into this (like you always do), but what I don't understand, shouldn't nbox always be 1 for pixmaps (I mean there can't be obscured areas like in onscreen windows). What about clip_mask? The MMX copy routine does not seem to consider that. Or am I missing something?
Created an attachment (id=70989) [edit] planemask.pngplanemask.png [Marten, new bug?] Regions. Internally, clip masks are represented as regions. On the client side, a Region is just some opaque data type, but on the inside they're a bunch of rectangles, describing the visible (unclipped) part of all drawing operations. In case of XCopyArea(), these exact rectangles that are the source for what ends up in `pbox' and `nbox'. The attached screenshot is from a modified version of the earlier demo program modified so it 1. sets a plane_mask that clips off all blue components. 2. sets a circular clip_mask It demonstrates 2 things, 1. the GXCopy square is ignoring plane_mask 2. with a complex region like this, there are quite a few boxes
You can get in touch with upstream yourself :) Either get on to the xorg ml (xorg@lists.freedesktop.org, not sure about the sign-up site) or file a bug upstream. The ml will probably get a bit more discussion.
So...did anybody actually do get in touch with upstream about this? It's definitely still broken in latest 6.8.2 (#110951 may be related). Bartron, could you please look into this again? (I know you're very busy with higher priority stuff, but with your knowledge of X internals I think you're more qualified to do this than I am. I'm a bit confused about 7.0rc1, even though fbcopy.c is still the same, the problem does not show with current modular ebuilds, although it does so with experimental packages in other distributions.)
???? Shot in the dark, there's a well known bug in RC1 that snuck in just before release in `configure.ac' that causes the `mmx_capable' test to always fail. In line 259, it checks for (__GNUC__ = 3 && __GNUC_MINOR__ < 4) (should be `__GNUC__ == 3'... '=' is not a valid C preprocessor token)... which means MMX specific code is not compiled in even when using gcc 3.4 or 4. Perhaps that other distribution has fixed `configure.ac' and Gentoo has not, that seems like an explanation. I'll look into the other problem.
???? The `mmx_capable' issue is fdo bug #4817 https://bugs.freedesktop.org/show_bug.cgi?id=4817 and was corrected upstream 20 October 2005. It does not appear to be in Gentoo yet, but now that RC2 is about to be released, it should be autofixed once RC2 ebuilds are available (only affects modular RC1...) The `fbcopy.c'/plane_mask issue is already corrected in fdo CVS as of 4 days ago (this one still needs to go into 6.8.2).
Sure does. Could someone do me a huge favour and create a bug on our bugzilla with the fbcopy fix? I have a few things yet that need to go into 6.8.2, and would like this on the list.
I of course mean the plane_mask issue, not the old one :P Btw, if anyone's still have transparency issues, you're likely not using the latest (~-masked) version of X...
(In reply to comment #109) > Btw, if anyone's still have transparency issues, you're likely not using the > latest (~-masked) version of X... Exactly, it's been more than 4 months since there's been a working, non-masked version of X in Gentoo, and that's what many users around here start to consider a weeee bit ridiculous. Could you please put your obvious personal feud with the patch submitter aside and stop taking it out on your whole user base? The net damage you've done so far is this issue has been covered in our local LUG's monthly publication for the 4th time in a row, and as a result Gentoo dropped on their monthly polularity poll from 3rd place in July to 19th place in September and fell off the Top 25 in October and November. Is that what you want? Please stop this madness NOW! Thank you.
The fact that your LUG apparently hates Gentoo because some icons show up black in openoffice is rather sad.
Amongst all the frankly rather sickening mudslinging, I am unable to tell whether this has been fixed or not. Please can someone confirm for me: is this fixed in 6.8.2-r6? I don't want to waste an hour and a half upgrading xorg for no reason.
Im using xorg 6.8.2-r6 with openoffice-bin (2.0.1) and it does not have the problem anymore.
Ok, I can confirm that 6.8.2-r6 does seem to fix this. Thanks.
Actually, it's half-fixed. ROP2 is fixed and only took a really long time and an extra nudge to go stable. Plane mask is still broken.
