Bugzilla Bug 196820

A new version of ATI drivers that finally deliver AIGLX support!

Reproducible: Didn't try

Steps to Reproduce:

Oh my God! You just killed a kitten!
http://allen.brooker.gb.net/misc/kitten-0day.jpg

I was able to install fglrx drivers by modifying the 8.40.4 ebuild and moving
patches around

You will need a locval portage overlay

(http://gentoo-wiki.com/HOWTO_Installing_3rd_Party_Ebuilds#Local_Portage_Overlay)

Steps to duplicate

1. mkdir -p /usr/local/portage/x11-drivers/ati-drivers
2. cp -rp /usr/portage/x11-drivers/ati-drivers
/usr/local/portage/x11-drivers/ati-drivers
3. cd /usr/local/portage/x11-drivers/ati-drivers
4. cp ati-drivers-8.40.4.ebuild ati-drivers-8.42.3.ebuild
5. cd files/
6. cp -r 8.40.4 8.42.3
7. mv ati-drivers-8.40.4-warnings.patch ati-drivers-8.42.3-warnings.patch
8. cd ..
9. vi ati-drivers-8.42.3.ebuild
      a. comment out the following line gunzip
common/usr/share/man/man8/atieventsd.8 || die "manpage unzip failed"
10. ebuild ati-drivers-8.42.3.ebuild digest
11. emerge -av ati-drivers

If you do not get 8.42.3 as the driver do the following

echo x11-drivers/ati-drivers >> /etc/portage/package.keywords

then emerge again.

This works for me and AIGLX is enabled.  


(II) Module glx: vendor="X.Org Foundation"
        compiled for 1.3.0, module version = 1.0.0
        ABI class: X.Org Server Extension, version 0.3
(==) AIGLX enabled

(In reply to comment #2)
> I was able to install fglrx drivers by modifying the 8.40.4 ebuild and moving
> patches around
> 
> You will need a locval portage overlay
> 
> (http://gentoo-wiki.com/HOWTO_Installing_3rd_Party_Ebuilds#Local_Portage_Overlay)
> 
> Steps to duplicate
> 
> 1. mkdir -p /usr/local/portage/x11-drivers/ati-drivers
> 2. cp -rp /usr/portage/x11-drivers/ati-drivers
> /usr/local/portage/x11-drivers/ati-drivers
> 3. cd /usr/local/portage/x11-drivers/ati-drivers
> 4. cp ati-drivers-8.40.4.ebuild ati-drivers-8.42.3.ebuild
> 5. cd files/
> 6. cp -r 8.40.4 8.42.3
> 7. mv ati-drivers-8.40.4-warnings.patch ati-drivers-8.42.3-warnings.patch
> 8. cd ..
> 9. vi ati-drivers-8.42.3.ebuild
>       a. comment out the following line gunzip
> common/usr/share/man/man8/atieventsd.8 || die "manpage unzip failed"
> 10. ebuild ati-drivers-8.42.3.ebuild digest
> 11. emerge -av ati-drivers
> 
> If you do not get 8.42.3 as the driver do the following
> 
> echo x11-drivers/ati-drivers >> /etc/portage/package.keywords
> 
> then emerge again.
> 
> This works for me and AIGLX is enabled.  
> 
> 
> (II) Module glx: vendor="X.Org Foundation"
>         compiled for 1.3.0, module version = 1.0.0
>         ABI class: X.Org Server Extension, version 0.3
> (==) AIGLX enabled
> 

On AMD64 this will lead to problems, because ATI doesn't provie
arch/usr/X11R6/lib anymore.
Plus, I get "error while loading shared libraries: libGL.so.1" although it is
there.

The funny thing is: It works, if I set opengl to xorg-x11 (then glxinfo shows
DRI=Yes).
And I even get descent performance.
AIGLX is switched off.

Yeah i just noticed the missing libGL.so.1 I installed from a console and using
VNC to access the desktop.  I am looking to see how to fix the issues with the
missing lib.

> Plus, I get "error while loading shared libraries: libGL.so.1" although it
> is there.

I was getting this too, the following solved it:

cd /usr/lib
ln -s libGL.so libGL.so.1

I'm not sure why this was necessary, though...

(In reply to comment #4)
> Yeah i just noticed the missing libGL.so.1 I installed from a console and using
> VNC to access the desktop.  I am looking to see how to fix the issues with the
> missing lib.
> 

to partially solve this I did ln -s /usr/lib/opengl/ati/lib/libGL.so
/usr/lib/libGL.so and ln -s /usr/lib/opengl/ati/lib/libGL.so
/usr/lib/libGL.so.1 (before this I removed the old link to xorg-x11 lib.)
I said partially because of this:
(output of fusion-icon)

... executing: compiz --replace --sm-disable --ignore-desktop-hints ccp
compiz (core) - Fatal: GLX_EXT_texture_from_pixmap is missing
compiz (core) - Error: Failed to manage screen: 0
compiz (core) - Fatal: No manageable screens found on display :0.0

I'm pretty sure libGL.so.1 is no longer provided by the driver.  In the
previous release, 41.7, it was just a text file that claimed to be there to
satisfy install scripts.

I'm hoping you can just eselect opengl xorg and be perfectly fine and as
intended.

(In reply to comment #7)
> I'm pretty sure libGL.so.1 is no longer provided by the driver.  In the
> previous release, 41.7, it was just a text file that claimed to be there to
> satisfy install scripts.
> 
> I'm hoping you can just eselect opengl xorg and be perfectly fine and as
> intended.
> 

As stated above that works for me.

(In reply to comment #7)
> I'm pretty sure libGL.so.1 is no longer provided by the driver.  In the
> previous release, 41.7, it was just a text file that claimed to be there to
> satisfy install scripts.
> 
> I'm hoping you can just eselect opengl xorg and be perfectly fine and as
> intended.
> 

well, either with xorg-x11 or by creating a new ln -s to libGL.so.1 from
ati-drivers, dri and aiglx are working but compiz still doesnt work:
compiz (core) - Fatal: GLX_EXT_texture_from_pixmap is missing

So on amd64 using GCC 4.1.2 I was not able to install the driver after cleaning
up the old driver 8.39.

The installer kept bombing out at fgl_glxgears

I used the patch that will be attached to this post to fix the problem but now
I don't have fgl_glxgears oh well =)

I also had to create the symlink that you are taling about

ln -s /usr/lib64/opengl/ati/lib/libGL.so /usr/lib/libGL.so.1

I also have the pixmap support

zak@slacker ~ $ glxinfo | grep -i pixmap
    GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, 
    GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
zak@slacker ~ $ 

Created an attachment (id=134191) [details]
patch to remove fgl_glxgears from the 8.42 ebuild

I had to use this on amd64 GCC 4.1.2 to get 8.42 to build 

Take care! This version does not support FireGL cards, including FireGL
Mobility... Still have to wait....

Created an attachment (id=134199) [details]
ati-drivers-8.42.3.ebuild

First stab at an ebuild for this driver. I'm sure, that there is a more elegant
solution to the lib install routine, but it works.
I don't know if that thing with the symlink is more eselects fault. It should
create all the three symlinks
libGL.so.1.2 -> /usr/lib64/opengl/ati/lib/libGL.so.1.2
libGL.so.1 -> libGL.so.1.2
libGL.so -> libGL.1.2
when setting opengl to ati I guess, but it only links
libGL.so -> /usr/lib64/opengl/ati/lib/libGL.so


--- ati-drivers-8.40.4.ebuild.old       2007-10-23 19:26:01.000000000 +0200
+++ ati-drivers-8.42.3.ebuild   2007-10-23 23:51:16.000000000 +0200
@@ -119,8 +119,6 @@
        #would be created
        sh "${src}" --extract "${S}" 2&>1 /dev/null

-       gunzip common/usr/share/man/man8/atieventsd.8 || die "manpage unzip
failed"
-
        # These are the userspace utilities that we also have source for.
        # We rebuild these later.
        rm \
@@ -287,7 +285,7 @@
        # etc.
        insinto /etc/ati
        # Everything except for the authatieventsd.sh script.
-       doins
common/etc/ati/{fglrxprofiles.csv,fglrxrc,logo*,control,atiogl.xml,signature}
+       doins common/etc/ati/{logo*,control,atiogl.xml,signature}
        if use acpi; then
                doins common/etc/ati/authatieventsd.sh
        fi
@@ -363,7 +361,11 @@
        # The GLX libraries
        # (yes, this really is "lib" even on amd64/multilib --marienz)
        exeinto ${ATI_ROOT}/lib
-       doexe "${ARCH_DIR}"/usr/X11R6/${pkglibdir}/libGL.so.${libver}
+       if [[ "${ABI}" == "amd64" ]]; then
+               doexe "${ARCH_DIR}"/usr/X11R6/${pkglibdir}/libGL.so.${libver}
+       else
+               doexe
"${WORKDIR}"/arch/x86/usr/X11R6/${pkglibdir}/libGL.so.${libver}
+       fi
        dosym libGL.so.${libver} ${ATI_ROOT}/lib/libGL.so.${libmajor}
        dosym libGL.so.${libver} ${ATI_ROOT}/lib/libGL.so

@@ -373,7 +375,11 @@

        # DRI modules, installed into the path used by recent versions of mesa.
        exeinto /usr/$(get_libdir)/dri
-       doexe "${ARCH_DIR}"/usr/X11R6/${pkglibdir}/modules/dri/fglrx_dri.so
+       if [[ "${ABI}" == "amd64" ]]; then
+               doexe
"${ARCH_DIR}"/usr/X11R6/${pkglibdir}/modules/dri/fglrx_dri.so
+       else
+               doexe
"${WORKDIR}"/arch/x86/usr/X11R6/${pkglibdir}/modules/dri/fglrx_dri.so
+       fi

        # Make up a libGL.la. Ati does not provide one, but mesa does. If
        # a (libtool-based) libfoo is built with libGL.la present a

(In reply to comment #11)
> Created an attachment (id=134191) [edit] [details]
> patch to remove fgl_glxgears from the 8.42 ebuild
> 
> I had to use this on amd64 GCC 4.1.2 to get 8.42 to build 
> 
fgl_glxgears builds fine here using gcc-4.2.2 on amd64, so it's not a general
problem.

Created an attachment (id=134203) [details]
bonus patch

this is needed too!

Created an attachment (id=134204) [details]
bonus patch

this is needed too!

oops... sorry for a double addition :) also please change the ebuild :)

(In reply to comment #16)
> Created an attachment (id=134204) [edit] [details]
> bonus patch
> 
> this is needed too!
> 

First your patch fails, because it collides with the warnings patch, that is
already in the tree.
Second please tell, why the patch is needed.
Third please post a real description, "bonus patch" isn't one.
So please post a patch that has been cleaned up, works with current patches in
portage and mark those other patches obsolete.
And give it a reasonable name, like
ati-drivers-8.42.3-2.6.23-thispatchdoessomething.patch.
Thanks

Here is a patch to convert the 8.40.4 ebuild 8.42.3. Also here is the revised
patch from kamikaze which now applies cleanly. Kamikaze's patch is a
replacement for ati-drivers-2.6.23.patch with more cleanup/fixes for 2.6.23.

Created an attachment (id=134230) [details]
convert 8.40.4 ebuild to 8.42.3

Created an attachment (id=134232) [details]
More fixes/cleanups for 2.6.23

(In reply to comment #20)
> Created an attachment (id=134230) [edit] [details]
> convert 8.40.4 ebuild to 8.42.3
> 

> +		cd ${S}/common/lib/modules/fglrx/build_mod
> 		epatch ${FILESDIR}/${PV}/${PN}-2.6.23.patch
I would rather change the patch than the ebuild.
And it seems that you have overwritten the already existing 2.6.23 patch which
is also the reason that it now applies for you. With current tree patches
(which I guess are valid) it still collides.

You also missed the 32bit lib install part, therefore 32bit opengl apps won't
work (wine for example).

Created an attachment (id=134235) [details]
More fixes/cleanups for 2.6.23

Corrected file paths and removed last hunk, that is already contained in the
existing patch.

Created an attachment (id=134236) [details]
ati-drivers-2.6.23-2.patch

Added patch.

Created an attachment (id=134237) [details]
ati-drivers-8.42.3.ebuild

Sorry, wrong file.

I get this with the latest ebuild of Bernd. I'd appreciate the help!

# emerge -1 ati-drivers
Calculating dependencies... done!
>>> Verifying ebuild Manifests...

>>> Emerging (1 of 1) x11-drivers/ati-drivers-8.42.3 to /
 * ati-driver-installer-8.42.3-x86.x86_64.run MD5 ;-) ...                      
                                [ ok ]
 * ati-driver-installer-8.42.3-x86.x86_64.run RMD160 ;-) ...                   
                                [ ok ]
 * ati-driver-installer-8.42.3-x86.x86_64.run SHA1 ;-) ...                     
                                [ ok ]
 * ati-driver-installer-8.42.3-x86.x86_64.run SHA256 ;-) ...                   
                                [ ok ]
 * ati-driver-installer-8.42.3-x86.x86_64.run size ;-) ...                     
                                [ ok ]
 * checking ebuild checksums ;-) ...                                           
                                [ ok ]
 * checking auxfile checksums ;-) ...                                          
                                [ ok ]
 * checking miscfile checksums ;-) ...                                         
                                [ ok ]
 * checking ati-driver-installer-8.42.3-x86.x86_64.run ;-) ...                 
                                [ ok ]
 * Determining the location of the kernel source code
 * Found kernel source directory:
 *     /usr/src/linux
 * Found kernel object directory:
 *     /lib/modules/2.6.22-gentoo-r8/build
 * Found sources for kernel version:
 *     2.6.22-gentoo-r8
>>> Unpacking source...
 * Applying ati-powermode-opt-path.patch ...                                   
                                [ ok ]
 * Converting 2.6.x/Makefile to use M= instead of SUBDIRS= ...                 
                                [ ok ]
>>> Unpacking ./../common/usr/src/ati/fglrx_sample_source.tgz to /var/tmp/portage/x11-drivers/ati-drivers-8.42.3/work/extra
 * Applying ati-drivers-8.42.3-warnings.patch ...                              
                                [ ok ]
>>> Source unpacked.
>>> Compiling source in /var/tmp/portage/x11-drivers/ati-drivers-8.42.3/work ...
 * Preparing fglrx module
make -C /usr/src/linux
M=/var/tmp/portage/x11-drivers/ati-drivers-8.42.3/work/common/lib/modules/fglrx/build_mod/2.6.x
modules
make[1]: Entering directory `/usr/src/linux-2.6.22-gentoo-r8'
  CC [M] 
/var/tmp/portage/x11-drivers/ati-drivers-8.42.3/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.o
/var/tmp/portage/x11-drivers/ati-drivers-8.42.3/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:
In function ‘fglrx_pci_suspend’:
/var/tmp/portage/x11-drivers/ati-drivers-8.42.3/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:799:
warning: passing argument 1 of ‘firegl_pci_save_state’ from incompatible
pointer type
/var/tmp/portage/x11-drivers/ati-drivers-8.42.3/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:
In function ‘fglrx_pci_resume’:
/var/tmp/portage/x11-drivers/ati-drivers-8.42.3/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:841:
warning: passing argument 1 of ‘firegl_pci_restore_state’ from incompatible
pointer type
/var/tmp/portage/x11-drivers/ati-drivers-8.42.3/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:
At top level:
/var/tmp/portage/x11-drivers/ati-drivers-8.42.3/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:527:
warning: ‘firegl_smp_func_parameter_wrap’ defined but not used
  LD [M] 
/var/tmp/portage/x11-drivers/ati-drivers-8.42.3/work/common/lib/modules/fglrx/build_mod/2.6.x/fglrx.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC     
/var/tmp/portage/x11-drivers/ati-drivers-8.42.3/work/common/lib/modules/fglrx/build_mod/2.6.x/fglrx.mod.o
  LD [M] 
/var/tmp/portage/x11-drivers/ati-drivers-8.42.3/work/common/lib/modules/fglrx/build_mod/2.6.x/fglrx.ko
make[1]: Leaving directory `/usr/src/linux-2.6.22-gentoo-r8'
 * Building fgl_glxgears
 * Building fglrx_gamma lib
 * Building fglrx_gamma util
>>> Source compiled.
>>> Test phase [not enabled]: x11-drivers/ati-drivers-8.42.3

>>> Install ati-drivers-8.42.3 into /var/tmp/portage/x11-drivers/ati-drivers-8.42.3/image/ category x11-drivers
 * Installing fglrx module
 * ati tree 'lib' -> 'lib32' on system
sed: can't read /usr/portage/local/x11-drivers/ati-drivers/files/libGL.la.in:
No such file or directory
 * 
 * ERROR: x11-drivers/ati-drivers-8.42.3 failed.
 * Call stack:
 *   ebuild.sh, line 1654:   Called dyn_install
 *   ebuild.sh, line 1089:   Called qa_call 'src_install'
 *   ebuild.sh, line 44:   Called src_install
 *   ati-drivers-8.42.3.ebuild, line 249:   Called src_install-libs
 *   ati-drivers-8.42.3.ebuild, line 401:   Called die
 * 
 * sed failed to make libGL.la
 * If you need support, post the topmost build error, and the call stack if
relevant.
 * A complete build log is located at
'/var/log/portage/x11-drivers:ati-drivers-8.42.3:20071024-152758.log'.
 * 

(In reply to comment #26)
> I get this with the latest ebuild of Bernd. I'd appreciate the help!
> 

>  * Installing fglrx module
>  * ati tree 'lib' -> 'lib32' on system
> sed: can't read /usr/portage/local/x11-drivers/ati-drivers/files/libGL.la.in:
> No such file or directory

You're missing that file.
What you should du is:
cp -R /usr/portage/x11-drivers/ati-drivers
/usr/portage/local/x11-drivers/ati-drivers
Then you have got all the files and patches, that are needed.

(In reply to comment #26)
> I get this with the latest ebuild of Bernd. I'd appreciate the help!
> 
> # emerge -1 ati-drivers
> Calculating dependencies... done!
> >>> Verifying ebuild Manifests...
> 
> >>> Emerging (1 of 1) x11-drivers/ati-drivers-8.42.3 to /
>  * ati-driver-installer-8.42.3-x86.x86_64.run MD5 ;-) ...                      
>                                 [ ok ]
>  * ati-driver-installer-8.42.3-x86.x86_64.run RMD160 ;-) ...                   
>                                 [ ok ]
>  * ati-driver-installer-8.42.3-x86.x86_64.run SHA1 ;-) ...                     
>                                 [ ok ]
>  * ati-driver-installer-8.42.3-x86.x86_64.run SHA256 ;-) ...                   
>                                 [ ok ]
>  * ati-driver-installer-8.42.3-x86.x86_64.run size ;-) ...                     
>                                 [ ok ]
>  * checking ebuild checksums ;-) ...                                           
>                                 [ ok ]
>  * checking auxfile checksums ;-) ...                                          
>                                 [ ok ]
>  * checking miscfile checksums ;-) ...                                         
>                                 [ ok ]
>  * checking ati-driver-installer-8.42.3-x86.x86_64.run ;-) ...                 
>                                 [ ok ]
>  * Determining the location of the kernel source code
>  * Found kernel source directory:
>  *     /usr/src/linux
>  * Found kernel object directory:
>  *     /lib/modules/2.6.22-gentoo-r8/build
>  * Found sources for kernel version:
>  *     2.6.22-gentoo-r8
> >>> Unpacking source...
>  * Applying ati-powermode-opt-path.patch ...                                   
>                                 [ ok ]
>  * Converting 2.6.x/Makefile to use M= instead of SUBDIRS= ...                 
>                                 [ ok ]
> >>> Unpacking ./../common/usr/src/ati/fglrx_sample_source.tgz to /var/tmp/portage/x11-drivers/ati-drivers-8.42.3/work/extra
>  * Applying ati-drivers-8.42.3-warnings.patch ...                              
>                                 [ ok ]
> >>> Source unpacked.
> >>> Compiling source in /var/tmp/portage/x11-drivers/ati-drivers-8.42.3/work ...
>  * Preparing fglrx module
> make -C /usr/src/linux
> M=/var/tmp/portage/x11-drivers/ati-drivers-8.42.3/work/common/lib/modules/fglrx/build_mod/2.6.x
> modules
> make[1]: Entering directory `/usr/src/linux-2.6.22-gentoo-r8'
>   CC [M] 
> /var/tmp/portage/x11-drivers/ati-drivers-8.42.3/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.o
> /var/tmp/portage/x11-drivers/ati-drivers-8.42.3/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:
> In function ‘fglrx_pci_suspend’:
> /var/tmp/portage/x11-drivers/ati-drivers-8.42.3/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:799:
> warning: passing argument 1 of ‘firegl_pci_save_state’ from incompatible
> pointer type
> /var/tmp/portage/x11-drivers/ati-drivers-8.42.3/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:
> In function ‘fglrx_pci_resume’:
> /var/tmp/portage/x11-drivers/ati-drivers-8.42.3/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:841:
> warning: passing argument 1 of ‘firegl_pci_restore_state’ from incompatible
> pointer type
> /var/tmp/portage/x11-drivers/ati-drivers-8.42.3/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:
> At top level:
> /var/tmp/portage/x11-drivers/ati-drivers-8.42.3/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:527:
> warning: ‘firegl_smp_func_parameter_wrap’ defined but not used
>   LD [M] 
> /var/tmp/portage/x11-drivers/ati-drivers-8.42.3/work/common/lib/modules/fglrx/build_mod/2.6.x/fglrx.o
>   Building modules, stage 2.
>   MODPOST 1 modules
>   CC     
> /var/tmp/portage/x11-drivers/ati-drivers-8.42.3/work/common/lib/modules/fglrx/build_mod/2.6.x/fglrx.mod.o
>   LD [M] 
> /var/tmp/portage/x11-drivers/ati-drivers-8.42.3/work/common/lib/modules/fglrx/build_mod/2.6.x/fglrx.ko
> make[1]: Leaving directory `/usr/src/linux-2.6.22-gentoo-r8'
>  * Building fgl_glxgears
>  * Building fglrx_gamma lib
>  * Building fglrx_gamma util
> >>> Source compiled.
> >>> Test phase [not enabled]: x11-drivers/ati-drivers-8.42.3
> 
> >>> Install ati-drivers-8.42.3 into /var/tmp/portage/x11-drivers/ati-drivers-8.42.3/image/ category x11-drivers
>  * Installing fglrx module
>  * ati tree 'lib' -> 'lib32' on system
> sed: can't read /usr/portage/local/x11-drivers/ati-drivers/files/libGL.la.in:
> No such file or directory
>  * 
>  * ERROR: x11-drivers/ati-drivers-8.42.3 failed.
>  * Call stack:
>  *   ebuild.sh, line 1654:   Called dyn_install
>  *   ebuild.sh, line 1089:   Called qa_call 'src_install'
>  *   ebuild.sh, line 44:   Called src_install
>  *   ati-drivers-8.42.3.ebuild, line 249:   Called src_install-libs
>  *   ati-drivers-8.42.3.ebuild, line 401:   Called die
>  * 
>  * sed failed to make libGL.la
>  * If you need support, post the topmost build error, and the call stack if
> relevant.
>  * A complete build log is located at
> '/var/log/portage/x11-drivers:ati-drivers-8.42.3:20071024-152758.log'.
>  * 
> 

cp /usr/portage/x11-drivers/ati-drivers/files/libGL.la.in
/usr/local/portage/x11-drivers/ati-drivers/files/libGL.la.in

Has anyone here tried the ebuild from the sabayon overlay?  I am about to
emerge it and see how it works on my amd_64 system.

patch ati-drivers-2.6.23.patch doesn't apply.

***** ati-drivers-2.6.23.patch *****

====================================

PATCH COMMAND:   patch -p0 -g0 -E --no-backup-if-mismatch <
/usr/portage/x11-drivers/ati-drivers/files/8.42.3/ati-drivers-2.6.23.patch

====================================
can't find file to patch at input line 4
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -urN build_mod2/firegl_public.c build_mod/firegl_public.c
|--- build_mod2/firegl_public.c 2007-10-24 14:10:52.000000000 +0000
|+++ build_mod/firegl_public.c  2007-10-24 14:14:39.000000000 +0000
--------------------------
No file to patch.  Skipping patch.
4 out of 4 hunks ignored

and a lot more of that

ironically i don't even use 2.6.23 kernel (because of issues like these) so
i'll try it wihtout the two 2.6.23 patches and see what happens.

(In reply to comment #30)
> patch ati-drivers-2.6.23.patch doesn't apply.
> 
> ***** ati-drivers-2.6.23.patch *****
> 

Try this one:
https://bugs.gentoo.org/attachment.cgi?id=134235
It's the same, but the paths have been corrected.
In the ebuild there is a section where it checks for the kernel version, the
patch belongs there.
So if you have an older kernel it will not be applied.

(In reply to comment #29)
> Has anyone here tried the ebuild from the sabayon overlay?  I am about to
> emerge it and see how it works on my amd_64 system.
> 

Ok, the sabayon ebuild works great!  All I had to do was:
cd /usr/lib
ln -s libGL.so libGL.so.1
as Neil mentioned above.  And compiz-fusion works.  3D apps are a little buggy
but that is the driver's fault.

This is on my core 2 duo (64bit dual lib system) with an ati mobility x1400.

(In reply to comment #31)
> (In reply to comment #30)
> > patch ati-drivers-2.6.23.patch doesn't apply.
> > 
> > ***** ati-drivers-2.6.23.patch *****
> > 
> 
> Try this one:
> https://bugs.gentoo.org/attachment.cgi?id=134235
> It's the same, but the paths have been corrected.
> In the ebuild there is a section where it checks for the kernel version, the
> patch belongs there.
> So if you have an older kernel it will not be applied.
> 

I keep getting this error too. Even with the patch you attached. Same output...
what do I miss? Should this patch you attached (called
ati-drivers-2.6.23-2.patch) replace ati-drivers-2.6.23.patch? Sorry, I'm a bit
confused now...

greetings
Johannes

(In reply to comment #33)
> (In reply to comment #31)
> > (In reply to comment #30)
> > > patch ati-drivers-2.6.23.patch doesn't apply.
> > > 
> > > ***** ati-drivers-2.6.23.patch *****
> > > 
> > 
> > Try this one:
> > https://bugs.gentoo.org/attachment.cgi?id=134235
> > It's the same, but the paths have been corrected.
> > In the ebuild there is a section where it checks for the kernel version, the
> > patch belongs there.
> > So if you have an older kernel it will not be applied.
> > 
> 
> I keep getting this error too. Even with the patch you attached. Same output...
> what do I miss? Should this patch you attached (called
> ati-drivers-2.6.23-2.patch) replace ati-drivers-2.6.23.patch? Sorry, I'm a bit
> confused now...
> 
> greetings
> Johannes
> 

There are three patches, that are 8.42.3 specific. Two of them are in the
current portage tree (ati-drivers-8.42.3-warnings.patch and
ati-drivers-2.6.23.patch).
The third is the one originally posted by kamikaze, but it has some passages
similar to the other patches.
All of those three patches (to of them you should copy and rename from 8.40.4)
belong in files/8.42.3/.
Then either use the ebuild I posted above or modify it yourself.
Correct output should look like this (when you're using a 2.6.23 kernel):
>>> Unpacking ./../common/usr/src/ati/fglrx_sample_source.tgz to /var/tmp/portage/x11-drivers/ati-drivers-8.42.3/work/extra
 * Applying ati-drivers-8.42.3-warnings.patch ...                              
                                                          [ ok ]
 * Applying ati-drivers-2.6.23.patch ...                                       
                                                                               
                              [ ok ]
 * Applying ati-drivers-2.6.23-2.patch ...                                     
                                                                               
                              [ ok ]
>>> Source unpacked.

Did you get a failure because the patch failed or because it wasn't found?

(In reply to comment #34)
> (In reply to comment #33)
> > (In reply to comment #31)
> > > (In reply to comment #30)
> > > > patch ati-drivers-2.6.23.patch doesn't apply.
> > > > 
> > > > ***** ati-drivers-2.6.23.patch *****
> > > > 
> > > 
> > > Try this one:
> > > https://bugs.gentoo.org/attachment.cgi?id=134235
> > > It's the same, but the paths have been corrected.
> > > In the ebuild there is a section where it checks for the kernel version, the
> > > patch belongs there.
> > > So if you have an older kernel it will not be applied.
> > > 
> > 
> > I keep getting this error too. Even with the patch you attached. Same output...
> > what do I miss? Should this patch you attached (called
> > ati-drivers-2.6.23-2.patch) replace ati-drivers-2.6.23.patch? Sorry, I'm a bit
> > confused now...
> > 
> > greetings
> > Johannes
> > 
> 
> There are three patches, that are 8.42.3 specific. Two of them are in the
> current portage tree (ati-drivers-8.42.3-warnings.patch and
> ati-drivers-2.6.23.patch).
> The third is the one originally posted by kamikaze, but it has some passages
> similar to the other patches.
> All of those three patches (to of them you should copy and rename from 8.40.4)
> belong in files/8.42.3/.
> Then either use the ebuild I posted above or modify it yourself.
> Correct output should look like this (when you're using a 2.6.23 kernel):
> >>> Unpacking ./../common/usr/src/ati/fglrx_sample_source.tgz to /var/tmp/portage/x11-drivers/ati-drivers-8.42.3/work/extra
>  * Applying ati-drivers-8.42.3-warnings.patch ...                              
>                                                           [ ok ]
>  * Applying ati-drivers-2.6.23.patch ...                                       
>                                                                                
>                               [ ok ]
>  * Applying ati-drivers-2.6.23-2.patch ...                                     
>                                                                                
>                               [ ok ]
> >>> Source unpacked.
> 
> Did you get a failure because the patch failed or because it wasn't found?
> 

It fails. Same message as posted above. These are the patches in files/8.42.3:

ati-drivers-2.6.23-2.patch
ati-drivers-2.6.23.patch
ati-drivers-8.42.3.patch
ati-drivers-8.42.3-warnings.patch

I'm using the ebuild you attached.

The output is:

 * Failed Patch: ati-drivers-2.6.23.patch !
 *  (
/usr/portage/local/local-overlay/x11-drivers/ati-drivers/files/8.42.3/ati-drivers-2.6.23.patch
)

Thanks for ya reply.

(In reply to comment #35)
> 
> It fails. Same message as posted above. These are the patches in files/8.42.3:


Is this the same file as this is:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/x11-drivers/ati-drivers/files/8.40.4/ati-drivers-2.6.23.patch?rev=1.1&view=markup
> ati-drivers-2.6.23.patch

What does this patch do:
> ati-drivers-8.42.3.patch
Do you apply it in the ebuild?
> ati-drivers-8.42.3-warnings.patch
> 
> I'm using the ebuild you attached.
> 
> The output is:
> 
>  * Failed Patch: ati-drivers-2.6.23.patch !
>  *  (
> /usr/portage/local/local-overlay/x11-drivers/ati-drivers/files/8.42.3/ati-drivers-2.6.23.patch
> )
> 
> Thanks for ya reply.
> 

If it still fails please post the .rej file, because it applies here fine and I
can't reproduce it.

Is it possible to at least update xorg-server ebuild (for example from
!x11-drivers/ati-drivers into !<x11-drivers/ati-drivers-8.42.3) in portage?

Ok, it works now. I must have mixed up things... Thanks :) I had to remove
fgl_glxgears too, thought. Otherwise it would not build. And I get an Access
violation:

--------------------------- ACCESS VIOLATION SUMMARY
---------------------------
LOG FILE = "/var/log/sandbox/sandbox-x11-drivers_-_ati-drivers-8.42.3-1290.log"

open_wr:   /usr/src/linux-2.6.23-gentoo/null.gcda

I'll try using FEATURES="-sandbox" to test. 

(In reply to comment #38)
> Ok, it works now. I must have mixed up things... Thanks :) I had to remove
> fgl_glxgears too, thought. Otherwise it would not build. And I get an Access
> violation:
> 
> --------------------------- ACCESS VIOLATION SUMMARY
> ---------------------------
> LOG FILE = "/var/log/sandbox/sandbox-x11-drivers_-_ati-drivers-8.42.3-1290.log"
> 
> open_wr:   /usr/src/linux-2.6.23-gentoo/null.gcda
> 
> I'll try using FEATURES="-sandbox" to test. 
> 

emerge sandbox-2.18.1-r1
That fixes the access violation.

If somebody have problems to configure the overlay:
A little help to find the right attachements (i used Bernd Steinhauers one) and
the correct files from the old ebuild.

# correct the path
cd /usr/local/portage/local/overlay/

rm -rf x11-drivers/ati-drivers

mkdir -p x11-drivers/ati-drivers/files/8.42.3

wget http://bugs.gentoo.org/attachment.cgi?id=134237 -O
x11-drivers/ati-drivers/ati-drivers-8.42.3

cp /usr/portage/x11-drivers/ati-drivers/files/ati-powermode-opt-path.patch
x11-drivers/ati-drivers/files

cp /usr/portage/x11-drivers/ati-drivers/files/atieventsd.init
x11-drivers/ati-drivers/files

cp /usr/portage/x11-drivers/ati-drivers/files/libGL.la.in
x11-drivers/ati-drivers/files

cp
/usr/portage/x11-drivers/ati-drivers/files/8.40.4/ati-drivers-8.40.4-warnings.patch
x11-drivers/ati-drivers/files/8.42.3/ati-drivers-8.42.3-warnings.patch

cp /usr/portage/x11-drivers/ati-drivers/files/8.40.4/ati-drivers-2.6.23.patch
x11-drivers/ati-drivers/files/8.42.3

wget http://bugs.gentoo.org/attachment.cgi?id=134235 -O
x11-drivers/ati-drivers/files/8.42.3/ati-drivers-2.6.23-2.patch

ebuild x11-drivers/ati-drivers/ati-drivers-8.42.3.ebuild digest

# -O because of the xorg-server block
emerge -O1 =ati-drivers-8.42.3

eselect opengl set ati

# why we have to do it now?
ln -s libGL.so /usr/lib/libGL.so.1

Ups Bernd Steinhauser said it before:

Plus, I get "error while loading shared libraries: libGL.so.1" although it is
there.
The funny thing is: It works, if I set opengl to xorg-x11 (then glxinfo shows
DRI=Yes).
And I even get descent performance.

Ups Bernd Steinhauser said it before:

Plus, I get "error while loading shared libraries: libGL.so.1" although it is
there.
The funny thing is: It works, if I set opengl to xorg-x11 (then glxinfo shows
DRI=Yes).
And I even get descent performance.

When I switch from X to console (ctrl+alt or by ending the Xsession) and I
switch back to X (or a new Xsession) the system is hanging. But that would be a
driver problem.

(In reply to comment #40)
> # why we have to do it now?
> ln -s libGL.so /usr/lib/libGL.so.1
> 
I think (I don't know) that partly it is ATI/AMDs fault. They might have
changed something in their naming scheme.
But I think partly it is eselects fault, because I guess it should create 3
links {.so,.so.1,.so.1.2} and not only one {.so}.
A modification of eselect could fix this. 
The ebuild could create symlinks
libGL.so -> libGL.so.1
libGL.so -> libGL.so.1.2
but I guess the eselect approach is better.

(In reply to comment #42)
> When I switch from X to console (ctrl+alt or by ending the Xsession) and I
> switch back to X (or a new Xsession) the system is hanging. But that would be a
> driver problem.

I get that, too, but I had this also with 8.40.4. It does now work sometimes
(For example it does now work if I select "Console login" before login in
kdm.), but it is not reliable. 
We can only hope that ATI/AMD fix this once and for all, because problems with
console switching has been around for years.

If i see this right:
eselect opengl changes the file "/etc/env.d/03opengl"
   LDPATH="/usr/lib/opengl/ati/lib"
   OPENGL_PROFILE="ati"
resp.
   LDPATH="/usr/lib/opengl/xorg-x11/lib"
   OPENGL_PROFILE="xorg-x11"
then the dynamic linker cache is updated.

What I do not understand:
for i in xorg-x11 ati; do eselect opengl set $i; ldconfig -p | grep libGL.so;
done
Switching to xorg-x11 OpenGL interface... done
  libGL.so.1 (libc6, OS ABI: Linux 2.4.20)
    => /usr/lib/opengl/xorg-x11/lib/libGL.so.1
  libGL.so (libc6, OS ABI: Linux 2.4.20)
    => /usr/lib/opengl/xorg-x11/lib/libGL.so
  libGL.so (libc6, OS ABI: Linux 2.4.20)
    => /usr/lib/libGL.so
Switching to ati OpenGL interface... done
  libGL.so.1.2 (libc6)
    => /usr/lib/opengl/ati/lib/libGL.so.1.2
  libGL.so (libc6)
    => /usr/lib/opengl/ati/lib/libGL.so
  libGL.so (libc6)
    => /usr/lib/libGL.so

If we use xorg-x11 the cache contains libGL.so.1
If we use    ati   the cache contains libGL.so.1.2

1. If I try to run glxinfo it diplay:
name of display: :0.0
and hangs
2. If I try to run compiz-fusion (I understood it is supported by aiglx. If not
please skip this point):
X Error of failed request:  GLXBadContext
  Major opcode of failed request:  129 (GLX)
  Minor opcode of failed request:  5 (X_GLXMakeCurrent)
  Serial number of failed request:  16
  Current serial number in output stream:  16 Using GTK decorator
compiz (core) -  Fatal:  GLX_EXT_texture_from_pixmap  is  missing
compiz (core) - Error: Failed to manage screen: 0 compiz (core) -
Fatal: No manageable screens found on display :0.0  The  applica-
tion  'gtk-window-decorator'  lost  its connection to the display
:0.0; most likely the X server was shut down  or  you  killed/de-
stroyed the application.
3. glxgears runs normally (accelerated)
What's wrong?

ATI Catalyst Control Center (/opt/bin/amdcccle) doesnt work and report this
error:

amdcccle: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
Aborted

ok, something related with xcb... however, I'm on amd64 and the x86 binary
(included in ati-driver-instaler) works! I've also to create a symlink of
libGL.so.1 in /usr/lib32/...

This ebuild does not block xorg-server-1.4(-r2), right?  The 8.42.3 drivers
have support for XOrg 7.3 including server 1.4.

(In reply to comment #47)
> This ebuild does not block xorg-server-1.4(-r2), right?  The 8.42.3 drivers
> have support for XOrg 7.3 including server 1.4.
> 

This ebuild doesn't block xorg-server-1.4, the xorg-server ebuild holds
!ati-drivers and blocks this from there. The xorg-server ebuild will need to
updated (probably -r3) after this ati-driver version gets added to the tree.

(In reply to comment #46)
> ATI Catalyst Control Center (/opt/bin/amdcccle) doesnt work and report this
> error:
> 
> amdcccle: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
> Aborted
> 
> ok, something related with xcb... however, I'm on amd64 and the x86 binary
> (included in ati-driver-instaler) works! I've also to create a symlink of
> libGL.so.1 in /usr/lib32/...

I've been struggling with xcb problem for sometime now. It's gone, but now I
get segmentation faults when trying to run any program using libGL (I guess).
After debugging glxinfo it looks like SIGSEGV happens inside libGL library. Now
I'm trying to figure out what's wrong (tried almost everything - kernel,
rebuilds, libGL substitution). Interesting thing that a libGL from ati package
has different size than the one found in eselect directory ([...]/opengl/ati).

Łukasz.

Concerning vsync: the settings in ~/.drirc are ignored by this driver version.
Actually there *is* a way to enable vsync, but only until the next X restart:
use /opt/bin/amdcccle, choose the preferred vsync mode and press Apply.

Unfortunately, the setting is not remembered at next X server restart. I know
amdcccle stores the setting in /etc/ati/amdpcsdb, but I *don't* know how it
applies it on-the-fly. Maybe someone fluent with strace could find it ? ;-)

For what it's worth:

The above patch wouldn't apply for me
https://bugs.gentoo.org/attachment.cgi?id=134232 (ati-drivers-2.6.23.patch).

I just used the ati-drivers-2.6.23.patch for the 8.40.4 driver and that one
along with https://bugs.gentoo.org/attachment.cgi?id=134235
(ati-drivers-2.6.23-2.patch) applied with no problems.

Ok, here's what works with this driver on my x86_64 r600 hardware:

The ebuild seems to work fine and I haven't had any issues with the patches.

There is a symbolic link issue where it doesn't create libGL.so.1 or
libGL.so.1.2 in /usr/lib32 and /usr/lib64, I will see if I can file a seperate
bug for that.  The libraries exist and function properly after being linked.

This driver works with xorg-server-1.4, with no xrandr-1.2 (you can use
amdcccle), BUT aiglx does not work with xorg-server-1.4.  I was able to get it
to function with 1.3 and it works although there are a few issues with aiglx
(fex shadows, scroll speed).

Video Overlay (xv or gl) is working provided you get your xorg.conf option set
right and your hardware supports it, check Xorg.0.log for hints.

I have tested both 32bit and 64bit apps and they both run great.  I have seen
no issues and great performance.

This version of amdcccle does not work with xcb.

I would definitely like to see this driver in portage sooner rather than later,
it is either this or vesa to get my 2900pro working.

(In reply to comment #52)
> There is a symbolic link issue where it doesn't create libGL.so.1 or
> libGL.so.1.2 in /usr/lib32 and /usr/lib64, I will see if I can file a seperate
> bug for that.  The libraries exist and function properly after being linked.

On my machine I've patched eselect-opengl:
--- opengl.eselect.old  2007-10-24 23:55:46.000000000 +0200
+++ opengl.eselect      2007-10-24 23:57:07.000000000 +0200
@@ -79,7 +79,7 @@
                # Note that we don't do .so*, just .so on purpose.  The
                # loader knows to look in the profile dir, and the
                # linked just needs the .so
-               for file in ${profile_libdir}/libGL{,core}.{so,a,la}; do
+               for file in ${profile_libdir}/libGL{,core}.{{so,so.*},a,la}; do
                        if [[ ${ROOT} != / ]] ; then
                                rootfile="${file//${ROOT}}"
                        else

For the ebuild:
--- eselect-opengl-1.0.5.ebuild.old     2007-10-25 00:06:31.000000000 +0200
+++ eselect-opengl-1.0.5.ebuild 2007-10-25 00:00:11.000000000 +0200
@@ -2,7 +2,7 @@
 # Distributed under the terms of the GNU General Public License v2
 # $Header:
/var/cvsroot/gentoo-x86/app-admin/eselect-opengl/eselect-opengl-1.0.5.ebuild,v
1.14 2007/07/01 22:53:00 peper Exp $

-inherit multilib
+inherit multilib eutils

 DESCRIPTION="Utility to change the OpenGL interface being used"
 HOMEPAGE="http://www.gentoo.org/"
@@ -35,6 +35,7 @@
        mv opengl.eselect-${PV} opengl.eselect
        mv glext.h-${GLEXT} glext.h
        mv glxext.h-${GLXEXT} glxext.h
+       epatch ${FILESDIR}/eselect-opengl.patch
 }

 pkg_preinst() {

With this solution it creates three symlinks instead of only one, but I don't
know if this is a valid solution, because I don't know, if this is an issue,
that should be fixed by eselect (although it can be fixed by eselect) and
because the wanted result might be that the other two symlinks in /usr/lib
point to the local lib (i.e. /usr/lib/libGL.so -> /usr/lib/libGL.so.1.2).
What I did there was the quickest and easiest solution, but maybe not the best.

Anyway, if the above solution is correct, then it could take quite some time,
till this driver hits portage, because corrected eselect would have to hit
portage first.

The "correct" solution to the libGL.so* problem is to leave eselect-opengl
alone and simply symlink libGL.so to libGL.so.1.2 and libGL.so.1

The linux convention is to have the file libX.so.y.z symlinked to by libX.so.y
and libX.so. For whatever reason, AMD/ATI decided that they'd violate this
convention for this release.

Upon closer inspection, it seems that the package properly provides
libGL.so.1.2

The lack of proper symlinks is a problem with the ebuild.

Regarding the missing symlinks, could the SONAME-Bug at
http://ati.cchtml.com/show_bug.cgi?id=843 somehow fool portages install
functions?

@teidakankan@gmail.com
> The above patch wouldn't apply for me
> https://bugs.gentoo.org/attachment.cgi?id=134232 (ati-drivers-2.6.23.patch).
> 
> I just used the ati-drivers-2.6.23.patch for the 8.40.4 driver and that one
> along with https://bugs.gentoo.org/attachment.cgi?id=134235
> (ati-drivers-2.6.23-2.patch) applied with no problems.
This was explained by 'Bernd Steinhauser' in this thread.
Comment  #18 From Bernd Steinhauser 2007-10-24 10:02:22 0000
Comment  #22 From Bernd Steinhauser 2007-10-24 15:00:48 0000

SONAME-Bug
I think i would say something like that with:
Comment  #44 From Rathgeb Markus 2007-10-24 22:07:28 0000

(In reply to comment #55)
> Upon closer inspection, it seems that the package properly provides
> libGL.so.1.2
> 
> The lack of proper symlinks is a problem with the ebuild.
> 

Uhm, disagree. As you said package provides correctly libGL.so.1.2 and the
ebuild works as it should, it puts libGL.so.1.2 in /usr/lib/opengl/ati/lib and
then symlinks libGL.so.1 and libGL.so to in the _same_ directory. Where it goes
wrong is in the dir /usr/lib and not /usr/lib/opengl/ati/lib and if the ebuild
will mess with the files in /usr/lib that's just plain wrong, because that is
eselects job (to symlink the files in /usr/lib to the selected implementation
in /usr/lib/opengl/${implementation}/lib.

*** Bug 197072 has been marked as a duplicate of this bug. ***

(In reply to comment #56)
> Regarding the missing symlinks, could the SONAME-Bug at
> http://ati.cchtml.com/show_bug.cgi?id=843 somehow fool portages install
> functions?
> 

I guess that actually is the case:
readelf -d /usr/lib/opengl/ati/lib/libGL.so.1.2
...
0x000000000000000e (SONAME)             Library soname: [libGL.so.1.2]
...

readelf -d /usr/lib/opengl/xorg-x11/lib/libGL.so.1.2
...
0x000000000000000e (SONAME)             Library soname: [libGL.so.1]
...

That, I guess, triggers the behavior Markus Rathgeb found, see comment #44

(In reply to comment #58)
> (In reply to comment #55)
> ...Where it goes
> wrong is in the dir /usr/lib and not /usr/lib/opengl/ati/lib...

Sorry, you're right. It's a misunderstanding on my part.

In any case, this seems to be a eselect-opengl problem that may- or may-not be
amd64 specific. There should probably be a new bug opened against that.

FWIW, the behavior of eselect-opengl has not changed in quite a long time, and
I've never experienced an issue with fglrx and eselect-opengl on x86 since the
latter hit stable.

After compiling the drivers with the ebuild I expericenced some random
artifacts. After using the ati installer it worked out of the box. Now I have a
readeon 200M so I do not have the standart memory model. But I gues we are
doing something wrong with the ebuild. I'll try to dig into that deeper
tomorrow. Is anybody else having the artifact problem? Or is runing the 200M
without any problems?

By the way: I just read the README that come with the drivers. And gentoo is
mentioned however we do not have a maintianer. Maybe someone with a lot of
ati-drivers experince can contact ati and help them and us out.

(In reply to comment #62)
> After compiling the drivers with the ebuild I expericenced some random
> artifacts. After using the ati installer it worked out of the box. Now I have a
> readeon 200M so I do not have the standart memory model. But I gues we are
> doing something wrong with the ebuild. I'll try to dig into that deeper
> tomorrow. Is anybody else having the artifact problem? Or is runing the 200M
> without any problems?
> 
> By the way: I just read the README that come with the drivers. And gentoo is
> mentioned however we do not have a maintianer. Maybe someone with a lot of
> ati-drivers experince can contact ati and help them and us out.
> 

The reason for that is because you can't do things on Gentoo the way ATi would
like to do them.  For example, you can't just generate an eBuild using their
installers the way you would a bebian package or an RPM.  Maybe you could, but
it would be complicated.  That's one reason why we do everything ourselves.

How are you receiving artifacts?  I shouldn't say how, but when?

(In reply to comment #61)
> In any case, this seems to be a eselect-opengl problem that may- or may-not be
> amd64 specific. There should probably be a new bug opened against that.

It's not amd64 specific, the 32bit libs show the same thing:
readelf -d /usr/lib32/opengl/ati/lib/libGL.so.1.2
...
 0x0000000e (SONAME)                     Library soname: [libGL.so.1.2]
...
readelf -d /usr/lib32/opengl/xorg-x11/lib/
...
0x0000000e (SONAME)                     Library soname: [libGL.so.1]
...

(Note that those are the _same_ libs and not amd64-specific 32bit libs.)

It is a problem that should be corrected by ATI, but there is a way that this
could be worked around with a eselect-opengl modification.
But maybe ATI could just release an updated libGL.so.1.2 package which fixes
this. Shouldn't be that hard...

(In reply to comment #63)
> How are you receiving artifacts?  I shouldn't say how, but when?
> 

Well as far as I could see they were there the whole time not huge or anything.
I'll re-emerge the new drivers with the ebuild today and see what it is.

(In reply to comment #65)
> (In reply to comment #63)
> > How are you receiving artifacts?  I shouldn't say how, but when?
> > 
> 
> Well as far as I could see they were there the whole time not huge or anything.
> I'll re-emerge the new drivers with the ebuild today and see what it is.
> 

Ah I just found out that when I change my transluency settings the artifact
show up on the right bottom of my screen. But that is not relevant to this
problem. Probably something ati has to work on. Other than that they are
working fine...

(In reply to comment #66)
> (In reply to comment #65)
> > (In reply to comment #63)
> > > How are you receiving artifacts?  I shouldn't say how, but when?
> > > 
> > 
> > Well as far as I could see they were there the whole time not huge or anything.
> > I'll re-emerge the new drivers with the ebuild today and see what it is.
> > 
> 
> Ah I just found out that when I change my transluency settings the artifact
> show up on the right bottom of my screen. But that is not relevant to this
> problem. Probably something ati has to work on. Other than that they are
> working fine...
> 

Ah, you mean those screen corruptions?
They have nothing to do with the install process.
It's one of the bugs this driver version has, according to Phoronix forums AMD
is aware of this problem (and hopefully will fix it in the next version).

There are a few options, that might help with this, but that doesn't belong
here, look into Phoronix forums, if you want to try them out.

Created an attachment (id=134467) [details]
ati-drivers-8.42.3.ebuild

I think this is a better way to handle the moved location of the 32bit libs for
64bit systems.
It provides the same functionality as the previous one, so no need for a
remerge (unless you want to test it of course).
32bit systems should not care about this.

--- ati-drivers-8.42.3.ebuild.old       2007-10-27 11:09:20.000000000 +0200
+++ ati-drivers-8.42.3.ebuild   2007-10-27 11:29:17.000000000 +0200
@@ -349,8 +349,10 @@
 src_install-libs() {
        if [[ "${ABI}" == "amd64" ]]; then
                local pkglibdir=lib64
+               local MY_ARCH_DIR="${S}/arch/x86_64"
        else
                local pkglibdir=lib
+               local MY_ARCH_DIR="${S}/arch/x86"
        fi
        einfo "ati tree '${pkglibdir}' -> '$(get_libdir)' on system"

@@ -362,11 +364,7 @@
        # The GLX libraries
        # (yes, this really is "lib" even on amd64/multilib --marienz)
        exeinto ${ATI_ROOT}/lib
-       if [[ "${ABI}" == "amd64" ]]; then
-               doexe "${ARCH_DIR}"/usr/X11R6/${pkglibdir}/libGL.so.${libver}
-       else
-               doexe
"${WORKDIR}"/arch/x86/usr/X11R6/${pkglibdir}/libGL.so.${libver}
-       fi
+       doexe "${MY_ARCH_DIR}"/usr/X11R6/${pkglibdir}/libGL.so.${libver}
        dosym libGL.so.${libver} ${ATI_ROOT}/lib/libGL.so.${libmajor}
        dosym libGL.so.${libver} ${ATI_ROOT}/lib/libGL.so

@@ -376,11 +374,7 @@

        # DRI modules, installed into the path used by recent versions of mesa.
        exeinto /usr/$(get_libdir)/dri
-       if [[ "${ABI}" == "amd64" ]]; then
-               doexe
"${ARCH_DIR}"/usr/X11R6/${pkglibdir}/modules/dri/fglrx_dri.so
-       else
-               doexe
"${WORKDIR}"/arch/x86/usr/X11R6/${pkglibdir}/modules/dri/fglrx_dri.so
-       fi
+       doexe "${MY_ARCH_DIR}"/usr/X11R6/${pkglibdir}/modules/dri/fglrx_dri.so

        # Make up a libGL.la. Ati does not provide one, but mesa does. If
        # a (libtool-based) libfoo is built with libGL.la present a

rayan, can you delete the "ati-drivers-2.6.23.patch"? The correct patch (with
this name) should be take from portage tree
x11-drivers/ati-drivers/files/8.40.4/*

ciao

luigi

AGP -> PCIe (or just the X1600 and X1950 AGP) do not seem to be working (well
really slow)

read my post over at phoronix for more details.

http://www.phoronix.com/forums/showthread.php?p=16997

As i'm writing this, i do notice some weird corruption on the 9500Pro on the
bottom right, where the 'watermark' is supposed to be on beta drivers? I'll
gladly take that though for the performance gain i'm gettin on my 9500 :) (took
my 1950 out)

(In reply to comment #62)
> By the way: I just read the README that come with the drivers. And gentoo is
> mentioned however we do not have a maintianer. Maybe someone with a lot of
> ati-drivers experince can contact ati and help them and us out

As I work directly with ati for gentoo along with sabyon I have this covered
before the release is ever made.

(In reply to comment #15)
> Created an attachment (id=134203) [edit] [details]
> bonus patch
> 
> this is needed too!
> 

This is a straight up violation of the GPL learn what you are doing before you
get yourself or someone else into a legal bind.

(In reply to comment #21)
> Created an attachment (id=134232) [edit] [details]
> More fixes/cleanups for 2.6.23
> 

This is also a violation of GPL do not distribute or expect it to be included
by any distro. This code you are all wanting to use belongs to kernel
developers and you do not have permission to redistribute it, or have not shown
any proof that you have permission.

Created an attachment (id=134516) [details]
official ati 2.6.13 support

(From update of attachment 134516 [details])
sorry hit wrong key!!!!

(In reply to comment #74)
> Created an attachment (id=134516) [edit] [details]
> official ati 2.6.13 support
> 

If that is the official support for 2.6.23, then maybe you didn't test it,
right?
It spits out:
WARNING: "__ke_vm_test_and_clear_dirty"
[/var/tmp/portage/x11-drivers/ati-drivers-8.42.3/work/common/lib/modules/fglrx/build_mod/2.6.x/fglrx.ko]
undefined!

This will prevent the module to be loaded.
So I guess, that this patch wasn't made for 8.42.3 and will not work with it.

(In reply to comment #72)
(In reply to comment #73)

Anarchy, is that you again? Can we please keep this bug free of off-topic
noise?!

Please bump this driver, it's the only one which seems to support the 2400 HD
mobility card.

*** Bug 197375 has been marked as a duplicate of this bug. ***

I didn't have had a look on all patches here, but on 8.41.7 was a patch needed
in order to get suspend working with 2.6.23 kernels, i patched this here too,
some experiences if it is needed anymore?

-#if !defined(CONFIG_SMP) || defined(CONFIG_SUSPEND_SMP) // ACPI not working on
older SMP kernel (prior to 2.6.13)
+#if !defined(CONFIG_SMP) || defined(CONFIG_PM_SLEEP_SMP) // ACPI not working
on older SMP kernel (prior to 2.6.13)

(In reply to comment #80)
> I didn't have had a look on all patches here, but on 8.41.7 was a patch needed
> in order to get suspend working with 2.6.23 kernels, i patched this here too,
> some experiences if it is needed anymore?
> 
> -#if !defined(CONFIG_SMP) || defined(CONFIG_SUSPEND_SMP) // ACPI not working on
> older SMP kernel (prior to 2.6.13)
> +#if !defined(CONFIG_SMP) || defined(CONFIG_PM_SLEEP_SMP) // ACPI not working
> on older SMP kernel (prior to 2.6.13)
> 

There is an extra bug for this, see bug 196684.
Since this isn't version specific (the patch should be applied to older
versions, too) it shouldn't be handled in this bug.

I have an Ati Mobility X600 on 2.6.22-ck1.
I used the latest ebuild, i.e, 8.42.3 (released on 27/10). The new driver
compiled fine (with the exception of a few warnings), and AIGLX is enabled.
But, DRI is not enabled, although the dri drivers seems to be loaded. eselect
opengl is set to ati.
In the var/log/Xorg.0.log file, I read the following error:

(EE) fglrx(1): [DRI] Locking deadlock.
        Already locked with context 137612692,
        trying to lock with context 2.
(EE) fglrx(1): [DRI] Unlocking inconsistency:
        Context 137612692 trying to unlock lock held by context 2
(EE) fglrx(1): [DRI] Unlocking inconsistency:
        Context 137612692 trying to unlock lock held by context 2

Does anybody have a clue what this error mean?

(In reply to comment #82)
> I have an Ati Mobility X600 on 2.6.22-ck1.
> I used the latest ebuild, i.e, 8.42.3 (released on 27/10). The new driver
> compiled fine (with the exception of a few warnings), and AIGLX is enabled.
> But, DRI is not enabled, although the dri drivers seems to be loaded. eselect
> opengl is set to ati.
> In the var/log/Xorg.0.log file, I read the following error:
> (EE) fglrx(1): [DRI] Locking deadlock.
>         Already locked with context 137612692,
>         trying to lock with context 2.
> (EE) fglrx(1): [DRI] Unlocking inconsistency:
>         Context 137612692 trying to unlock lock held by context 2
> (EE) fglrx(1): [DRI] Unlocking inconsistency:
>         Context 137612692 trying to unlock lock held by context 2
> Does anybody have a clue what this error mean?

Can you post your Xorg.conf?  That might be an issue with DRI permissions.

Created an attachment (id=134653) [details]
xorg file

(In reply to comment #83)
> Can you post your Xorg.conf?  That might be an issue with DRI permissions.
> 
I do not think that there is an issue with DRI permision, since DRI is enabled
in older versionw of fglrx driver. Anyhow, maybe there is something else wrong
with the xorg.conf file, so here it is (xorg.conf file)

Is the ebuild going to be placed in portage anytime soon? People would enjoy
having AIGLX without hassles with overlaying... The last driver (8.41) did not
make it but probably because it was not worth it.

(In reply to comment #85)
> Is the ebuild going to be placed in portage anytime soon? People would enjoy
> having AIGLX without hassles with overlaying... The last driver (8.41) did not
> make it but probably because it was not worth it.
> 

patience :)
8.42 is a lot different from 8.40 and the corresponding ebuild will need a lot
of changes and checks. if you REALLY want it right now, copy the ebuild made so
far to your local overlay. 8.41 did not make it because it was not in a
productional state, but it was just a test version. 8.42 has all support needed
to make it to portage, just wait a couple of days

(In reply to comment #86)
> (In reply to comment #85)
> > Is the ebuild going to be placed in portage anytime soon? People would enjoy
> > having AIGLX without hassles with overlaying... The last driver (8.41) did not
> > make it but probably because it was not worth it.
> > 
> 
> patience :)
> 8.42 is a lot different from 8.40 and the corresponding ebuild will need a lot
> of changes and checks. if you REALLY want it right now, copy the ebuild made so
> far to your local overlay. 8.41 did not make it because it was not in a
> productional state, but it was just a test version. 8.42 has all support needed
> to make it to portage, just wait a couple of days
> 

Okay, I see. Thanks for clarifications. I have it running anyway just would be
nice to have it in portage.

(In reply to comment #86)
> (In reply to comment #85)
> > Is the ebuild going to be placed in portage anytime soon? People would enjoy
> > having AIGLX without hassles with overlaying... The last driver (8.41) did not
> > make it but probably because it was not worth it.
> > 
> 
> patience :)
> 8.42 is a lot different from 8.40 and the corresponding ebuild will need a lot
> of changes and checks. if you REALLY want it right now, copy the ebuild made so
> far to your local overlay. 8.41 did not make it because it was not in a
> productional state, but it was just a test version. 8.42 has all support needed
> to make it to portage, just wait a couple of days

8.42 is crippled and has no support for firegl cards I have already spoken with
the maintainer on irc, it will not be until 8.43 that a bump should be made.
This is when all cards from 8.40 will be resupported fully. 

Well, 8.42 hasa totally new code base, so it's expected.

(In reply to comment #88)
> 8.42 is crippled and has no support for firegl cards I have already spoken with
> the maintainer on irc, it will not be until 8.43 that a bump should be made.
> This is when all cards from 8.40 will be resupported fully. 
> 

There is a patch, that adds support for these cards. However, I don't know if
it is working and if it is working well, since I don't own such a card. See:
http://www.phoronix.com/forums/showthread.php?t=6091

But I would agree, that 8.42.3 isn't really a good version, since it has some
nasty bugs and (hopefully) 8.43 will come soon.

Then why not add the 8.42 ebuild package.mask'ed so more people can test the
ebuild changes and report any ebuild-related problems before 8.43 is out ? That
way, the 8.43 ebuild could be more mature from the start :-)

I'll second the vote for a masked package in portage - I'm dying to know if
AMD's rewrite finally solves the amd64/ati/Google Earth problem, and I'd rather
avoid having to set up the install by hand.

(In reply to comment #92)
> I'll second the vote for a masked package in portage - I'm dying to know if
> AMD's rewrite finally solves the amd64/ati/Google Earth problem, and I'd rather
> avoid having to set up the install by hand.
> 

Do you mean this lib-thing, where it is missing libGL.so.1.2, so it fails to
initialize?
That is not fixed by this driver. 

Making this ebuild a masked one seems like a very good idea to me. Personally,
I've already put the ebuild in a local overlay, but this sure would be a
welcome present to others.
I had a small problem of lots of applications looking for /usr/lib/libGL.so.1,
which wasn't there. I fixed it by doing (as root):
ln -s /usr/lib/libGL.so /usr/lib/libGL.so.1
Yes, weird linking order, but it works.

On my x1950 Pro AGP 3D is very sluggish. Xv seems pretty good but mplayer
crashes sometimes.  I have the following error in my Xorg.0.log:

(II) fglrx(0): [drm] register handle = 0x00004000
(EE) fglrx(0): Failed to enable interrupts.
(II) fglrx(0): [pci] find AGP GART
(II) fglrx(0): [agp] Mode=0x1f00421b bridge: 0x10de/0x00e1
(II) fglrx(0): [agp] AGP v1/2 disable mask 0x00000000
(II) fglrx(0): [agp] AGP v3 disable mask   0x00000000
(II) fglrx(0): [agp] enabling AGP with mode=0x1f00431a
(II) fglrx(0): [agp] Remapping MC AGP space (new MCAGPBase = 0xe0000000)
(II) fglrx(0): [agp] AGP protocol is enabled for graphics board.
(cmd=0x1f004312)
(II) fglrx(0): [agp] graphics chipset has AGP v3.0 (native mode)
(II) fglrx(0): DRI initialization successfull!

I've tried everything I can think of to get rid of this error.

I vote for the masked package too!!

The main problem with this driver's version is the lack of firegl cards
support, so those users simply have to leave the ebuild masked, while the
others can use the driver and test the ebuild for possible problems, helping to
fix them!

It's a simple and logical solution and it's used by many other packages, so i
don't see any problem doing so for this package too...

...ah, and it's right, this driver doesn't support firegl cards, but is also
right that 8.40.4 doesn't support ALL Radeon HD cards! So you're giving anyway
a non-complete cards support.

So, giving masked package is the best:
- firegl users will use ~8.40.4
- other users will use masked ~8.42.3

...and they lived happily ever after ;)

(In reply to comment #96)
> The main problem with this driver's version is the lack of firegl cards
> support, so those users simply have to leave the ebuild masked, while the
> others can use the driver and test the ebuild for possible problems, helping to
> fix them!

I don't think so. The driver can be patched to work with firegl cards (see my
post above), but there are other serious problems:
- Need of an additional symlink, because of wrong soname of libGL.so.1.2
(Maybe this can be fixed by the ebuild or eselect, but most likely this will go
away if 8.42.3 is skipped.)
- Screen corruptions, which can be worked around by a few options in xorg.conf.
(Option      "KernelModuleParm" "locked-userpages=0" and/or Option     
"XAANoOffscreenPixmaps" "true", I don't know, which one really solves it.)
How many people do you think will open bugs and threads complain about this,
even if you give a big warning in the ebuild or in package.mask?
- Crashes, oopses (ok, 8.40.4 has those, too)
- AIGLX is there, but it doesn't really work for many people, especially with
Compiz Fusion (Beryl seems to work better.).

(In reply to comment #93)
> [...]I'm dying to know if AMD's rewrite finally solves the amd64/ati/Google Earth problem[...]
> 
> Do you mean this lib-thing, where it is missing libGL.so.1.2, so it fails to
> initialize?
> That is not fixed by this driver. 
> 

No, the long-standing "Google Earth freezes at title screen with 100% CPU
usage" problem with (as best I can tell from Googling around about it) the ATI
driver, with certain video cards.  Might only be on AMD64 as well.  Despite the
fact that only Google Earth has the problem so far, fingers online seem to be
pointing at ATI's drivers as the cause.

(Plus - being stuck on the old proprietary ATI drivers is keeping me from
updating to the current X.org server...)

Would there really be many people who'd go to the effort to install a
hard-masked package who would then complain about bugs?

In reply to Comment #95
[quote]
I've tried everything I can think of to get rid of this error.
[/quote]

Read my post, from comment #70
(http://bugs.gentoo.org/show_bug.cgi?id=196820#c70) and then follow the link to
the phoronix forum. http://www.phoronix.com/forums/showthread.php?p=16997

You can find there what the problem is.

For those of you not having the problem ;)
It seems like someone got it fixed on his fedora system updating to the latest
kernel, 2.6.23. Since I hadn't gotten that one to work with the e-build/ATi
driver I haven't tried this myself and went back to 2.6.22 with slugish
performance. I just synced my portage tree so i'll try 2.6.23 tomorrow.

Finally I reccon that Ryan and Bernd's 2.6.23 and 2.6.23-2 kernel patches are
still needed with bernd's latest ebuild? I'll give that a whirl after gettin'
the kernel upgraded then.

This ebuild fails for me.

* Messages for package x11-drivers/ati-drivers-8.42.3:

 * Cannot find $EPATCH_SOURCE!  Value for $EPATCH_SOURCE is:
 * 
 *  
/usr/portage/local/xamindar/x11-drivers/ati-drivers/files/8.42.3/ati-drivers-8.42.3-warnings.patch
 *   ( ati-drivers-8.42.3-warnings.patch )
 * 
 * ERROR: x11-drivers/ati-drivers-8.42.3 failed.
 * Call stack:
 *                   ebuild.sh, line 1696:  Called dyn_unpack
 *                   ebuild.sh, line  812:  Called qa_call 'src_unpack'
 *                   ebuild.sh, line   44:  Called src_unpack
 *   ati-drivers-8.42.3.ebuild, line  167:  Called epatch
'/usr/portage/local/xamindar/x11-drivers/ati-drivers/files/8.42.3/ati-drivers-8.42.3-warnings.patch'
 *               eutils.eclass, line  161:  Called die
 * The specific snippet of code:
 *                      die "Cannot find \$EPATCH_SOURCE!"
 *  The die message:
 *   Cannot find $EPATCH_SOURCE!
 * 
 * If you need support, post the topmost build error, and the call stack if
relevant.
 * A complete build log is located at
'/var/tmp/portage/x11-drivers/ati-drivers-8.42.3/temp/build.log'.
 * 

(In reply to comment #99)
> Finally I reccon that Ryan and Bernd's 2.6.23 and 2.6.23-2 kernel patches are
> still needed with bernd's latest ebuild? I'll give that a whirl after gettin'
> the kernel upgraded then.
> 
You just need the 2.6.23-2 patch and the two patches, that are already in
portage (copy them over from your local portage tree).
See comment 40 from Markus Rathgeb for instructions.

(In reply to comment #100)
> This ebuild fails for me.
> 
See comment 40 from Markus Rathgeb for instructions.

Could someone please mark all the patches that are not needed mark obsolete?
That should also include fgl_glxgears patch, since that error should be fixed
by stable sandbox in tree.

Concerning Comment #98: Well, for me the 8.42.3 driver actually solves the
"Google Earth Freezes on Splash Screen" bug !

> See comment 40 from Markus Rathgeb for instructions.
> 
Thank, got a little farther but now it fails on fglxgears.

 * Messages for package x11-drivers/ati-drivers-8.42.3:

 * 
 * ERROR: x11-drivers/ati-drivers-8.42.3 failed.
 * Call stack:
 *                   ebuild.sh, line 1696:  Called dyn_compile
 *                   ebuild.sh, line 1034:  Called qa_call 'src_compile'
 *                   ebuild.sh, line   44:  Called src_compile
 *   ati-drivers-8.42.3.ebuild, line  188:  Called die
 * The specific snippet of code:
 *      "$(tc-getCC)" -o fgl_fglxgears ${CFLAGS} ${LDFLAGS} -DUSE_GLU \
 *              -I"${S}"/common/usr/include fgl_glxgears.c \
 *              -lGL -lGLU -lX11 -lm || die "fgl_glxgears build failed"
 *  The die message:
 *   fgl_glxgears build failed
 * 
 * If you need support, post the topmost build error, and the call stack if
relevant.
 * A complete build log is located at
'/var/tmp/portage/x11-drivers/ati-drivers-8.42.3/temp/build.log'.
 * 

Please forgive my bonehead post above.  Can I delete my posts?

ALL issues with 8.42.3 with regards to compiz not working is 100% due to
eselect-opengl issues....

People need to stop bitching about this driver, stop using if you dont know
what you are doing...

(In reply to comment #97)
> (In reply to comment #96)
> > The main problem with this driver's version is the lack of firegl cards
> > support, so those users simply have to leave the ebuild masked, while the
> > others can use the driver and test the ebuild for possible problems, helping to
> > fix them!
> 
> I don't think so. The driver can be patched to work with firegl cards (see my
> post above), but there are other serious problems:
> - Need of an additional symlink, because of wrong soname of libGL.so.1.2
> (Maybe this can be fixed by the ebuild or eselect, but most likely this will go
> away if 8.42.3 is skipped.)
> - Screen corruptions, which can be worked around by a few options in xorg.conf.
> (Option      "KernelModuleParm" "locked-userpages=0" and/or Option     
> "XAANoOffscreenPixmaps" "true", I don't know, which one really solves it.)
> How many people do you think will open bugs and threads complain about this,
> even if you give a big warning in the ebuild or in package.mask?
> - Crashes, oopses (ok, 8.40.4 has those, too)
> - AIGLX is there, but it doesn't really work for many people, especially with
> Compiz Fusion (Beryl seems to work better.).
> 

(In reply to comment #105)
> ALL issues with 8.42.3 with regards to compiz not working is 100% due to
> eselect-opengl issues....
> 
> People need to stop bitching about this driver, stop using if you dont know
> what you are doing...
> 

You got this totally wrong. I'm not bitching about this driver. In fact it
works quite well for me.

How it comes, that if (like you're saying) all of the issues with compiz are
totally related to eselect-opengl, that many users of other distros have
similar problems, where eselect-opengl doesn't even exist?

All that I was saying is, that I've got my doubts, that this driver is good
enough for portage. And I still think, that it isn't, at least not without an
entry in package.mask.

(In reply to comment #101)
> (In reply to comment #99)
> > Finally I reccon that Ryan and Bernd's 2.6.23 and 2.6.23-2 kernel patches are
> > still needed with bernd's latest ebuild? I'll give that a whirl after gettin'
> > the kernel upgraded then.
> > 
> You just need the 2.6.23-2 patch and the two patches, that are already in
> portage (copy them over from your local portage tree).
> See comment 40 from Markus Rathgeb for instructions.

For the last time do not tell people to use this patch it is a violation of GPL
and I am telling you as a kernel hacker to stop violating or you will pay the
consequences. You do not have the authors permissions to take his code which
was in the kernel then removed to add to a third party driver.

IANAL but I don't think there is any violation. Sure, the code is copied, but
ATI already copy similar macros from earlier kernel versions e.g.
ptep_clear_flush_dirty
Also, the macros are generic (they are for manipulating page tables, try and
find an OS that doesn't have page tables) and simple.

> I don't think so. The driver can be patched to work with firegl cards (see my
> post above), but there are other serious problems:

I know, but "someone" continue saying that code is a license violation...
Anyway, ignoring that (supposed) license violation, also firegl cards can
work...

> - Need of an additional symlink, because of wrong soname of libGL.so.1.2
> (Maybe this can be fixed by the ebuild or eselect, but most likely this will go
> away if 8.42.3 is skipped.)

There are lots of patches and/or additions in ebuilds of lots of packages...
couldn't we just add the symlink creation in the ebuild to fix the problem? I
think it's just a few lines of code ;)
If the symlink creation can't be added to the ebuild, you could just add a
WARNING at the end of the package's emerge process, to warn people to create
the symlink manually, maybe printing also the command to execute, so they only
have to copy & paste it :)

> - Screen corruptions, which can be worked around by a few options in xorg.conf.
> (Option      "KernelModuleParm" "locked-userpages=0" and/or Option     
> "XAANoOffscreenPixmaps" "true", I don't know, which one really solves it.)
> How many people do you think will open bugs and threads complain about this,
> even if you give a big warning in the ebuild or in package.mask?

Just to let you know, the line that fix the screen corruptions is
Option "XAANoOffscreenPixmaps" "true"

As for the symlink creation-proposal, a WARNING that warns about that issue
could be added in the ebuild, printed at the end of the package emerge process.

Anyway, I don't think people will complain much for a masked package and i
think lesser people will open bugs about it...
In addition, people generally search in the bugs database before posting a bug
and, for those who don't do it, bugs can just be marked as DUPLICATE or
other...

> - Crashes, oopses (ok, 8.40.4 has those, too)

All packages have bugs, crashes, etc. ;)
For example, with 8.39 and 8.40 driver i wasn't able to keep Gentoo up for more
than ~10 minutes, because it crashed!!
In 8.41 and 8.42 that problem has been fixed and i can work/"work" without any
problem (apart for screen corruptions that can be fixed with the xorg.conf
option cited above).

> - AIGLX is there, but it doesn't really work for many people, especially with
> Compiz Fusion (Beryl seems to work better.).

You have to cosider that there are lots of people (like me) that don't use
AIGLX and you also have to consider that previous driver's verions don't
support AIGLX at all!
So:
- people interested in using AIGLX can continue in the same way as they did
until now (__if__ the driver doesn't work for them, because there are lots of
people using AIGLX with the new driver... and it works!)
- people NOT interested in using AIGLX can use the new driver, with much higher
performances and bugs fixes

Just to be clear: i'm not "attacking" you Bernd, i'm just telling my opinion,
replying to your replies ;)
...and sorry if i wrote something wrong in english but i'm italian and lately
i'm a bit rusty with english :P

(In reply to comment #109)
> > - Need of an additional symlink, because of wrong soname of libGL.so.1.2
> > (Maybe this can be fixed by the ebuild or eselect, but most likely this will go
> > away if 8.42.3 is skipped.)
> 
> There are lots of patches and/or additions in ebuilds of lots of packages...
> couldn't we just add the symlink creation in the ebuild to fix the problem? I
> think it's just a few lines of code ;)
> If the symlink creation can't be added to the ebuild, you could just add a
> WARNING at the end of the package's emerge process, to warn people to create
> the symlink manually, maybe printing also the command to execute, so they only
> have to copy & paste it :)
It's not the problem, that it is tricky. Anyway I thought about this again and
I don't see a problem if eselect-opengl would create 3 symlinks instead of one.
Either:
libGL.so.1.2 -> opengl/ati/lib/libGL.so.1.2
libGL.so.1 -> opengl/ati/lib/libGL.so.1
libGL.so -> opengl/ati/lib/libGL.so
(That is easy, just look at my patch above for eselect-opengl.)
Or:
libGL.so.1.2 -> opengl/ati/lib/libGL.so.1.2
libGL.so.1 -> libGL.so.1.2
libGL.so -> libGL.so.1

The second approach would need some more modification to eselect-opengl, but I
think it is the cleaner approach. 

Of course printing out a warning that the user should create the symlink
himself would be a solution, but then you would also have to tell them, that
they should delete the symlink again if they switch back to xorg-x11. Not that
it would instantly bring problems up, but there might be problems and I would
rather try to avoid that. 

> 
> > - Screen corruptions, which can be worked around by a few options in xorg.conf.
> > (Option      "KernelModuleParm" "locked-userpages=0" and/or Option     
> > "XAANoOffscreenPixmaps" "true", I don't know, which one really solves it.)
> > How many people do you think will open bugs and threads complain about this,
> > even if you give a big warning in the ebuild or in package.mask?
> 
> Just to let you know, the line that fix the screen corruptions is
> Option "XAANoOffscreenPixmaps" "true"
Ok, thanks I will include a warning in the ebuild.

> Anyway, I don't think people will complain much for a masked package and i
> think lesser people will open bugs about it...
> In addition, people generally search in the bugs database before posting a bug
> and, for those who don't do it, bugs can just be marked as DUPLICATE or
> other...
Ok, I agree, let's bring this to package.mask, but that is not for me to
decide. ;)

> Just to be clear: i'm not "attacking" you Bernd, i'm just telling my opinion,
> replying to your replies ;)
> ...and sorry if i wrote something wrong in english but i'm italian and lately
> i'm a bit rusty with english :P
I don't feel offended. ;)

Created an attachment (id=135344) [details]
ati-drivers-8.42.3.ebuild

Added warnings for usage of the SLUB allocator (suspend is broken) and screen
corruptions.

Forgot the diff:
--- ati-drivers-8.42.3.ebuild.old       2007-11-06 17:21:17.000000000 +0100
+++ ati-drivers-8.42.3.ebuild   2007-11-06 17:58:12.000000000 +0100
@@ -91,6 +91,18 @@
                die "CONFIG_PARAVIRT enabled"
        fi

+       if linux_chkconfig_present SLUB; then
+               ewarn  "You have selected support for the SLUB allocator.
Suspending is"
+               ewarn  "known to be broken with this allocator and ati-drivers.
If you"
+               ewarn  "need support for Suspend-To-Ram or Suspend-To-Disk,
select SLAB"
+               ewarn  "instead. To do this enable CONFIG_SLAB and disable
CONFIG_SLUB"
+               ewarn  "in /usr/src/linux/.config or select"
+               ewarn  "                General setup  --->"
+               ewarn  "                        Choose SLAB allocator (SLUB) 
--->"
+               ewarn  "                                (X) SLAB"
+               ewarn  "in 'menuconfig'"
+       fi
+
        # xorg-server 1.1 and its prereleases correspond to xorg 7.1.
        if has_version ">=x11-base/xorg-server-1.0.99"; then
                BASE_DIR="${S}/x710"
@@ -405,6 +415,10 @@
 }

 pkg_postinst() {
+       ewarn "If you experience screen corruption with this driver, try
putting"
+       ewarn '         Option "XAANoOffscreenPixmaps" "true"'
+       ewarn "in the Device Section of /etc/X11/xorg.conf."
+
        /usr/bin/eselect opengl set --use-old ati

        elog "To switch to ATI OpenGL, run \"eselect opengl set ati\""

My video card is Ati Radeon Xpress 200. this driver didn't work for me!

I'm using ati-drivers-8.42.3.ebuild, and selected opengl to use ati driver.

But Xorg hangs before gnome logo appear, only the mouse cursor "X" can move.

Here is the output of "lspci"
# lspci
01:05.0 VGA compatible controller: ATI Technologies Inc RC410 [Radeon Xpress
200]

Anyone has the same problem as me?

http://ati.cchtml.com/show_bug.cgi?id=183
Here is a bug report saying that it's a problem only with xpress 200 series,
is it unresolved?

Totem-gstreamer opengl playback is broken with this driver, at least on my
machine. I'd vote to keep this hard masked at a minimum, this version is pretty
buggy.

~amd64, Radeon X1250 IGP, 2.6.23-gentoo

Just a little question:
Why do we collect here driver related bugs?
I thought there is a place for bugs related on gentoo.

I emerged this ebuild and my X now switched to software rendering. Why is that?
I'm using Xgl.

$ fglrxinfo
display: :0.0  screen: 0
OpenGL vendor string: Mesa project: www.mesa3d.org
OpenGL renderer string: Mesa GLX Indirect
OpenGL version string: 1.2 (1.5 Mesa 6.5.2)

"Hey, i've updated my PC and now it doesn't work!!"
Paul, first of all, we would need more info. secondly, like rathgeb argued, why
the heck are these things discussed in a bugreport? join #gentoo on irc if you
need help, or post a message on the forums, but this is not why bugzilla is
here

(In reply to comment #98)
> (In reply to comment #93)
> > [...]I'm dying to know if AMD's rewrite finally solves the amd64/ati/Google Earth problem[...]
> > 
> > Do you mean this lib-thing, where it is missing libGL.so.1.2, so it fails to
> > initialize?
> > That is not fixed by this driver. 
> > 
> 

  No  -  the driver doesn't fix this -- its still tied to the fact that
google's libgl and libglu are from a different generation than ati's driver. 
I've got googleearth working on this driver by moving googles libGL and libGLU
out of the way and softlinking to /usr/lib32/libGL and /usr/lib32/libGLU (cant
recall OTTOMH which .so .so.1 .so.1.2 links I setup) -- works rather well in my
books....
> No, the long-standing "Google Earth freezes at title screen with 100% CPU
> usage" problem with (as best I can tell from Googling around about it) the ATI
> driver, with certain video cards.  Might only be on AMD64 as well.  Despite the
> fact that only Google Earth has the problem so far, fingers online seem to be
> pointing at ATI's drivers as the cause.
> 
> (Plus - being stuck on the old proprietary ATI drivers is keeping me from
> updating to the current X.org server...)
> 
> Would there really be many people who'd go to the effort to install a
> hard-masked package who would then complain about bugs?
> 

I'm getting a sandbox violation while following the process in comment #40     
  open_wr:   /usr/src/linux-2.6.23-r1/null.gcda

  anyone have any ideas on that?

(In reply to comment #119)
> I'm getting a sandbox violation while following the process in comment #40     
>   open_wr:   /usr/src/linux-2.6.23-r1/null.gcda
> 
>   anyone have any ideas on that?
> 
emerge -v1 '>=sys-apps/sandbox-1.2.18.1-r1'

If necessary, unmask it.

(In reply to comment #116)
> I emerged this ebuild and my X now switched to software rendering. Why is that?
> I'm using Xgl.
> $ fglrxinfo
> display: :0.0  screen: 0
> OpenGL vendor string: Mesa project: www.mesa3d.org
> OpenGL renderer string: Mesa GLX Indirect
> OpenGL version string: 1.2 (1.5 Mesa 6.5.2)

If you run "eselect opengl set ati", what happens?  You really shouldn't need
to do this.

Post your emerge --info.  I need some more information.  Are you running AMD64?
 I'm assuming you're not because this might actually be the symlinks issue that
was resolved on AMD64 and not on x86.

(In reply to comment #120)
> (In reply to comment #119)
> > I'm getting a sandbox violation while following the process in comment #40     
> >   open_wr:   /usr/src/linux-2.6.23-r1/null.gcda
> > 
> >   anyone have any ideas on that?
> > 
> emerge -v1 '>=sys-apps/sandbox-1.2.18.1-r1'
> 
> If necessary, unmask it.
> 

  I upgraded sandbox and the issue went away -- *grin* thanks

   Having gotten this to build and install on my system, and having manually
added the missing libGL softlinks in /usr/lib64 and /usr/lib32  (amd64) this
creature is leaking memory horribly while running opengl based apps (phoronix
post is :
  http://www.phoronix.com/forums/showthread.php?t=6438
)
I'm certainly not the only one seeing this.

 Also, inasmuch as the driver is definately firing well according to the (not a
benchmark tool) glxgears and fgl_fglxgears (/not a benchmark tool) and getting
better PEAK framerates from gl processes (WoW in wine, ut2003-demo) I'm still
getting ****far**** better AVERAGE framerates from my ati9550 card with this
driver than with the X1650Pro AGP card.

   There are folks suggesting that using ATI's agp gart code would provide
better results, however looking at kernel config code from 2.6.18 on I cannot
see how one disables in kernel AGP code -- and with 2.6.23 IOMMU is turned on
by default with amd64 cpu optimizations, thus masking agp gart options. Am I
correct in assuming that if one is setting ones Processor Type to amd64/opteron
one locks out the choice in agp gart options?  Thus I gather that setting up a
64 bit system *properly* locks out the option.

  I'm going to try valgrinding things to see where the memory leak is
occurring.

   Bernd: 
   I'm still finding the list of patches in the attachments somewhat confusing:
 I think we need to (expire/deprecate/supercede) attachement
ati-drivers-2.6.23.patch as it appears that the real source for that file
should be from
/usr/portage/x11-drivers/ati-drivers/files/8.40.4/ati-drivers-2.6.23.patch in
the users system.
 and in truth I dont think the one here is identical (leastwise it needs
mangling before it will apply cleanly in my build tree - the path depth is
wrong)

(In reply to comment #123)
>    Bernd: 
>    I'm still finding the list of patches in the attachments somewhat confusing:
>  I think we need to (expire/deprecate/supercede) attachement
> ati-drivers-2.6.23.patch as it appears that the real source for that file
> should be from
> /usr/portage/x11-drivers/ati-drivers/files/8.40.4/ati-drivers-2.6.23.patch in
> the users system.
>  and in truth I dont think the one here is identical (leastwise it needs
> mangling before it will apply cleanly in my build tree - the path depth is
> wrong)
> 
Sorry, I can only mark my own attachments obsolete, you have to ask the
creators of those patches to do that (or a dev could do that).
Currently the only patch needed from this page is ati-drivers-2.6.23-2.patch.
The correct way to install this driver has been described by Markus in comment
40.

BTW:
Looking at the date (it's the 15th of November!) I guess we can skip this
driver and look forward to 8.43 which hopefully will be released soon.

  (aaaaaahhh!!!! we need better airtraffic controllers here -- we just collided
Bernd)


This is the summary from :

 valgrind --leak-check=full --error-limit=no -v fgl_fglxgears    

  if I'm reading this correctly there is something horribly wrong with my
libGL.so.1.2

listair@ajftl1 ~ $ ls /usr/lib/libGL.so.1.2
/usr/lib/libGL.so.1.2
alistair@ajftl1 ~ $ ls -l /usr/lib/libGL.so.1.2
lrwxrwxrwx 1 root root 10 Nov 14 20:22 /usr/lib/libGL.so.1.2 -> libGL.so.1
alistair@ajftl1 ~ $ ls -l /usr/lib/libGL.so.1
lrwxrwxrwx 1 root root 17 Nov 14 19:35 /usr/lib/libGL.so.1 -> /usr/lib/libGL.so
alistair@ajftl1 ~ $ ls -l /usr/lib/libGL.so
lrwxrwxrwx 1 root root 35 Nov 15 11:44 /usr/lib/libGL.so ->
//usr/lib64/opengl/ati/lib/libGL.so



==29383== IN SUMMARY: 15457167 errors from 118 contexts (suppressed: 10 from 1)
==29383==
==29383== malloc/free: in use at exit: 10,169,206 bytes in 2,623 blocks.
==29383== malloc/free: 69,334 allocs, 66,711 frees, 110,479,368 bytes
allocated.
==29383==
==29383== searching for pointers to 2,623 not-freed blocks.
==29383== checked 5,358,480 bytes.
==29383==
==29383==
==29383== 0 bytes in 120 blocks are definitely lost in loss record 1 of 66
==29383==    at 0x4A20D3B: malloc (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==29383==    by 0x695EC08: ???
==29383==    by 0x60C5840: ???
==29383==    by 0x60C5D73: ???
==29383==    by 0x60C4CE8: ???
==29383==    by 0x60C4378: ???
==29383==    by 0x60C2B9C: ???
==29383==    by 0x60C3408: ???
==29383==    by 0x60C2601: ???
==29383==    by 0x643BA8C: ???
==29383==    by 0x643BE37: ???
==29383==    by 0x6442C58: ???
==29383==
==29383==
==29383== 7 bytes in 1 blocks are definitely lost in loss record 5 of 66
==29383==    at 0x4A20D3B: malloc (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==29383==    by 0x6964ACA: ???
==29383==    by 0x69AF3C6: ???
==29383==    by 0x6966465: ???
==29383==    by 0x69AE32C: ???
==29383==    by 0x6965C11: ???
==29383==    by 0x67D95F1: ???
==29383==    by 0x67D9628: ???
==29383==    by 0x69C8415: ???
==29383==    by 0x605FB52: ???
==29383==
==29383==
==29383== 8 bytes in 1 blocks are definitely lost in loss record 8 of 66
==29383==    at 0x4A20D3B: malloc (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==29383==    by 0x4006A9E: _dl_map_object_from_fd (in /lib64/ld-2.5.so)
==29383==    by 0x4007A33: _dl_map_object (in /lib64/ld-2.5.so)
==29383==    by 0x40106AB: dl_open_worker (in /lib64/ld-2.5.so)
==29383==    by 0x400C885: _dl_catch_error (in /lib64/ld-2.5.so)
==29383==    by 0x40101B6: _dl_open (in /lib64/ld-2.5.so)
==29383==    by 0x5B151D9: (within /lib64/libdl-2.5.so)
==29383==    by 0x400C885: _dl_catch_error (in /lib64/ld-2.5.so)
==29383==    by 0x5B1555C: (within /lib64/libdl-2.5.so)
==29383==    by 0x5B15151: dlopen (in /lib64/libdl-2.5.so)
==29383==    by 0x4B6BA4B: (within /usr/lib64/opengl/ati/lib/libGL.so.1.2)
==29383==    by 0x4B6B4B4: driGetDriver (in
/usr/lib64/opengl/ati/lib/libGL.so.1.2)
==29383==
==29383==
==29383== 692 bytes in 14 blocks are possibly lost in loss record 25 of 66
==29383==    at 0x4A20D3B: malloc (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==29383==    by 0x695EC08: ???
==29383==    by 0x68711A3: ???
==29383==    by 0x6871686: ???
==29383==    by 0x686B587: ???
==29383==    by 0x68775B5: ???
==29383==    by 0x6399425: ???
==29383==    by 0x63B3FBD: ???
==29383==    by 0x6382FEF: ???
==29383==    by 0x60A1C09: ???
==29383==    by 0x650F2CD: ???
==29383==    by 0x650519F: ???
==29383==
==29383==
==29383== 1,728 (216 direct, 1,512 indirect) bytes in 1 blocks are definitely
lost in loss record 28 of 66
==29383==    at 0x4A20D3B: malloc (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==29383==    by 0x4B467F9: _gl_context_modes_create (in
/usr/lib64/opengl/ati/lib/libGL.so.1.2)
==29383==    by 0x69612E8: ???
==29383==    by 0x4B4D28F: (within /usr/lib64/opengl/ati/lib/libGL.so.1.2)
==29383==    by 0x4B4C87A: (within /usr/lib64/opengl/ati/lib/libGL.so.1.2)
==29383==    by 0x4B4B634: __glXInitialize (in
/usr/lib64/opengl/ati/lib/libGL.so.1.2)
==29383==    by 0x4B47FD4: glXChooseVisual (in
/usr/lib64/opengl/ati/lib/libGL.so.1.2)
==29383==    by 0x40203A: (within /usr/bin/fgl_fglxgears)
==29383==    by 0x4041C6: (within /usr/bin/fgl_fglxgears)
==29383==    by 0x51B5373: (below main) (in /lib64/libc-2.5.so)
==29383==
==29383==
==29383== 664 (16 direct, 648 indirect) bytes in 1 blocks are definitely lost
in loss record 29 of 66
==29383==    at 0x4A20D3B: malloc (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==29383==    by 0x4B4B3C2: __FireGLDRIGetVisualConfigPrivates (in
/usr/lib64/opengl/ati/lib/libGL.so.1.2)
==29383==    by 0x4B4D1D7: (within /usr/lib64/opengl/ati/lib/libGL.so.1.2)
==29383==    by 0x4B4C87A: (within /usr/lib64/opengl/ati/lib/libGL.so.1.2)
==29383==    by 0x4B4B634: __glXInitialize (in
/usr/lib64/opengl/ati/lib/libGL.so.1.2)
==29383==    by 0x4B47FD4: glXChooseVisual (in
/usr/lib64/opengl/ati/lib/libGL.so.1.2)
==29383==    by 0x40203A: (within /usr/bin/fgl_fglxgears)
==29383==    by 0x4041C6: (within /usr/bin/fgl_fglxgears)
==29383==    by 0x51B5373: (below main) (in /lib64/libc-2.5.so)
==29383==
==29383==
==29383== 319 (263 direct, 56 indirect) bytes in 3 blocks are definitely lost
in loss record 35 of 66
==29383==    at 0x4A20D3B: malloc (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==29383==    by 0x67D8C5C: ???
==29383==    by 0x68807ED: ???
==29383==    by 0x684B34E: ???
==29383==    by 0x6876D28: ???
==29383==    by 0x6060873: ???
==29383==    by 0x650515F: ???
==29383==    by 0x6532F58: ???
==29383==    by 0x65143F5: ???
==29383==    by 0x6965658: ???
==29383==    by 0x6961299: ???
==29383==    by 0x4B4D28F: (within /usr/lib64/opengl/ati/lib/libGL.so.1.2)
==29383==
==29383==
==29383== 960 (64 direct, 896 indirect) bytes in 1 blocks are definitely lost
in loss record 38 of 66
==29383==    at 0x4A20D3B: malloc (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==29383==    by 0x695EBF8: ???
==29383==    by 0x65B4F00: ???
==29383==    by 0x60C206F: ???
==29383==    by 0x60A1B7C: ???
==29383==    by 0x650F2CD: ???
==29383==    by 0x650519F: ???
==29383==    by 0x6532F58: ???
==29383==    by 0x65143F5: ???
==29383==    by 0x6965658: ???
==29383==    by 0x6961299: ???
==29383==    by 0x4B4D28F: (within /usr/lib64/opengl/ati/lib/libGL.so.1.2)
==29383==
==29383==
==29383== 1,080 bytes in 1 blocks are definitely lost in loss record 50 of 66
==29383==    at 0x4A20D3B: malloc (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==29383==    by 0x67D8D3F: ???
==29383==    by 0x6856590: ???
==29383==    by 0x687E2D0: ???
==29383==    by 0x6873D52: ???
==29383==    by 0x6875573: ???
==29383==    by 0x6877858: ???
==29383==    by 0x637BDC5: ???
==29383==    by 0x6382EB4: ???
==29383==    by 0x60A1C09: ???
==29383==    by 0x650F2CD: ???
==29383==    by 0x650519F: ???
==29383==
==29383==
==29383== 9,384 bytes in 2 blocks are possibly lost in loss record 60 of 66
==29383==    at 0x4A20D3B: malloc (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==29383==    by 0x695EBF8: ???
==29383==    by 0x695E311: ???
==29383==    by 0x695E409: ???
==29383==    by 0x695E227: ???
==29383==    by 0x695E468: ???
==29383==    by 0x66871C9: ???
==29383==    by 0x668861C: ???
==29383==    by 0x69AE77C: ???
==29383==    by 0x69AF0A6: ???
==29383==    by 0x69682A7: ???
==29383==    by 0x69AE32C: ???
==29383==
==29383==
==29383== 537,600 bytes in 700 blocks are definitely lost in loss record 64 of
66
==29383==    at 0x4A1FE4C: calloc (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==29383==    by 0x4B6D227: XF86DRIGetDeviceInfo (in
/usr/lib64/opengl/ati/lib/libGL.so.1.2)
==29383==    by 0x6962257: ???
==29383==    by 0x6965BA8: ???
==29383==    by 0x69C061F: ???
==29383==    by 0x68817DD: ???
==29383==    by 0x6840B51: ???
==29383==    by 0x6876CC8: ???
==29383==    by 0x65339A0: ???
==29383==    by 0x6522486: ???
==29383==    by 0x608E5DB: ???
==29383==    by 0x6261F81: ???
==29383==
==29383== LEAK SUMMARY:
==29383==    definitely lost: 539,254 bytes in 829 blocks.
==29383==    indirectly lost: 3,112 bytes in 18 blocks.
==29383==      possibly lost: 10,076 bytes in 16 blocks.
==29383==    still reachable: 9,616,764 bytes in 1,760 blocks.
==29383==         suppressed: 0 bytes in 0 blocks.
==29383== Reachable blocks (those to which a pointer was found) are not shown.
==29383== To see them, rerun with: --leak-check=full --show-reachable=yes
--29383--  memcheck: sanity checks: 590 cheap, 24 expensive
--29383--  memcheck: auxmaps: 128 auxmap entries (8192k, 8M) in use
--29383--  memcheck: auxmaps: 15725244 searches, 25264583 comparisons
--29383--  memcheck: SMs: n_issued      = 668 (10688k, 10M)
--29383--  memcheck: SMs: n_deissued    = 262 (4192k, 4M)
--29383--  memcheck: SMs: max_noaccess  = 524287 (8388592k, 8191M)
--29383--  memcheck: SMs: max_undefined = 199 (3184k, 3M)
--29383--  memcheck: SMs: max_defined   = 4660 (74560k, 72M)
--29383--  memcheck: SMs: max_non_DSM   = 505 (8080k, 7M)
--29383--  memcheck: max sec V bit nodes:    74 (6k, 0M)
--29383--  memcheck: set_sec_vbits8 calls: 1928 (new: 74, updates: 1854)
--29383--  memcheck: max shadow mem size:   12230k, 11M
--29383-- translate:            fast SP updates identified: 66,366 ( 87.2%)
--29383-- translate:   generic_known SP updates identified: 9,341 ( 12.2%)
--29383-- translate: generic_unknown SP updates identified: 397 (  0.5%)
--29383--     tt/tc: 1,202,943 tt lookups requiring 2,918,569 probes
--29383--     tt/tc: 1,202,943 fast-cache updates, 7 flushes
--29383--  transtab: new        62,513 (2,000,447 -> 33,725,015; ratio 168:10)
[0 scs]
--29383--  transtab: dumped     0 (0 -> ??)
--29383--  transtab: discarded  54,118 (1,803,238 -> ??)
--29383-- scheduler: 59,084,099 jumps (bb entries).
--29383-- scheduler: 590/1,307,513 major/minor sched events.
--29383--    sanity: 591 cheap, 24 expensive checks.
--29383--    exectx: 30,011 lists, 16,067 contexts (avg 0 per list)
--29383--    exectx: 15,593,216 searches, 15,592,474 full compares (999 per
1000)
--29383--    exectx: 61,120,472 cmp2, 2,276,889 cmp4, 0 cmpAll

**************************************************************************

emerge --info 

System uname: 2.6.23-gentoo-r1iommuin x86_64 AMD Athlon(tm) 64 X2 Dual Core
Processor 3800+
Timestamp of tree: Sun, 11 Nov 2007 03:00:01 +0000
app-shells/bash:     3.2_p17
dev-java/java-config: 1.3.7, 2.0.33-r1
dev-lang/python:     2.4.3-r4
dev-python/pycrypto: 2.0.1-r6
sys-apps/baselayout: 1.12.9-r2
sys-apps/sandbox:    1.2.18.1-r2
sys-devel/autoconf:  2.13, 2.61
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.16.1-r3
sys-devel/gcc-config: 1.3.13-r3
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.17-r2
ACCEPT_KEYWORDS="amd64"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config
/usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/revdep-rebuild
/etc/splash /etc/terminfo /etc/udev/rules.d"
CXXFLAGS="-O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans
userfetch"
GENTOO_MIRRORS="http://gentoo.cites.uiuc.edu/pub/gentoo/
http://mirror.datapipe.net/gentoo http://gentoo.chem.wisc.edu/gentoo/
http://mirrors.acm.cs.rpi.edu/gentoo/ http://gentoo.mirrors.tds.net/gentoo"
LINGUAS="en_GB en_US"
MAKEOPTS="-j5"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude=/distfiles --exclude=/local --exclude=/packages
--filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="3dnow 3dnowext X a52 aac acl acpi addbookmarks aim akode alias alsa amd64
ao aoss apache2 arts asf audiofile autoreplace bash-completion bcmath berkdb
bitmap-fonts bluetooth bonobo bzip2 cdaudio cddb cdinstall cdparanoia cdr cli
connectionstatus cracklib crypt cups curl curlwrappers dbus device-mapper
directfb divx dri dv dvb dvd dvdnav dvdr dvdread eds encode exif fam ffmpeg
firefox flac foomaticdb fortran ftp gadu gd gdbm gif gimp gmedia gphoto2 gpm gs
gstreamer gtk2 hddtemp highlight icecast iconv icq ieee1394 image imagemagick
imap imlib ipod ipv6 irc isdnlog jabber java javascript jbig jingle joystick
jpeg jpeg2k kde kdeenablefinal kipi ladspa lame lash lcms lesstif libcaca
libgda libnotify libsamplerate libsexy libwww lm_sensors logitech-mouse
logrotate lua lzo lzw mad midi mikmod mime mmap mmx mmxext mng modplug mozilla
mp2 mp3 mp4 mp4live mpeg mpeg2 mpi mplayer msn mudflap musicbrainz mysqli
ncurses netmeeting new-login nls nntp nowlistening nptl nptlonly ntfs ogg
openal openexr opengl openmp oscar pam pango pcre pda perl php png pnm posix
ppds pppd python qt3 qt4 quicktime rar readline realmedia reflection reiserfs
rtc samba sasl scanner scrobbler sdl session sharedmem simplexml sndfile
sockets speex spell spl sse sse2 ssl svg svgz taglib tcpd texteffect threads
tiff truetype truetype-fonts type1-fonts unicode usb utempter v4l v4l2 vcd
vorbis wifi wma wmf wmp xanim xcomposite xine xorg xpm xscreensaver xv xvid
xvmc yahoo zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106
cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0
intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci"
ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file
hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route
share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse wacom joystick"
KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001
mtxorb ncurses text" LINGUAS="en_GB en_US" USERLAND="GNU" VIDEO_CARDS="ati
radeon fglrx nforce fbdev v4l vesa"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL,
LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

(In reply to comment #124)
> (In reply to comment #123)
> >    Bernd: 
> >    I'm still finding the list of patches in the attachments somewhat confusing:
> >  I think we need to (expire/deprecate/supercede) attachement
> > ati-drivers-2.6.23.patch as it appears that the real source for that file
> > should be from
> > /usr/portage/x11-drivers/ati-drivers/files/8.40.4/ati-drivers-2.6.23.patch in
> > the users system.
> >  and in truth I dont think the one here is identical (leastwise it needs
> > mangling before it will apply cleanly in my build tree - the path depth is
> > wrong)
> > 
> Sorry, I can only mark my own attachments obsolete, you have to ask the
> creators of those patches to do that (or a dev could do that).
> Currently the only patch needed from this page is ati-drivers-2.6.23-2.patch.
> The correct way to install this driver has been described by Markus in comment
> 40.
> 
> BTW:
> Looking at the date (it's the 15th of November!) I guess we can skip this
> driver and look forward to 8.43 which hopefully will be released soon.
> 

  I sure hope things get better in that one -- although I'm starting to suspect
that at least **part** of my issues are related to my system build state .. and
it would be nice to fix that **first** 

Ok, bumped and committed to tree. Works for me on amd64. If you have problems
or etc, please file a new bug or etc. Although I can't say if those problems
will be addressed or not :)

Seems like there was two of the same patches here in bug report. I believe I
had issues with both. So made my own, and used that. Otherwise just bumped
ebuild from 8.40.4. Didn't diff my 8.42.3 with the one in this bug.

If I missed something or etc. Please let me know. Although I think I would
prefer a new bug. This one is getting quite big. Also if anyone needs to
provide allot of output. Please do so via an attachment. That way we can read
comments, without having to scroll for days.

FYI, I tried this already with xorg 1.4/7.3. So far no go, although this
version supposedly has support for that.

Otherwise closing bug since ebuild has been committed to tree :)

(In reply to comment #127)
> Ok, bumped and committed to tree. Works for me on amd64. If you have problems
> or etc, please file a new bug or etc. Although I can't say if those problems
> will be addressed or not :)
> 
> Seems like there was two of the same patches here in bug report. I believe I
> had issues with both. So made my own, and used that. Otherwise just bumped
> ebuild from 8.40.4. Didn't diff my 8.42.3 with the one in this bug.

I'll give you a diff against 8.40.4 and some explanations of the changes, that
I've made (I'll leave the trivial stuff like gunzip and epatch out):
@@ -91,6 +91,23 @@
                die "CONFIG_PARAVIRT enabled"
        fi

+       if linux_chkconfig_present SLUB; then
+               ewarn  "You have selected support for the SLUB allocator.
Suspending is"
+               ewarn  "known to be broken with this allocator and ati-drivers.
If you"
+               ewarn  "need support for Suspend-To-Ram or Suspend-To-Disk,
select SLAB"
+               ewarn  "instead. To do this enable CONFIG_SLAB and disable
CONFIG_SLUB"
+               ewarn  "in /usr/src/linux/.config or select"
+               ewarn  "                General setup  --->"
+               ewarn  "                        Choose SLAB allocator (SLUB) 
--->"
+               ewarn  "                                (X) SLAB"
+               ewarn  "in 'menuconfig'"
+       fi
+
        # xorg-server 1.1 and its prereleases correspond to xorg 7.1.
        if has_version ">=x11-base/xorg-server-1.0.99"; then
                BASE_DIR="${S}/x710"

Comment: Ok, this first hunk is because of a bug of the ati-drivers with the
SLUB allocator, though it is not clear if this only happens if slub is selected
or if it just makes it more likely to happen. The state of the art is, that you
shouldn't activate SLUB if you want to use Suspend and ati-drivers. I thought I
jump that in, although this might be a case of a new bug.



@@ -350,8 +370,10 @@
 src_install-libs() {
        if [[ "${ABI}" == "amd64" ]]; then
                local pkglibdir=lib64
+               local MY_ARCH_DIR="${S}/arch/x86_64"
        else
                local pkglibdir=lib
+               local MY_ARCH_DIR="${S}/arch/x86"
        fi
        einfo "ati tree '${pkglibdir}' -> '$(get_libdir)' on system"

@@ -363,7 +385,7 @@
        # The GLX libraries
        # (yes, this really is "lib" even on amd64/multilib --marienz)
        exeinto ${ATI_ROOT}/lib
-       doexe "${ARCH_DIR}"/usr/X11R6/${pkglibdir}/libGL.so.${libver}
+       doexe "${MY_ARCH_DIR}"/usr/X11R6/${pkglibdir}/libGL.so.${libver}
        dosym libGL.so.${libver} ${ATI_ROOT}/lib/libGL.so.${libmajor}
        dosym libGL.so.${libver} ${ATI_ROOT}/lib/libGL.so
@@ -373,7 +395,7 @@

        # DRI modules, installed into the path used by recent versions of mesa.
        exeinto /usr/$(get_libdir)/dri
-       doexe "${ARCH_DIR}"/usr/X11R6/${pkglibdir}/modules/dri/fglrx_dri.so
+       doexe "${MY_ARCH_DIR}"/usr/X11R6/${pkglibdir}/modules/dri/fglrx_dri.so

        # Make up a libGL.la. Ati does not provide one, but mesa does. If
        # a (libtool-based) libfoo is built with libGL.la present a

Comment: These 3 hunks are needed. Older versions of the ati-drivers provided
32bit libs in the arch/x86_64/usr/X11R6/lib dir. Those are not there anymore,
instead the ati installer installs the normal 32bit libs from
arch/x86/usr/X11R6/lib. This modification gets those 32bit libs installed.
Without this you'll get a warnung during emerge, that some files could be found
and you might have problems with 32bit apps, that use opengl.


@@ -402,6 +424,10 @@
 }

 pkg_postinst() {
+       ewarn "If you experience screen corruption with this driver, try
putting"
+       ewarn '         Option "XAANoOffscreenPixmaps" "true"'
+       ewarn "in the Device Section of /etc/X11/xorg.conf."
+
        /usr/bin/eselect opengl set --use-old ati

        elog "To switch to ATI OpenGL, run \"eselect opengl set ati\""

Comment: This is a warning for the screen corruptions, that a lot of users see,
and a hint how to workaround it. I would really recommend adding this to the
ebuild, since that will save quite some time for some users who experience this
stuff.


Finally I would recommend, as stated before, that you add this package to
package.mask, since there are quite some problems out there. BTW, see comment
40 for the correct way handling the patches. Only the patch from me (2.6.23-2)
is needed in addition to the patches in portage, the others are copies, that
conflict with the patches in portage.
BTW, I'm running this driver with xorg-server-1.4 for some weeks now and it
works fine for me. Didn't expect any problems that could be related to that.
Sorry for another very long post on this bug report.

Sorry for that incredible bug spam, I thought you would make the same mistake
as the Sabayon people did.
Your ebuild of course is ok, so this bug can be closed.

src_unpack() from 8.40.4 still contains code to manually extract the archive
offset, which, as far as I can see, is no longer used. It should probably be
removed.

Closing. Everything else -> a *new* bug. This got incredibly messy.