Just wanted to post my progress, and see what others might be experiencing.

I have a radeon 9600xt using the xorg radeon driver in --current.

I upgraded my compiz to 0.8.4 and built the compiz fusion packages.

I'm not able to build the kde4 one's as I don't understand the build instruction's for cmake on this. This kde4 compiz fusion wasn't/isn't available for the 0.8.2 series compiz in Slackware proper, so that's why I upgraded my main compiz (plus fixes).

However, I do have compiz-fusion working splendid in XFCE tho.

It all works well, after I do:

xorg.conf:

add
device section gets:

# from here: http://wiki.compiz-fusion.org/ATI%20with%20AIGLX
xorg.conf:

Option "XAANoOffscreenPixmaps" "true"
Option "AccelMethod" "EXA"


and end of xorg.conf I added:

Section "Extensions"
Option "Composite" "Enable"
EndSection

Section "ServerFlags"
Option "AIGLX" "true"
EndSection

The only issues I have is using xrandr, the monitor on the right, has corrupted vertical bar about 3" but only in the wallpaper area, the task bar, and system tray, and clock are fine. So it appears compiz-fusion doesn't know what to do with the wallpaper.

On boxes that don't use xrandr I have no issue.

Aside from the wallpaper issue using xrandr, it's running pretty good here, no issues whatsoever. Even the emerald themes, and fusion-icon.

Has anyone else seen this issues? Do you have fusion working for kde4? Any random thoughts?

I am running compiz-fusion on current, however I use a nvidia card. The Kconfig backend source package doesn't work with the newest KDE. It should be fixed in the coming 0.9.0 release, but you don't need it to run compiz in KDE... I am running it with no problems right now. I have never setup CF with an ATI card so I can't be any help there.

Old_Fogie, your hardware has a maximum texture size of 2048. Anything single texture beyond 2048 pixels in height/width will be corrupted, including your xfce4 background. If you kill xfdesktop, and use the compiz wallpaper plugin, you probably wouldn't see this corruption (assuming you don't exceed the cards maximum 3D limitation of 2560).

The next version of compiz will have a copy mode (in addition to the currently used texture_from_pixmap mode) that won't use textures and will, therefore, work beyond that 2048 limitation (but not beyond the maximum 3D limitation, obviously).

EDIT: KDE4 (with compiz or with its own desktop effects) should not show this problem as plasma draws each background as a separate window, which gets converted to its own texture.

Adam

@daedra
- Is the kde4 source package needed to allow KDE's compiz to see all the extra plugins that are available with the compiz-fusion packages. Is that the direction they are heading?

@adamk75
"you probably wouldn't see this corruption (assuming you don't exceed the cards maximum 3D limitation of 2560)"

Aha, I see , so is that why I had to add the virtual line in my xorg.conf for 'xrandr' to be used? ( I used to use the binary drivers to get compiz-fusion working with dual monitor, but --current isn't support by fglrx anymore, so I'm kind of new to the whole xrandr setup)

snip....
SubSection "Display"
Viewport 0 0
Depth 24
Modes "1280x1024_75.00" "1280x1024" "1024x768" "800x600" "640x480"
Virtual 2560 1024
snip....

The Virtual line just tells Xorg what the maximum resolution you plan on using across both monitors. It doesn't have anything to do with the maximum 3D texture size or the maximum 3D resolution. The version of Xorg and radeon you are using just aren't very good at guessing what resolution monitors are attached to both ports of the video card (newer ones might work better so that Virtual isn't required).

If you are using two 1280x1024 monitors (as appears to be the case) you could use xrandr to place one of them "Above" or "Below" the other. This would give you a combined resolution of 1280x2048, which does not exceed the 2028x2048 limitation. Getting used to stacking the monitors vertically virtually can be difficult, though, when you place them horizontally physically :-)

Adam

adam:

Interesting.

My setup for xrandr.

My primary monitor, on the left can do 1280x1024 @ 100+ Hz

My secondary monitor, on the right can do 1280x1024 @ 60Hz max (but it flickers) so I use 1152x864 @ 75 hz on the right side monitor to avoid flickering.

Since I have slackware --current (using xrandr) on this box, dual booted with debian-lenny (using fglrx) I wrote a script for my xfce,

here's my 'bash-fu'

#!/bin/sh

if [ -e /etc/slackware-version ]; then
if [ `hostname` = "darkstart" ]; then
ps ax |grep xfce4-session |grep bin |cut -d "/" -f 4 -s > /tmp/session.info
if grep -q xfce4-session /tmp/session.info ; then \
/usr/bin/xrandr --output DVI-0 --mode 1152x864 --right-of VGA-0
rm /tmp/session.info
fi
fi
fi

This way if I'm in Slackware, using xfce, then xrandr kicks in for me. But if I boot into Debian, only KDE is available and fglrx takes over via the xorg.conf for fglrx.

I just noticed today, using gtk-record my desktop, that my computer records my primary monitor fine, but does not record that part of the screen that Compiz-Fusion had issues with too. However, my apps are there and work fine.

I tried this with compiz on and off. Very odd.

I just set out to build compiz on my recent install of slackware64-current, using slackbuilds.

plugins-main however is failing to build because it keeps reading /usr/lib instead of /usr/lib64 despite specifying x86_64 in the slackbuild

I can configure manually, then build it without a problem though
sr2pkg also fails with the same errors



edit: I even manually edited the slackbuild to configure with --libdir=/usr/lib64
and i still get that error, yet i can manually './confgure --libdir=/usr/lib64 && make' without an error, what the hell?

exact error: There is a libGLU.so in both /usr/lib and /usr/lib64 as well as libXcomposite.so, has anyone else had this problem?

I'd much rather make a package rather than just make install.

additional edit:
I just decided to make the package manually with /sbin/makepkg after compiling the source myself since i have no clue why the slackbuild kept failing when it was seemingly running nearly the exact same configure options.

Please read http://slackbuilds.org/faq/#x86_64 carefully

Eric

Oh, I see, thanks. I got it working though.