Talk:Using Xgl on older versions of SUSE Linux

From openSUSE

FBO or pbuffer? which is better/faster/more compatible? Regarding the FBO and pbuffer settings for the nvidia Xgl settings, which is preferable? Is one setting faster than the other? I couldn't find this information on google. If anyone knows, please post here or update the main page to indicate which is better or preferable in most cases. If there are compatibility issues between nvidia cards, that would be nice to know, too.

FBOs don't work well yet. They do for xv acceleration, but not for glx or window.

Matthias 12:04, 3 March 2006 (UTC)

a note from David Reveman presentation (think fosdem)

- Was using pbuffers for offscreen memory management; moving to FBOs

http://people.freedesktop.org/~ajax/xdc2006-notes.txt

Czubin

Still, FBOs don't work yet. There is no new driver out there for which FBOs don't have issues. pBuffers had been disabled as soon as support for FBOs was there, and enabled back when it was clear that they do not work as anticipated.

Matthias 15:59, 21 March 2006 (UTC)

64bt compatability package

I'm using 64bit suse 10.0, and wish to give the whole xgl thing a go. However there are only 32 bit versions of the compatability packages available (from what I can tell). I could use these but it means I have to uninstall a load of 64 bit libraries and then re-install the 32 bit versions; this is porbably possible but in the mean time is cumbersome and causes way too many dependency issues. So - can any body provide a 64 bit version of the rpm - I'd make it myself, the files that the 32 bit version contains are fairly straight forward, but I am uncertain as to how I'd package a custom made rpm. Cheers. Ben.

Other architectures are now available.

Matthias 12:04, 3 March 2006 (UTC)

On subsequent startups it is enough to invoke compiz --replace gconf.

What is the proper way to do that? It might be something easy, but we shouldn't presume everyone knows how to do it :)

I suggest to simply remove that sentence and point to compiz page where a full explanation can. be given

Czubin Mark

I think it should stay because its useful. I do it with just adding it to the startup in gnome and I would add that to the article if I was confident enough that's the right thing to do. --Cassini83 20:57, 5 March 2006 (UTC)

GLIBC_2.4 issues

Well unfortunately, having installed the rpms for my 64bit 10.0 distro, Xgl doesn't start since there is no GLIBC_2.4 version of libc.so.6... Perhaps this could also be added to the compatability packages? NB. My exact error is

Xgl: /lib64/tls/libc.so.6: version `GLIBC_2.4' not found (required by/usr/X11R6/lib64/libXau.so.6) Xgl: /lib64/tls/libc.so.6: version `GLIBC_2.4' not found (required by/usr/X11R6/lib64/libXdmcp.so.6)

Ok, so I don't know what happenned here but after a reinstallation of everything, and I mean everything, things including xgl and compiz are working fantastically

This is good to know. I haven't received much input about the compatibility packages so far.

Matthias 15:59, 21 March 2006 (UTC)

X86_64 Links broken

Just tried to download the packages, but all of the x86_64 links are 404ed...

that's because the links were pointing to and older file, I changed the download entry-> now it doesn't link directly to a package

Mark Czubin

Edited download and install section

reason: besides finding it a bit ugly it was impractical the version updates every week , changing the wiki links every week is stupid :) Mark Czubin

This is not really a nice solution - but I don't have a better idea :-(.

Matthias 15:59, 21 March 2006 (UTC)

For suse 10.0:

As it seems , the newer compiz and Xgl packages got even a bigger dependancy.

Perhaps it's best to link to somewhat older packages which don't have these problems and are guaranteed to work.

Doing this by placing those packages (for example) on http://www.suse.de/~mhopf/xgl/ for the time being

and only updating the packages every two weeks if there are no problems.

It would be also easier for the user who don't have to scroll through thousands of packages.

Mark Czubin 16:26 Tuesday, March 21 2006 (UTC)

Wrong statements for fglrx

The following had been added to the fglrx troubleshooting section:

• It appears that on systems with ATI cards, a symlink is set incorrectly which causes Xorg to be started instead of Xgl.

To fix this, go to /usr/X11R6/bin and execute the following as root:

1. ln -sf Xgl XFree86

init 3 and init 5 and Xgl should be running. Verified on two laptops with ATI cards.

• Reported ATI fglrx driver version to work is 8.23.7-1
• Cards: Radeon Mobility 9700 and Radeon Mobility 24

I removed these lines, because they are obviously wrong. Just tested 8.23.7 on 10.1 Beta8 + newest packages on i386 with Radeon 9700:

• Xorg :0 & DISPLAY=:0 Xgl -fullscreen -br :1 works, and one can run compiz on :1
• Xorg :1 & DISPLAY=:1 Xgl -fullscreen -br :0 immedeately deadlocks. Thus the automatic Xorg startup sequence of Xgl won't work.
• XFree86 must be a link to Xorg for compatibility reasons. It is not used anywhere anymore, too. The Xserver to be called is /usr/X11R6/bin/X, which itself must be a symlink to /var/X11R6/bin/X, which is a symlink to /usr/X11R6/bin/$DISPLAYMANAGER_XSERVER (from /etc/sysconfig/displaymanager, after running SuSEconfig). Maybe the author of these linkes updated a very old system which still had a link to XFree86 somewhere.

Matthias 16:12, 21 March 2006 (UTC)

Issues with Java applications

Ok, so I haven't majorly tested this issues, but it seems that two Java applications (and probably others, which I haven't tried) do not work on my (64bit Amd) suse 10.0 distro, with Xgl and compiz. The two applications in question are B*rland's JB*ilder and L*mewire p2p program. The latter I can do without but since I do a huge amount of developing in Java, I *really* need the use of JBuilder (my preferred IDE). For this reason, I will unfortunately have to stop using Xgl unless the issue can be resolved. Perhaps, and indeed most likely, the problem is with Java in not understanding the Xgl api rather than it being an issue with the Xgl implementation itself. Ben.

Well, I've been playing around with the JVM settings and it seems that if you use the option -Dawt.nativeDoubleBuffering=true, then everything (atleast for a test ap, I wrote) works - although drawing updates are very flickery, which can by annoying. I guess Xgl uses native double buffering or something. Ben

In fact, forget this solution; its too flickery. Perhaps I'l try Xnest instead. Ben.

Using the Gnome Xgl control center applet instead

After setting up xgl/compiz the manual way on 10.1 beta9, I noticed that there is an applet to enable xgl or not. Might this be a complete replacement for the manual steps?

In the future, I guess so. Meanwhile, I won't mention it as it could even go away and be replaced by something different Matthias 13:27, 11 April 2006 (UTC)

Issues with 3D applications

3D applications like Blender and Google earth are working on software 3d accleration. How to go around this problem?

10.2?

This document reflects only 10.1/SLED config - doesn't account for the changes in 10.2. Can one of the maintainers be chided into updating this document to support 10.2?

Specifically, I'd like to see how to config compiz under KDE, what is actually happening when you change the sysconfig setting (I'd like to start using the kde-window-decorator, and add the gconf plugin)...