I can confirm that the xv and gl video is watchable using xcompmgr over compiz. Its still buggy; it refuses to accept a transparency given by transset and if the background changes (e.g scrolling a web page behind the movie) then the video disappears (apparently replaced by the background) for a fraction of a second (much like the compiz choppyness). I wonder if the xv/gl stuff doesn't like compositing and compiz is more inclined to refresh background windows.
Announcement
Collapse
No announcement yet.
AMD 8.42.3 Driver Released -- The Baby Is Born!
Collapse
This topic is closed.
X
X
-
Originally posted by Berniyh View PostI knew it.
Now the screen corruption came back, so that isn't the solution either, but it might help a little bit.
Code:Section "Device" Identifier "ATI Radeon 9600" Driver "fglrx" VendorName "ATI Technologies Inc" BusID "PCI:1:0:0" Option "VideoOverlay" "on" Option "OpenGLOverlay" "off" Option "UseFastTLS" "2" Option "KernelModuleParm" "locked-userpages=0" Option "no_accel" "no" Option "no_dri" "no" Option "EnablePrivateBackZ" "no" Option "backingstore" "true" Option "XAANoOffscreenPixmaps" "true" Option "ForceMonitors" "notv" EndSection
Comment
-
Originally posted by hluk View PostThe screen corruption is gone for me
Actually if it takes that long it would be acceptable, but I really would like to see AMD releasing a bug fix for this before next driver release (I know that's not gonna happen...).
Another thing that they really should release a fix for before the next release (8.43) is the wrong SONAME issue of libGL.so which may hold off this driver of gentoo's portage.
See here:
That shouldn't be a big issue and I guess it would be fixable by just releasing a fixed libGL.so, but of course that is not going to happen either.
Comment
-
Option "XAANoOffscreenPixmaps" "true"
the other thing is that you seem to have to force the xv with the videooverlay and disable the opengl overlay. after that i had to set beryl from texture from pixmaps to copy and my fps have not gone down anymore. now i'm stable at 700-800 fps with every environment which is quite good.
Another thing that they really should release a fix for before the next release (8.43) is the wrong SONAME issue of libGL.so which may hold off this driver of gentoo's portage.
for some reason the sabayon ebuild has removed the fgl_glxgears and some other things, but on my gentoo they work flawlessly. another important thing is to always run the atieventsd service at boot time. after i've had it added some time ago i was able to correct a lot of problems. i don't know what it really does but it seems to be of some kind of use.
Comment
-
Originally posted by givemesugarr View Postjust use the sabayon ebuild or modify the 8.40.4 one removing the gunzip line and by adding the libGL.so.{major} where there is the libGL symlinking in the ebuild.
Did they even test this? It spits out some errors during installation.
I'm mean, after an emerge, when you made (or modified an ebuild), you should just go through the install process at least once and see if it did everything correctly.
Sorry, but you just can't add some (proprietary) software one day after it has been released to your tree and with that they can't be taken serious by anybody again...
... or at least not by me.
The thing with the libGL.so is not that it has the wrong (file-)name. The thing, is that the SONAME of it is wrong, which brings the whole needing for the symlink in in first place.
See the gentoo bug about 8.42.3 for information.
I'll try the other option and see if that helps, tomorrow.
Comment
-
i don't really know if the sabayon ebuild works... i didn't tried it myself. i've patched manually the old 8.40.4 and installed from that one. for me it worked without problems. i had the driver installed about 1 hour after it was released and it works fine for now.
i could test the new ebuild, but since the old patched one works fine i don't really see a reason to change it. maybe when i got to try the 2.6.23 (not so fast since it seems for this driver to have problems with this kernel).
as for the soname issue, i don't really think that this is a real problem since it is fixed with a simple symlink. of course that should be fixed in the next release and i think that ati would correct that feature by next month's release. for now just add the symlink part in the ebuild and you'll have it working.
Comment
-
Originally posted by givemesugarr View Posti don't really know if the sabayon ebuild works... i didn't tried it myself. i've patched manually the old 8.40.4 and installed from that one. for me it worked without problems. i had the driver installed about 1 hour after it was released and it works fine for now.
i could test the new ebuild, but since the old patched one works fine i don't really see a reason to change it. maybe when i got to try the 2.6.23 (not so fast since it seems for this driver to have problems with this kernel).
The thing is (and maybe this is also the reason you didn't expect any problems) that ATI changed the installer package and therefore on AMD64 systems two of the 32bit libs don't get installed (because their location has changed). Of course if you modify the ebuild yourself this is ok, because then you know that you may run into problems, but if the ebuild is provided by your distributor you think, that it will work.
With your current ebuild you might expect problems running 32bit apps, that use opengl, for example, if you run a game with wine.
as for the soname issue, i don't really think that this is a real problem since it is fixed with a simple symlink. of course that should be fixed in the next release and i think that ati would correct that feature by next month's release. for now just add the symlink part in the ebuild and you'll have it working.
The real problem is, that because of the wrong SONAME the wrong libname is included by env-update/ldconfig and that is the reason it doesn't find the lib.
So this is a problem that should be fixed by ati, not a dirty hack in the ebuild.
Comment
Comment