Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 196820

Summary: x11-drivers/ati-drivers 8.42 - version bump request
Product: Gentoo Linux Reporter: Sergej Pisarenko <drseergio>
Component: New packagesAssignee: Luca Barbato <lu_zero>
Status: RESOLVED FIXED    
Severity: enhancement CC: algardas, andrea.rizzolo, arthur, auke, baigsabeeh, beschindler, chain, charni, clmason, cycoone, dan.dickey, fcoiffie, follettoonip, gentoo, gentoo, gentoobugs, giovanni.bobbio, infested, it-knodel, junkxamindar, l.mierzwa, loki_val, luigi.mantellini+gentoo, maggu2810, marek, martinfruiz, matt756, mattemod, mimi.vx, natanael.copa, oliver, pesa, quantumsummers, roeland, s, shadow, smc+gbugs, teidakankan, timmy8765, tom, toto, uzytkownik2, vladimir, will.briggs, world.root, x11-drivers, yang
Priority: High Keywords: InVCS
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: patch to remove fgl_glxgears from the 8.42 ebuild
ati-drivers-8.42.3.ebuild
bonus patch
bonus patch
convert 8.40.4 ebuild to 8.42.3
More fixes/cleanups for 2.6.23
More fixes/cleanups for 2.6.23
ati-drivers-2.6.23-2.patch
ati-drivers-8.42.3.ebuild
ati-drivers-8.42.3.ebuild
official ati 2.6.23 support
xorg file
ati-drivers-8.42.3.ebuild

Description Sergej Pisarenko 2007-10-23 18:31:22 UTC
A new version of ATI drivers that finally deliver AIGLX support!

Reproducible: Didn't try

Steps to Reproduce:
Comment 1 Peter Alfredsen (RETIRED) gentoo-dev 2007-10-23 18:39:40 UTC
Oh my God! You just killed a kitten!
http://allen.brooker.gb.net/misc/kitten-0day.jpg
Comment 2 Zak Peirce 2007-10-23 18:47:44 UTC
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
Comment 3 Bernd Steinhauser 2007-10-23 18:55:56 UTC
(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.
Comment 4 Zak Peirce 2007-10-23 19:16:39 UTC
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.
Comment 5 Neil Skrypuch 2007-10-23 19:19:16 UTC
> 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...
Comment 6 Andrea Rizzolo 2007-10-23 19:22:13 UTC
(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
Comment 7 Tony Murray 2007-10-23 19:34:00 UTC
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.
Comment 8 Bernd Steinhauser 2007-10-23 19:36:36 UTC
(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.
Comment 9 Andrea Rizzolo 2007-10-23 19:42:19 UTC
(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
Comment 10 Zak Peirce 2007-10-23 19:42:24 UTC
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 ~ $ 

Comment 11 Zak Peirce 2007-10-23 19:44:00 UTC
Created attachment 134191 [details, diff]
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
Comment 12 Guillaume Infantes 2007-10-23 20:12:47 UTC
Take care! This version does not support FireGL cards, including FireGL Mobility... Still have to wait....
Comment 13 Bernd Steinhauser 2007-10-23 22:05:22 UTC
Created attachment 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
Comment 14 Bernd Steinhauser 2007-10-23 22:39:41 UTC
(In reply to comment #11)
> Created an attachment (id=134191) [edit]
> 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.
Comment 15 Oleg Korsak 2007-10-24 01:12:44 UTC
Created attachment 134203 [details]
bonus patch

this is needed too!
Comment 16 Oleg Korsak 2007-10-24 01:13:01 UTC
Created attachment 134204 [details]
bonus patch

this is needed too!
Comment 17 Oleg Korsak 2007-10-24 01:13:37 UTC
oops... sorry for a double addition :) also please change the ebuild :)
Comment 18 Bernd Steinhauser 2007-10-24 10:02:22 UTC
(In reply to comment #16)
> Created an attachment (id=134204) [edit]
> 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
Comment 19 Ryan Hope 2007-10-24 14:32:50 UTC
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.
Comment 20 Ryan Hope 2007-10-24 14:34:26 UTC
Created attachment 134230 [details, diff]
convert 8.40.4 ebuild to 8.42.3
Comment 21 Ryan Hope 2007-10-24 14:35:14 UTC
Created attachment 134232 [details, diff]
More fixes/cleanups for 2.6.23
Comment 22 Bernd Steinhauser 2007-10-24 15:00:48 UTC
(In reply to comment #20)
> Created an attachment (id=134230) [edit]
> 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).
Comment 23 Bernd Steinhauser 2007-10-24 15:02:46 UTC
Created attachment 134235 [details, diff]
More fixes/cleanups for 2.6.23

Corrected file paths and removed last hunk, that is already contained in the existing patch.
Comment 24 Bernd Steinhauser 2007-10-24 15:03:55 UTC
Created attachment 134236 [details]
ati-drivers-2.6.23-2.patch

Added patch.
Comment 25 Bernd Steinhauser 2007-10-24 15:04:41 UTC
Created attachment 134237 [details]
ati-drivers-8.42.3.ebuild

Sorry, wrong file.
Comment 26 R!tman 2007-10-24 15:30:18 UTC
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'.
 * 
Comment 27 Bernd Steinhauser 2007-10-24 15:48:58 UTC
(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.
Comment 28 Marek Hakala 2007-10-24 15:51:05 UTC
(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
Comment 29 Jared Kidd 2007-10-24 16:58:56 UTC
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.
Comment 30 Olliver Schinagl 2007-10-24 18:00:46 UTC
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.
Comment 31 Bernd Steinhauser 2007-10-24 18:28:05 UTC
(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.
Comment 32 Jared Kidd 2007-10-24 19:31:19 UTC
(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.
Comment 33 Johannes Duschl 2007-10-24 19:50:00 UTC
(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
Comment 34 Bernd Steinhauser 2007-10-24 20:00:37 UTC
(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?
Comment 35 Johannes Duschl 2007-10-24 20:14:09 UTC
(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.

Comment 36 Bernd Steinhauser 2007-10-24 20:44:04 UTC
(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.
Comment 37 Maciej Piechotka 2007-10-24 20:50:18 UTC
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?
Comment 38 Johannes Duschl 2007-10-24 21:07:04 UTC
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. 

Comment 39 Bernd Steinhauser 2007-10-24 21:09:18 UTC
(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.
Comment 40 Markus Rathgeb 2007-10-24 21:33:00 UTC
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
Comment 41 Markus Rathgeb 2007-10-24 21:40:40 UTC
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.
Comment 42 Markus Rathgeb 2007-10-24 21:41:40 UTC
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.
Comment 43 Bernd Steinhauser 2007-10-24 21:59:15 UTC
(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.
Comment 44 Markus Rathgeb 2007-10-24 22:07:28 UTC
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
Comment 45 Maciej Piechotka 2007-10-25 00:12:45 UTC
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?
Comment 46 Arthur Castro 2007-10-25 00:36:19 UTC
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/...
Comment 47 Sabeeh Baig 2007-10-25 02:27:23 UTC
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.
Comment 48 Zach Schimke 2007-10-25 05:43:58 UTC
(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.
Comment 49 Lukasz Goralczyk 2007-10-25 14:02:54 UTC
(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.


Comment 50 Joël 2007-10-25 22:36:36 UTC
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 ? ;-)
Comment 51 teidakankan 2007-10-25 23:38:48 UTC
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.
Comment 52 Tony Murray 2007-10-26 01:23:37 UTC
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.
Comment 53 Bernd Steinhauser 2007-10-26 01:52:05 UTC
(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.
Comment 54 Yang Zhao 2007-10-26 06:23:52 UTC
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.
Comment 55 Yang Zhao 2007-10-26 06:28:10 UTC
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.
Comment 56 Michael Schnake 2007-10-26 06:46:59 UTC
Regarding the missing symlinks, could the SONAME-Bug at
http://ati.cchtml.com/show_bug.cgi?id=843 somehow fool portages install functions?
Comment 57 Markus Rathgeb 2007-10-26 07:40:48 UTC
@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
Comment 58 Bernd Steinhauser 2007-10-26 08:53:58 UTC
(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.
Comment 59 Jakub Moc (RETIRED) gentoo-dev 2007-10-26 09:12:36 UTC
*** Bug 197072 has been marked as a duplicate of this bug. ***
Comment 60 Bernd Steinhauser 2007-10-26 10:44:42 UTC
(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
Comment 61 Yang Zhao 2007-10-26 20:00:04 UTC
(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.
Comment 62 Roeland Douma 2007-10-26 20:39:34 UTC
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.
Comment 63 Sabeeh Baig 2007-10-26 20:49:01 UTC
(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?
Comment 64 Bernd Steinhauser 2007-10-26 21:33:56 UTC
(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...
Comment 65 Roeland Douma 2007-10-27 08:06:32 UTC
(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.
Comment 66 Roeland Douma 2007-10-27 08:59:22 UTC
(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...
Comment 67 Bernd Steinhauser 2007-10-27 09:09:19 UTC
(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.
Comment 68 Bernd Steinhauser 2007-10-27 09:36:55 UTC
Created attachment 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
Comment 69 Luigi 'Comio' Mantellini 2007-10-27 14:12:42 UTC
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
Comment 70 Olliver Schinagl 2007-10-27 14:40:10 UTC
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)
Comment 71 Jory A. Pratt gentoo-dev 2007-10-27 23:25:20 UTC
(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.

Comment 72 Jory A. Pratt gentoo-dev 2007-10-27 23:26:13 UTC
(In reply to comment #15)
> Created an attachment (id=134203) [edit]
> 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.
Comment 73 Jory A. Pratt gentoo-dev 2007-10-27 23:27:46 UTC
(In reply to comment #21)
> Created an attachment (id=134232) [edit]
> 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.
Comment 74 Jory A. Pratt gentoo-dev 2007-10-27 23:49:03 UTC
Created attachment 134516 [details, diff]
official ati 2.6.23 support
Comment 75 Jory A. Pratt gentoo-dev 2007-10-27 23:49:40 UTC
Comment on attachment 134516 [details, diff]
official ati 2.6.23 support

sorry hit wrong key!!!!
Comment 76 Bernd Steinhauser 2007-10-28 10:56:56 UTC
(In reply to comment #74)
> Created an attachment (id=134516) [edit]
> 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.
Comment 77 Jakub Moc (RETIRED) gentoo-dev 2007-10-28 14:18:26 UTC
(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?!
Comment 78 Richard H. 2007-10-28 21:59:15 UTC
Please bump this driver, it's the only one which seems to support the 2400 HD mobility card.
Comment 79 Jakub Moc (RETIRED) gentoo-dev 2007-10-29 06:48:35 UTC
*** Bug 197375 has been marked as a duplicate of this bug. ***
Comment 80 Florian Manschwetus 2007-10-29 11:21:34 UTC
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)
Comment 81 Bernd Steinhauser 2007-10-29 13:29:13 UTC
(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.
Comment 82 MasterX 2007-10-29 17:43:15 UTC
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?
Comment 83 Sabeeh Baig 2007-10-29 18:09:12 UTC
(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.
Comment 84 MasterX 2007-10-29 19:33:34 UTC
Created attachment 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)
Comment 85 Sergej Pisarenko 2007-10-30 17:33:32 UTC
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.
Comment 86 Auke Booij (tulcod) 2007-10-30 17:43:43 UTC
(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
Comment 87 Sergej Pisarenko 2007-10-30 17:57:39 UTC
(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.
Comment 88 Jory A. Pratt gentoo-dev 2007-11-01 12:12:46 UTC
(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. 

Comment 89 Sabeeh Baig 2007-11-01 12:27:25 UTC
Well, 8.42 hasa totally new code base, so it's expected.
Comment 90 Bernd Steinhauser 2007-11-01 12:29:55 UTC
(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.
Comment 91 Joël 2007-11-01 13:21:13 UTC
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 :-)
Comment 92 Epicanis 2007-11-01 19:54:22 UTC
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.
Comment 93 Bernd Steinhauser 2007-11-01 20:16:11 UTC
(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. 
Comment 94 Auke Booij (tulcod) 2007-11-01 20:20:15 UTC
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.
Comment 95 Jonathan Slark 2007-11-02 12:12:53 UTC
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.
Comment 96 Matteo Modesti 2007-11-02 14:30:08 UTC
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 ;)
Comment 97 Bernd Steinhauser 2007-11-02 14:45:52 UTC
(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.).
Comment 98 Epicanis 2007-11-02 22:50:46 UTC
(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?
Comment 99 Olliver Schinagl 2007-11-03 02:07:39 UTC
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.
Comment 100 Jared Kidd 2007-11-03 10:35:44 UTC
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'.
 * 
Comment 101 Bernd Steinhauser 2007-11-03 10:48:50 UTC
(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.
Comment 102 Joël 2007-11-03 15:17:25 UTC
Concerning Comment #98: Well, for me the 8.42.3 driver actually solves the "Google Earth Freezes on Splash Screen" bug !
Comment 103 Jared Kidd 2007-11-03 16:56:44 UTC
> 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'.
 * 
Comment 104 Jared Kidd 2007-11-03 20:19:04 UTC
Please forgive my bonehead post above.  Can I delete my posts?
Comment 105 Ryan Hope 2007-11-04 18:24:32 UTC
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.).
> 

Comment 106 Bernd Steinhauser 2007-11-04 18:54:54 UTC
(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.
Comment 107 Jory A. Pratt gentoo-dev 2007-11-06 12:46:35 UTC
(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.
Comment 108 Daniel Drake (RETIRED) gentoo-dev 2007-11-06 13:15:24 UTC
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.
Comment 109 Matteo Modesti 2007-11-06 15:18:21 UTC
> 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
Comment 110 Bernd Steinhauser 2007-11-06 16:48:45 UTC
(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. ;)
Comment 111 Bernd Steinhauser 2007-11-06 16:59:15 UTC
Created attachment 135344 [details]
ati-drivers-8.42.3.ebuild

Added warnings for usage of the SLUB allocator (suspend is broken) and screen corruptions.
Comment 112 Bernd Steinhauser 2007-11-06 17:01:40 UTC
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\""
Comment 113 xiaoping Gao 2007-11-08 12:25:10 UTC
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?
Comment 114 B. Keroack 2007-11-08 12:43:48 UTC
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
Comment 115 Markus Rathgeb 2007-11-08 17:57:43 UTC
Just a little question:
Why do we collect here driver related bugs?
I thought there is a place for bugs related on gentoo.
Comment 116 Pavel Volkov 2007-11-08 20:38:44 UTC
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)
Comment 117 Auke Booij (tulcod) 2007-11-08 20:42:19 UTC
"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
Comment 118 Alistair 2007-11-14 01:24:53 UTC
(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?
> 
Comment 119 Alistair 2007-11-14 15:05:58 UTC
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?
Comment 120 Bernd Steinhauser 2007-11-14 15:44:36 UTC
(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.
Comment 121 Sabeeh Baig 2007-11-14 17:48:00 UTC
(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.
Comment 122 Alistair 2007-11-15 18:00:05 UTC
(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

Comment 123 Alistair 2007-11-15 18:22:13 UTC
   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)

Comment 124 Bernd Steinhauser 2007-11-15 18:47:43 UTC
(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.
Comment 125 Alistair 2007-11-15 19:02:32 UTC
  (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
Comment 126 Alistair 2007-11-15 19:03:55 UTC
(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** 
Comment 127 William L. Thomson Jr. (RETIRED) gentoo-dev 2007-11-19 01:15:13 UTC
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 :)
Comment 128 Bernd Steinhauser 2007-11-19 01:38:20 UTC
(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.
Comment 129 Bernd Steinhauser 2007-11-19 01:49:18 UTC
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.
Comment 130 Yang Zhao 2007-11-19 02:08:10 UTC
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.
Comment 131 Jakub Moc (RETIRED) gentoo-dev 2007-11-19 06:19:53 UTC
Closing. Everything else -> a *new* bug. This got incredibly messy.