Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 96053 - OpenOffice doesn't display transparencies since update
Summary: OpenOffice doesn't display transparencies since update
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: x86 Linux
: Normal normal (vote)
Assignee: Gentoo X packagers
URL: https://bugs.freedesktop.org/show_bug...
Whiteboard:
Keywords:
: 96153 96244 99837 100819 100939 101228 102579 103514 105929 106831 xorg-x11_black_box (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-06-14 03:38 UTC by Borja Pacheco
Modified: 2006-01-05 17:23 UTC (History)
37 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Image showing how OpenOffice displays icons (Pantallazo.png,94.66 KB, image/png)
2005-06-14 03:39 UTC, Borja Pacheco
Details
Screenshot of Wine (wine.jpg,439.28 KB, image/jpeg)
2005-06-27 04:42 UTC, Giacomo Perale
Details
small (180KB) mpeg4 video showing these black boxes. (rdesktop_errors.mpeg,170.71 KB, application/octet-stream)
2005-09-17 06:21 UTC, FieldySnuts
Details
diff1.patch (diff1.patch,1006 bytes, patch)
2005-09-30 17:07 UTC, bartron
Details | Diff
nice test (bug-96053.tar.gz,15.68 KB, application/x-gtar)
2005-09-30 17:21 UTC, bartron
Details
diff2.patch (diff2.patch,310 bytes, patch)
2005-09-30 17:23 UTC, bartron
Details | Diff
planemask.pngplanemask.png (planemask.png,17.37 KB, image/png)
2005-10-18 18:35 UTC, bartron
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Borja Pacheco 2005-06-14 03:38:11 UTC
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"
Comment 1 Borja Pacheco 2005-06-14 03:39:23 UTC
Created attachment 61195 [details]
Image showing how OpenOffice displays icons
Comment 2 Andreas Proschofsky (RETIRED) gentoo-dev 2005-06-14 06:27:40 UTC
which packages did you update before the problem occured?
Comment 3 Borja Pacheco 2005-06-14 07:13:11 UTC
(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')
Comment 4 Andreas Proschofsky (RETIRED) gentoo-dev 2005-06-14 07:18:29 UTC
"No idea" is no good basis for identifying problems... Check /var/log/emerge.log
the info should be in there
Comment 5 Borja Pacheco 2005-06-14 07:29:23 UTC
(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 /
Comment 6 Borja Pacheco 2005-06-14 07:32:55 UTC
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?
Comment 7 Paul de Vrieze (RETIRED) gentoo-dev 2005-06-14 12:41:35 UTC
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.
Comment 8 Paul de Vrieze (RETIRED) gentoo-dev 2005-06-14 12:42:44 UTC
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
Comment 9 Borja Pacheco 2005-06-14 23:28:42 UTC
(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.
Comment 10 Borja Pacheco 2005-06-15 01:16:09 UTC
(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)

Comment 11 Andreas Proschofsky (RETIRED) gentoo-dev 2005-06-16 00:01:33 UTC
*** Bug 96244 has been marked as a duplicate of this bug. ***
Comment 12 Gleb Litvjak 2005-06-16 03:40:08 UTC
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. 
Comment 13 Joshua Baergen (RETIRED) gentoo-dev 2005-06-17 13:33:42 UTC
*** Bug 96153 has been marked as a duplicate of this bug. ***
Comment 14 Giacomo Perale 2005-06-22 17:01:40 UTC
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
Comment 15 Donnie Berkholz (RETIRED) gentoo-dev 2005-06-24 16:19:13 UTC
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.
Comment 16 Joshua Baergen (RETIRED) gentoo-dev 2005-06-24 18:16:52 UTC
I can confirm this problem using ATI binaries.
Comment 17 Kenyon Ralph 2005-06-24 18:33:28 UTC
I'm on Nvidia with this problem.
Comment 18 Paul de Vrieze (RETIRED) gentoo-dev 2005-06-26 06:56:12 UTC
I'm using the radeon driver (with the problem)
Comment 19 Giacomo Perale 2005-06-27 04:42:37 UTC
Created attachment 62043 [details]
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.
Comment 20 Lukasz Goralczyk 2005-07-04 04:29:09 UTC
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. 
Comment 21 Otártics András 2005-07-04 16:24:54 UTC
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)
Comment 22 Otártics András 2005-07-04 16:35:56 UTC
Hi again!

 Actually, c1c1c1 will be the best ...

With regards, 
                         Semir
Comment 23 Bill Kenworthy 2005-07-11 07:38:12 UTC
Is there any further info on this?  How do we fix it?
Comment 24 Giacomo Perale 2005-07-14 04:01:16 UTC
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.
Comment 25 Donnie Berkholz (RETIRED) gentoo-dev 2005-07-14 12:10:49 UTC
Yes, it's been applied to upstream CVS. Please file a bug at
bugs.freedesktop.org and post the URL here.

Thanks!
Comment 26 Giacomo Perale 2005-07-14 12:56:30 UTC
https://bugs.freedesktop.org/show_bug.cgi?id=3781
Comment 27 Joël 2005-07-20 04:47:51 UTC
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 ?
Comment 28 Donnie Berkholz (RETIRED) gentoo-dev 2005-07-20 10:15:33 UTC
You would know this if you read comments #24 and #25.
Comment 29 Mark Krischer 2005-07-20 19:55:21 UTC
in case anyone is wondering, the problem still exists with
x11-base/xorg-x11-6.8.99.15.
Comment 30 Jakub Moc (RETIRED) gentoo-dev 2005-07-21 14:21:35 UTC
*** Bug 99837 has been marked as a duplicate of this bug. ***
Comment 31 Vince C. 2005-07-26 15:03:08 UTC
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.
Comment 32 Bill Kenworthy 2005-07-26 15:52:33 UTC
For me, 6.8.2-r2 has the bug, but 6.8.2-r1 is OK, so try the r1 version.

BillK
Comment 33 Francesco 2005-07-26 16:03:48 UTC
To Vince C: you don't have to install < 6.8.2 but 6.8.2-r1 (not last that's 
r2). Try it! 
Comment 34 Andreas Proschofsky (RETIRED) gentoo-dev 2005-07-30 23:43:33 UTC
*** Bug 100819 has been marked as a duplicate of this bug. ***
Comment 35 Herbie Hopkins (RETIRED) gentoo-dev 2005-07-31 15:48:32 UTC
*** Bug 100939 has been marked as a duplicate of this bug. ***
Comment 36 Paweł Hajdan, Jr. (RETIRED) gentoo-dev 2005-08-03 09:54:29 UTC
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?
Comment 37 Jakub Moc (RETIRED) gentoo-dev 2005-08-03 10:38:14 UTC
*** Bug 101228 has been marked as a duplicate of this bug. ***
Comment 38 Karsten Becker 2005-08-04 03:01:04 UTC
I can confirm the bug is also on AMD64, not only on x86. My system is up-to-date
as of 03. August 2005.
Comment 39 Sven 2005-08-15 00:03:44 UTC
*** Bug 102579 has been marked as a duplicate of this bug. ***
Comment 40 Sven 2005-08-15 00:06:31 UTC
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.
Comment 41 Sérgio Luís 2005-08-16 17:13:15 UTC
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...
Comment 42 Joshua Baergen (RETIRED) gentoo-dev 2005-08-16 19:59:30 UTC
(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.

Comment 43 Jakub Moc (RETIRED) gentoo-dev 2005-08-23 16:40:10 UTC
*** Bug 103514 has been marked as a duplicate of this bug. ***
Comment 44 Francesco 2005-09-13 05:31:23 UTC
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.  
  
Comment 45 Donnie Berkholz (RETIRED) gentoo-dev 2005-09-13 05:33:05 UTC
Indeed it is, because -r3 was a bump for a security vulnerability.
Comment 46 Francesco 2005-09-13 09:35:12 UTC
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... 
Comment 47 Donnie Berkholz (RETIRED) gentoo-dev 2005-09-13 10:34:28 UTC
Because that breaks the build with new gcc. The patch is part of CVS, so
excluding it doesn't make any sense.
Comment 48 Tom Kiermaier 2005-09-13 14:01:09 UTC
Would stable users even be using the new gcc? I'm not seeing the logic in keeping that patch there in 
stable xorg-x11.
Comment 49 Francesco 2005-09-13 15:30:28 UTC
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? 
Comment 50 Donnie Berkholz (RETIRED) gentoo-dev 2005-09-13 15:42:15 UTC
(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.
Comment 51 Sven 2005-09-13 23:02:36 UTC
> 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!

Comment 52 Astrid Malo 2005-09-14 00:11:42 UTC
*** Bug 105929 has been marked as a duplicate of this bug. ***
Comment 53 FieldySnuts 2005-09-17 06:20:10 UTC
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.
Comment 54 FieldySnuts 2005-09-17 06:21:24 UTC
Created attachment 68667 [details]
small (180KB) mpeg4 video showing these black boxes.

When I am not capturing the video, the black boxes are continuous, and NOT
broken.
Comment 55 Joshua Baergen (RETIRED) gentoo-dev 2005-09-17 08:17:09 UTC
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.
Comment 56 Rene Zbinden 2005-09-18 04:18:11 UTC
I am a little bit unhappy that the last working version xorg-x11-6.8.2-r1 isn't
in  the tree anymore.
Comment 57 Sebastian Redl 2005-09-18 05:47:03 UTC
Security policy, most likely. Since -r1 contains a security problem, it gets
removed as quickly as possible.
Comment 58 Mustafa Mesanovic 2005-09-19 06:14:58 UTC
Hi there, the problem persists with xorg-x11-6.8.2-r4... :(
Comment 59 Sven 2005-09-19 10:51:43 UTC
can anyone confirm this problem doesnt occur in combination with gcc4?
Comment 60 Iain Buchanan 2005-09-19 18:12:52 UTC
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.
Comment 61 Fritz Heinrichmeyer 2005-09-20 00:13:31 UTC
why has this bug status resolved upstream?
Real gentoo users are expected to have their own portage overlay ;-) ?
Comment 62 Markus Baumeister 2005-09-21 12:42:05 UTC
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.
Comment 63 FieldySnuts 2005-09-21 12:56:09 UTC
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
Comment 64 Jakub Moc (RETIRED) gentoo-dev 2005-09-21 13:43:20 UTC
*** Bug 106831 has been marked as a duplicate of this bug. ***
Comment 65 MaN w1tHoUt SoCkS 2005-09-21 17:11:22 UTC
(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.
Comment 66 Paul de Vrieze (RETIRED) gentoo-dev 2005-09-22 01:42:40 UTC
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.
Comment 67 Jakub Moc (RETIRED) gentoo-dev 2005-09-23 01:52:49 UTC
*** Bug 106959 has been marked as a duplicate of this bug. ***
Comment 68 Jakub Moc (RETIRED) gentoo-dev 2005-09-23 01:54:07 UTC
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. 
Comment 69 Bachelier Vincent 2005-09-23 02:10:53 UTC
I confirm that without this patch all work fine and no black box anymore
Comment 70 Paul de Vrieze (RETIRED) gentoo-dev 2005-09-23 02:20:29 UTC
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.
Comment 71 Joshua Baergen (RETIRED) gentoo-dev 2005-09-23 08:05:05 UTC
(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.
Comment 72 Matthew Stapleton 2005-09-25 07:11:05 UTC
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. 
Comment 73 Johan S. Murf 2005-09-25 17:28:30 UTC
(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?
Comment 74 MaN w1tHoUt SoCkS 2005-09-25 17:52:06 UTC
(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.
Comment 75 Matthew Stapleton 2005-09-26 00:58:06 UTC
(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. 
 
Comment 76 Matthew Stapleton 2005-09-26 01:38:41 UTC
(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. 
Comment 77 Martin Flugeldufel 2005-09-30 16:47:08 UTC
Same problem here.

Bartron, could you please have a look?
Comment 78 bartron 2005-09-30 17:05:24 UTC

    
Comment 79 bartron 2005-09-30 17:05:24 UTC
  
  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

Comment 80 bartron 2005-09-30 17:07:26 UTC
Created attachment 69594 [details, diff]
diff1.patch
Comment 81 bartron 2005-09-30 17:07:26 UTC
Created attachment 69594 [details, diff]
diff1.patch

  
  fbCompositeSrc_8888x8x8888mmx fix, for completenes.
Comment 82 bartron 2005-09-30 17:20:10 UTC

    
Comment 83 bartron 2005-09-30 17:20:10 UTC
  
  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.

Comment 84 bartron 2005-09-30 17:21:38 UTC
Created attachment 69596 [details]
nice test
Comment 85 bartron 2005-09-30 17:21:38 UTC
Created attachment 69596 [details]
nice test

  
  Here's a small program that demonstrates the problem... includes two 
screenshots taken with working and broken fb driver.
Comment 86 bartron 2005-09-30 17:22:47 UTC
  
  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.

Comment 87 bartron 2005-09-30 17:23:45 UTC
Created attachment 69597 [details, diff]
diff2.patch

  
  Fastest possible fix... only use `fbCopyAreammx()' for `GXcopy'.
Untested, no warranties.
Comment 88 Joshua Baergen (RETIRED) gentoo-dev 2005-09-30 21:47:43 UTC
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.
Comment 89 Viktor Ashirov 2005-10-01 19:20:20 UTC
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
Comment 90 Joe Khoobyar 2005-10-01 21:12:23 UTC
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.
Comment 91 Donnie Berkholz (RETIRED) gentoo-dev 2005-10-01 21:27:53 UTC
As soon as we can get a fix upstreamed, we'll be happy to add it.
Comment 92 Gordon 2005-10-02 16:04:06 UTC
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..........
Comment 93 Joe Khoobyar 2005-10-02 22:00:36 UTC
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?  
Comment 94 Gordon 2005-10-02 22:29:51 UTC
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.
Comment 95 Adam Jackson 2005-10-03 00:24:44 UTC
> 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.
Comment 96 Greg Tassone 2005-10-03 02:44:23 UTC
(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.
Comment 97 Adam Jackson 2005-10-03 12:38:36 UTC
fixed in upstream.  josh_b or spyderous, when you get a chance, please add
bartron's patch to the ebuild.
Comment 98 Joshua Baergen (RETIRED) gentoo-dev 2005-10-03 12:54:04 UTC
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.
Comment 99 Donnie Berkholz (RETIRED) gentoo-dev 2005-10-03 13:10:24 UTC
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.
Comment 100 Gordon 2005-10-03 21:20:34 UTC
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.
Comment 101 Gordon 2005-10-03 21:22:04 UTC
Sorry, meant *without everything but CXcopy*.
Comment 102 Giacomo Perale 2005-10-04 05:03:12 UTC
@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.
Comment 103 FieldySnuts 2005-10-06 12:12:05 UTC
This fixed my problem with rdesktop (Comment #53), xorg-x11-6.8.99.15-r3 works
great.

Thanks a lot!
Comment 104 Martin Flugeldufel 2005-10-17 19:00:04 UTC
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?
Comment 105 bartron 2005-10-18 17:19:20 UTC
  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?)
Comment 106 Martin Flugeldufel 2005-10-18 17:47:42 UTC
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?
Comment 107 bartron 2005-10-18 18:35:38 UTC
Created attachment 70989 [details]
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
Comment 108 Joshua Baergen (RETIRED) gentoo-dev 2005-10-18 19:29:45 UTC
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.
Comment 109 Martin Flugeldufel 2005-11-08 17:37:04 UTC
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.)
Comment 110 bartron 2005-11-08 17:47:36 UTC
????
  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.
Comment 111 bartron 2005-11-08 17:55:36 UTC
  ????
  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).
Comment 112 Joshua Baergen (RETIRED) gentoo-dev 2005-11-08 21:42:20 UTC
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.
Comment 113 Joshua Baergen (RETIRED) gentoo-dev 2005-11-08 21:43:59 UTC
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...
Comment 114 Q. Fladen 2005-11-22 16:55:27 UTC

(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.
Comment 115 Donnie Berkholz (RETIRED) gentoo-dev 2005-11-22 17:07:11 UTC
The fact that your LUG apparently hates Gentoo because some icons show up black
in openoffice is rather sad.
Comment 116 Tom Harris 2006-01-04 04:20:07 UTC
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.
Comment 117 Dietrich Moerman 2006-01-04 08:33:09 UTC
Im using xorg 6.8.2-r6 with openoffice-bin (2.0.1) and it does not have the problem anymore.
Comment 118 Tom Harris 2006-01-04 12:29:01 UTC
Ok, I can confirm that 6.8.2-r6 does seem to fix this. Thanks.
Comment 119 Q. Fladen 2006-01-05 17:23:10 UTC
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.