# 2.6.29 and ATI drivers

## h2sammo

i am thinking of updating but am worried about compatibility with my radeon X1950 card.  any of you had expereince with 2.6.29 and ati drivers and how do they fare?

----------

## ShinyDoofy

I was going to create a thread about the problems I've had with this, so here goes:

last night I updated my kernel from 2.6.28.4 to 2.6.29.1 (both vanilla) and changed my root fs to ext4. Booting went fine, but X won't seem to start anymore. Naturally, I recompiled ati-drivers with the correct symlink (for .29.1) only to find it not working as well. Turns out the drivers won't compile with 2.6.29. So I tried both fixes from bug #264021, both have the same result: black screen and dead keyboard. SSH from another machine and Alt+SysRq+REISUB still work great, but that's about it. As I figured that .28.4 works with ext4 as well, I quickly changed the symlink back and recompiled ati-drivers once more. Booted up .28.4 and I still get the same symptoms although everything else worked perfectly fine with this kernel prior to booting . I have PAT on for .28.4 and off for 29.1 (see the bug).

My system:

Dell Studio 15

2.6.28.4 (again)

ATI Mobility Radeon HD 3450

Xorg.0.log

Anything that could help is highly appreciated!

----------

## scary

Same problem here with gentoo-sources-2.6.29(-r1), with ati-drivers ebuilds both from bugzilla and from gentoo-quebec overlay, toshiba laptop with mobility hd 3470, with and without PAT: X would not start (black screen + dead keyboard), always leading to awful kernel messages (aside from the warnings pretty much everyone is having due the quick and dirty acpi patches involved).

 In my case though eselecting back to 2.6.28-r3 + emerge -C ati-drivers + emerge ati-drivers  (regular ~amd64 from portage) brought me back to an usable system. Did you etc-update whatever had to be etc-updated ?

----------

## ShinyDoofy

Just played back the tarball that I made for changing my root fs and it finally starts X again. I have no clue what caused this strange behavior or how to fix it if it ever pops up again. Guess I'll just tar my root fs before I touch ati-drivers again (or update my kernel) and hope for the best.

----------

## h2sammo

you mean X works in 2.6.28 again? or you got it to work in 2.6.29?

----------

## ShinyDoofy

Nope, in 2.6.28.4. Guess I'll just wait until that bug is closed and/or a new ebuild is out.

----------

## scary

fglrx 9.4 should be out in a week or so... cross your fingers for .29 support :)

----------

## h2sammo

keep us posted

----------

## Hibbelharry

@H2Sammo: You won't have any luck with Catalyst 9.4 since 9.3 was the last one to support your X1950 Card. Only Radeon HD 2000+ Series are supported since 9.4. You will either have to stay with 2.6.28 and Xorg 1.5 or you will need to migrate to open source ati driver which works mostly well nowadays.

Greetz

Hibbelharry

----------

## h2sammo

i have been using fglrx (which i think is the open source driver).  that should work for 2.6.29 right?

is the kernel ok with ATI drivers now?

----------

## VoidMage

 *h2sammo wrote:*   

> i have been using fglrx (which i think is the open source driver)

 

 :Laughing:   :Laughing:   :Laughing:   :Laughing: 

----------

## kornhs4

That might be interesting:

- http://www.pro-linux.de/news/2009/13971.html  --> search for ati-drivers

- http://www.planet3dnow.de/vbulletin/showthread.php?t=359537 --> info über ati-drivers 9.2, 9.3

----------

## ShinyDoofy

 *kornhs4 wrote:*   

> That might be interesting:
> 
> - http://www.pro-linux.de/news/2009/13971.html  --> search for ati-drivers

 This has already been mentioned as a fix in bug 264021. As said, it doesn't work for me.

----------

## psutokth

 *h2sammo wrote:*   

> i have been using fglrx (which i think is the open source driver)

 

driver "fglrx" belongs to x11-drivers/ati-drivers, the closed source driver

driver "radeon" belongs to x11-drivers/xf86-video-ati, the open source driver

----------

## DaggyStyle

 *psutokth wrote:*   

>  *h2sammo wrote:*   i have been using fglrx (which i think is the open source driver) 
> 
> driver "fglrx" belongs to x11-drivers/ati-drivers, the closed source driver
> 
> driver "radeon" belongs to x11-drivers/xf86-video-ati, the open source driver

 

driver "radeonhd" belongs to x11-drivers/xf86-video-radeonhd, another open source driver

----------

## h2sammo

thx for being more helpful than the l33t mage yonder...

----------

## VoidMage

 *h2sammo wrote:*   

> thx for being more helpful than the l33t mage yonder...

 

Well, I'm not particularly fond of you either.

----------

## h2sammo

any news on this front?

----------

## ShinyDoofy

Well, 9.4 was released some days ago and still doesn't compile against kernel 2.6.29. I'm unwilling to try the hacks for it as I don't see myself pumping my root filesystem over the network again just for it to screw my system once more.

----------

## TripleM666

http://www.phoronix.com/forums/showthread.php?t=16173&p=68038

this patch works, and there is no special magic about it. it includes 3 files, which originate from the 2.6.29 kernel, where some stuff is declared, and the atidrivers cant find otherwise now, and the necessary includes and code adaptions.

with these the driver compiles fine (as far as no more errors) and works (9.3 , i didnt tried 9.4). although the usual finetuning of the system is needed (sysrq and obsolete symbols in kernel).

so long,

----------

## kornhs4

 *TripleM666 wrote:*   

> this patch works, and there is no special magic about it. 

 

Thanks! Actually, its not the first patch in the forum. Some poster referred to this patch a bit later: http://liquorix.net/patches/FGLRX-2.6.29-9.2-5.diff

----------

## andretti

I have a X1900 card and installed 2.6.29.1 kernel recently with radeonhd 1.2.4, no problem so far... except very very occasionally it crashes on starting or exiting X. I think I'll try radeonhd 1.2.5 once it's available in portage...

Actually I'm very impressed by the open source radeonhd driver.

----------

## h2sammo

anyone got it to work with the ati driver?

----------

## DaggyStyle

 *h2sammo wrote:*   

> anyone got it to work with the ati driver?

 

there is a ebuild in bugs.gentoo.org but it dishes out alot of errors to dmesg.

----------

## ShinyDoofy

I did some more testing and it turned out that /etc/ati/amdpcsdb is a really critical file to have. When I delete it and start X, my screen dies and I can only REISUB (or log in via ssh and see what's going wrong). When I copy the old file back I had some time ago, everything works well (for kernel  2.6.28.4 and Catalyst 9.4).

Anyway, Catalyst 9.5 running for me for now with kernel 2.6.29.4 with this patch (although it's spamming dmesg with error messages).

/Also, for whatever reason, amdcccle doesn't segfault anymore when starting it.

----------

## milomak

am i having this same problem when I have to set the driver to vesa and when i use startxfce4, the mouse and keyboard is dead?

even though i have settings in /etc/hal/fdi/policy/10-x11-... that work on other distros?

```

[I] x11-drivers/ati-drivers

     Available versions:  [M]8.27.10-r1!s 8.32.5!s!t (~)8.33.6-r1!s!t [M]8.35.5 [M](~)8.36.5 [M]8.39.4 [M]8.40.4 [M](~)8.452 [M]8.471.3 8.552-r2 (~)8.552-r3 (~)8.573-r1 (~)8.582 (~)8.593 {acpi debug doc kernel_linux multilib opengl qt3}

     Installed versions:  8.593(20:04:28 05/22/09)(kernel_linux -acpi -debug)

     Homepage:            http://www.ati.com

     Description:         Ati precompiled drivers for recent chipsets

[I] x11-drivers/xf86-video-ati

     Available versions:  6.6.3 6.8.0-r1 (~)6.9.0 (~)6.10.0 (~)6.11.0 6.12.1-r1 (~)6.12.2 {debug}

     Installed versions:  6.12.2(20:05:20 05/22/09)(-debug)

     Homepage:            http://xorg.freedesktop.org/

     Description:         ATI video driver 

[U] x11-base/xorg-server

     Available versions:  1.3.0.0-r6 (~)1.4.2 (~)1.5.3-r4 1.5.3-r5 (~)1.5.3-r6 {M}(~)1.6.1.901 {M}(~)1.6.1.901-r1 {3dfx debug dmx dri hal input_devices_acecad input_devices_aiptek input_devices_calcomp input_devices_citron input_devices_digitaledge input_devices_dmc input_devices_dynapro input_devices_elo2300 input_devices_elographics input_devices_evdev input_devices_fpit input_devices_hyperpen input_devices_jamstudio input_devices_joystick input_devices_keyboard input_devices_magellan input_devices_microtouch input_devices_mouse input_devices_mutouch input_devices_palmax input_devices_penmount input_devices_spaceorb input_devices_summa input_devices_synaptics input_devices_tek4957 input_devices_tslib input_devices_ur98 input_devices_virtualbox input_devices_vmmouse input_devices_void input_devices_wacom ipv6 kdrive minimal nptl sdl tslib video_cards_apm video_cards_ark video_cards_ast video_cards_chips video_cards_cirrus video_cards_cyrix video_cards_dummy video_cards_epson video_cards_fbdev video_cards_fglrx video_cards_geode video_cards_glint video_cards_i128 video_cards_i740 video_cards_impact video_cards_imstt video_cards_intel video_cards_mach64 video_cards_mga video_cards_neomagic video_cards_newport video_cards_nsc video_cards_nv video_cards_nvidia video_cards_r128 video_cards_radeon video_cards_radeonhd video_cards_rendition video_cards_s3 video_cards_s3virge video_cards_savage video_cards_siliconmotion video_cards_sis video_cards_sisusb video_cards_sunbw2 video_cards_suncg14 video_cards_suncg3 video_cards_suncg6 video_cards_sunffb video_cards_sunleo video_cards_suntcx video_cards_tdfx video_cards_tga video_cards_trident video_cards_tseng video_cards_v4l video_cards_vermilion video_cards_vesa video_cards_vga video_cards_via video_cards_virtualbox video_cards_vmware video_cards_voodoo video_cards_xgi xorg}

     Installed versions:  1.6.1.901(02:07:43 05/22/09)(hal input_devices_evdev input_devices_keyboard input_devices_mouse ipv6 nptl video_cards_fglrx video_cards_radeon video_cards_radeonhd video_cards_v4l video_cards_vesa xorg -debug -dmx -input_devices_acecad -input_devices_aiptek -input_devices_calcomp -input_devices_citron -input_devices_digitaledge -input_devices_dmc -input_devices_dynapro -input_devices_elo2300 -input_devices_elographics -input_devices_fpit -input_devices_hyperpen -input_devices_jamstudio -input_devices_joystick -input_devices_magellan -input_devices_microtouch -input_devices_mutouch -input_devices_palmax -input_devices_penmount -input_devices_spaceorb -input_devices_summa -input_devices_synaptics -input_devices_tek4957 -input_devices_tslib -input_devices_ur98 -input_devices_virtualbox -input_devices_vmmouse -input_devices_void -input_devices_wacom -kdrive -minimal -sdl -tslib -video_cards_apm -video_cards_ark -video_cards_ast -video_cards_chips -video_cards_cirrus -video_cards_dummy -video_cards_epson -video_cards_fbdev -video_cards_geode -video_cards_glint -video_cards_i128 -video_cards_i740 -video_cards_impact -video_cards_imstt -video_cards_intel -video_cards_mach64 -video_cards_mga -video_cards_neomagic -video_cards_nv -video_cards_nvidia -video_cards_r128 -video_cards_rendition -video_cards_s3 -video_cards_s3virge -video_cards_savage -video_cards_siliconmotion -video_cards_sis -video_cards_sisusb -video_cards_sunbw2 -video_cards_suncg14 -video_cards_suncg3 -video_cards_suncg6 -video_cards_sunffb -video_cards_sunleo -video_cards_suntcx -video_cards_tdfx -video_cards_tga -video_cards_trident -video_cards_tseng -video_cards_vermilion -video_cards_via -video_cards_virtualbox -video_cards_vmware -video_cards_voodoo -video_cards_xgi)

     Homepage:            http://xorg.freedesktop.org/

     Description:         X.Org X servers
```

----------

## milomak

aaargh, I didn't have hald starting at boot   :Embarassed: 

----------

## eis

Hi everyone!

This is an interesing thread and it seems to at least touch my problem as well. Here it goes:

I use the gentoo 2.6.27-r8 kernel, just as the stable portage tree offers it. 

Ich compiled ati-drivers without errors.

When I set up the xdm (I tried both xdm and slim as the manager), I always get a welcome screen that freezes my whole system. I can only reset. 

In my kernel I chose the following options, just as described in this gentoo-ati-howto.

---

Processor type and features --->

<*> MTRR (Memory Type Range Register) support

Device drivers --->

   Graphics support --->

   <M> /dev/agpgart (AGP Support) --->

      (The agpgart option is not present on 64-bit kernels; just choose your chipset support.)

      <M> Intel 440LX/BX/GX, I8xx and E7x05 support

      (Enable your chipset instead of the above.)

   <M> Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) --->

      <M> (Select your graphics card from the list)

---

I have a 32 bit dell laptop with an ati mobilitiy X300 graphics card.

Does anyone know what I am doing wrong?

greetings,

boris

----------

## milomak

how can i find out what package is trying to pull ati-drivers even though I do not have fglrx in VIDEOCARDS?

----------

## ShinyDoofy

Either use the -t option on emerge or try "equery d ati-drivers"

----------

## eis

hm..

still no solution for my problem. I never really thought about what kernel to use. 

Usually I set all the options by hand, compile and install modules. 

For updates I save the kernel configuration of the old kernel.

Is there a better way to go?

thanks in advance, 

boris

----------

## emuller

 *ShinyDoofy wrote:*   

> I did some more testing and it turned out that /etc/ati/amdpcsdb is a really critical file to have. When I delete it and start X, my screen dies and I can only REISUB (or log in via ssh and see what's going wrong). When I copy the old file back I had some time ago, everything works well (for kernel  2.6.28.4 and Catalyst 9.4).
> 
> Anyway, Catalyst 9.5 running for me for now with kernel 2.6.29.4 with this patch (although it's spamming dmesg with error messages).
> 
> /Also, for whatever reason, amdcccle doesn't segfault anymore when starting it.

 

For exactly this reason, I find it useful to put my fglrx config files under revision control:

cd /etc

hg init .

hg add /etc/X11/xorg.conf

hg add /etc/ati

hg commit

I then commit working amdpcsdb+xorg.conf configs ...

----------

## Snake

I planned to upgrade to 2.6.29 from 2.6.27 in following days, but after seeing that topic, I think I'll stick to good old 27  :Wink:  and wait for 2.6.30 to become stable and hope everything will be ok then.

----------

## VoidMage

@Snake: and just what will that change ? -

it's ati-drivers that are broken, not kernel.

----------

## adrs0061

Im not sure why most here are using the closed source driver and maybe you have valid reasons i dont know but from where i stand i can only say that the opensource drivers (have them running in all of my computers) are the way to go there stable and dont make any hassle when updating the kernel or the xorg-server, and from now on there the only drivers which continue to support R500 and below

and also with all the work which is currently done around ATI KMS and radeon driver gallium 3d support the opensource drivers are definitely the way to go

just wanted to say that because i think most of you would have less problems if you don't need 3D support at the moment with the opensource drivers

regards

----------

## DaggyStyle

 *adrs0061 wrote:*   

> Im not sure why most here are using the closed source driver and maybe you have valid reasons i dont know but from where i stand i can only say that the opensource drivers (have them running in all of my computers) are the way to go there stable and dont make any hassle when updating the kernel or the xorg-server, and from now on there the only drivers which continue to support R500 and below
> 
> and also with all the work which is currently done around ATI KMS and radeon driver gallium 3d support the opensource drivers are definitely the way to go
> 
> just wanted to say that because i think most of you would have less problems if you don't need 3D support at the moment with the opensource drivers
> ...

 

that is why.

----------

## i92guboj

Besides that, both radeonhd and radeon fails miserably for a lot of people, just like fglrx. 

Even if you don't need 3d, you might have the *luck* that only fglrx works for you. The situation of ATi cards is chaotic, as always.

I have a 2600 on one computer, and both radeon and radeonhd crash my server at startup, causing one of my monitors to go standby and similar things. Yeah, ATi is specially daunting on setups with more than one monitor.

----------

## radio_flyer

3D 3D 3D

Not for Compiz. Not for gaming. For engineering. Serious engineering work requires OpenGL.

I've run the radeon driver in the past on a 9200. Great 3D support. Loved it. On my current HD2600XT, I'm running fglrx ( and stuck at 2.6.28 ) because 3D is not optional. I'm running an ATI card solely because I know open-source R600 3D support is coming, thanks to ATI and the X developers. The moment usable open source 3D shows up in either the radeon or radeonhd driver, fglrx is *so* off my system...

----------

## emuller

I am using the AMD Stream SDK, which requires fglrx

For R700 based hardware (4850,4870,4870x2), the fglrx driver can be made to work.  Stick with Xorg 1.5.3 or 1.5.2 for the time being (no >=1.6) and <=2.6.28 kernel.

Funny behaviour is usually due to /etc/ati/amdpcsdb 

Generate your xorg.conf like so:

rm /etc/X11/xorg.conf

touch /etc/X11/xorg.conf

aticonfig --initial --adapter=all -f

But this is not a "fresh" config as the amdpcsdb remains.  Deleting that can sometimes improve the situation.   

Best thing is to keep all this stuff under revision control so one doesn't have to reinstall to get back to a working config ... see above post.

My trouble is I want to get more than two 4870x2 cards working with fglrx for stream computing.  With that, I have not yet succeeded.

----------

## adrs0061

in my experience i had a lot less problems with the opensource radeon driver, at least with the released versions, i dont use the radeonhd much, but i can't speak for anything newer then a RS600 and i don't use any 3D at, and the only experience with two monitor support is the RS600 which works with the radeon driver like a charm

excuse my shortsightedness on some of these issues :S

----------

## h2sammo

so, 2.6.30 was released.

1. does 2.6.29 work with ATI w/out additional tinkering?

2. does 2.6.30 support ATI video cards?

----------

## adrs0061

2.6.30 does support radeon cards up to the R700 with 2D support (opensource), i dont think theres any fglrx support yet

im not sure what u mean with point 1. but theres no official 2.6.29 support within the fglrx driver 

regards

----------

## theRealMorpheu5

According to http://linux.com/community/blogs/ATI-Catalyst-fglrx-and-Kernels-2.6.30-2.6.29.html there seems to be a hope.

Is this happening anytime soon? Is anyone having random lockups (kernel panic with flashing caps-lock light and no more details) when using various xvideo/opengl applications? For example: I cannot play movies with Mplayer or work with Blender for long time since they, sooner or later, make the kernel panic.

EDIT: I'm using ati-drivers-8.593 and all the stable (not keyworded) Xorg things.

EDIT 2: Forgot to mention that I'm happily running kde-4.2.4-r2 with compositing enabled, and glxgears, as well as fgl_glxgears are apparently not causing any crash.

----------

## DevSolar

 *VoidMage wrote:*   

> it's ati-drivers that are broken, not kernel.

 

It's the kernel policy of changing API / ABI between versions on a whim that's broken, and breaking many things for many people for years now.

----------

## nego

I have a ATI Sapphire 3850hd and the open source ati radeon drivers work flawlessly with the automatically generated xorg config. 2d and 3d acceleration work about as well as I've experienced with fglrx drivers. I only tried them after I could not manage to get fglrx working with the latest kernel.

----------

## sylvain_

 *ShinyDoofy wrote:*   

> 
> 
> and Alt+SysRq+REISUB still work great, but that's about it.
> 
> 

 

that's RSEUIB (yeah that dosent fell right)

----------

## DaggyStyle

 *nego wrote:*   

> I have a ATI Sapphire 3850hd and the open source ati radeon drivers work flawlessly with the automatically generated xorg config. 2d and 3d acceleration work about as well as I've experienced with fglrx drivers. I only tried them after I could not manage to get fglrx working with the latest kernel.

 

well both 2d and 3d are software render not hardware render.

there is not software acceleration from these chips.

----------

## energyman76b

with my HD3870, 2.6.29.X, catalyst 9.5&9.6

I need this patch:

diff -Nparu build_mod/firegl_public.c fglrx-8.573-new/common/lib/modules/fglrx/build_mod/firegl_public.c

--- build_mod/firegl_public.c   2009-01-23 20:00:26.000000000 -0200                                     

+++ fglrx-8.573-new/common/lib/modules/fglrx/build_mod/firegl_public.c  2009-02-13 15:25:00.000000000 -0200

@@ -1460,7 +1460,11 @@ KCL_TYPE_Pid ATI_API_CALL KCL_GetTgid(vo                                            

  */                                                                                                       

 KCL_TYPE_Uid ATI_API_CALL KCL_GetEffectiveUid(void)                                                       

 {                                                                                                         

+#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,2 :Cool: 

+    return current->cred->euid;                                                                           

+#else                                                                                                     

     return current->euid;                                                                                 

+#endif                                                                                                    

 }                                                                                                         

 /** /brief Delay execution for the specified number of microseconds                                       

@@ -1832,15 +1836,30 @@ int ATI_API_CALL KCL_PosixSecurityCapChe                                           

  */                                                                                                       

 void ATI_API_CALL KCL_PosixSecurityCapSetIPCLock(unsigned int lock)                                       

 {                                                                                                         

+                                                                                                          

+#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,2 :Cool: 

+    struct cred *new = prepare_creds();                                                                   

+    if (!new) {                                                                                           

+           printk(KERN_ERR "fglrx: could not allocate memory\n");                                         

+           return;                                                                                        

+    }                                                                                                     

+#else                                                                                                     

+#define new current                                                                                       

+#endif                                                                                                    

     if (lock == 0 )                                                                                       

     {                                                                                                     

-        cap_lower(current->cap_effective, CAP_IPC_LOCK);                                                  

+        cap_lower(new->cap_effective, CAP_IPC_LOCK);                                                      

     }                                                                                                     

     else                                                                                                  

     {                                                                                                     

-        cap_raise(current->cap_effective, CAP_IPC_LOCK);                                                  

+        cap_raise(new->cap_effective, CAP_IPC_LOCK);                                                      

     }                                                                                                     

-    return;

+

+#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,2 :Cool: 

+    commit_creds(new);

+#else

+#undef new

+#endif

 }

 /** \brief Get number of available RAM pages

diff -Nparu build_mod/firegl_public.h fglrx-8.573-new/common/lib/modules/fglrx/build_mod/firegl_public.h

--- build_mod/firegl_public.h   2009-01-23 20:00:26.000000000 -0200

+++ fglrx-8.573-new/common/lib/modules/fglrx/build_mod/firegl_public.h  2009-02-16 14:02:50.000000000 -0300

@@ -18,6 +18,7 @@

 #define _FIREGL_PUBLIC_H_

 #include <stdarg.h>

+#include <asm/pgtable.h>

 #include "kcl_pci.h"

 #include "kcl_io.h"

@@ -590,6 +591,11 @@ extern unsigned long        KCL_SYSINFO_

 #define cpu_has_pge test_bit(X86_FEATURE_PGE, &boot_cpu_data.x86_capability)

 #endif

+#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,2 :Cool: 

+#undef pgprot_writecombine

+#undef pgprot_noncached

+#endif

+

 #ifndef pgprot_writecombine

 #define pgprot_writecombine(prot) __pgprot((pgprot_val(prot) & ~(_PAGE_PCD)) | _PAGE_PWT)

 #endif

@@ -598,6 +604,7 @@ extern unsigned long        KCL_SYSINFO_

 #define pgprot_noncached(prot) __pgprot(pgprot_val(prot) | _PAGE_PCD | _PAGE_PWT)

 #endif

+

 #endif //FIREGL_USWC_SUPPORT

diff -Nparu build_mod/kcl_acpi.c fglrx-8.573-new/common/lib/modules/fglrx/build_mod/kcl_acpi.c

--- build_mod/kcl_acpi.c        2009-01-23 20:00:26.000000000 -0200

+++ fglrx-8.573-new/common/lib/modules/fglrx/build_mod/kcl_acpi.c       2009-02-13 15:25:00.000000000 -0200

@@ -18,6 +18,12 @@

 #include <linux/autoconf.h>

 #include <linux/acpi.h>

+#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,2 :Cool: 

+#include <../drivers/acpi/acpica/acconfig.h>

+#include <../drivers/acpi/acpica/aclocal.h>

+#include <../drivers/acpi/acpica/acobject.h>

+#endif

+

 #include "kcl_config.h"

 #include "kcl_type.h"

 #include "kcl_acpi.h"

 #include "kcl_acpi.h"

after that 3d&co works but dmesg is spammed with this:

[14734.504469] [fglrx:firegl_find_any_map] *ERROR* Invalid map handle!<3>[fglrx:drm_vm_open] *ERROR* map not found -> inconsistent kernel data!!! vma_start:0x7fde13660000,handle:0xfdff0000

[14734.506516] [fglrx:firegl_find_any_map] *ERROR* Invalid map handle!<3>[fglrx:drm_vm_open] *ERROR* map not found -> inconsistent kernel data!!! vma_start:0x7fde12dbf000,handle:0xd11ac000

[14734.510144] [fglrx:firegl_find_any_map] *ERROR* Invalid map handle!<3>[fglrx:drm_vm_close] *ERROR* map not found -> inconsistent kernel data!!! vma_start:0x7fde12dbf000,handle:0xd11ac000

[14735.026129] [fglrx:firegl_find_any_map] *ERROR* Invalid map handle!<3>[fglrx:drm_vm_open] *ERROR* map not found -> inconsistent kernel data!!! vma_start:0x7fddf7d4d000,handle:0xd11f4000

----------

## i92guboj

 *DevSolar wrote:*   

>  *VoidMage wrote:*   it's ati-drivers that are broken, not kernel. 
> 
> It's the kernel policy of changing API / ABI between versions on a whim that's broken, and breaking many things for many people for years now.

 

That's completely irrelevant. The kernel development can't remain stagnated due to the release cycles of external projects (and much less when they're closed source projects and the kernel developers can't do anything about that). So your solution would be holding back the whole community because ATI -whom don't even belong to this opensource community- can't keep the pace? I hope that on a second guess you don't really think that way.

When the api breaks is for a good reason, because *something* is happening in that regard in the kernel, like kms and a lot of other goodies that are coming into scene right now. It's not like the developers enjoy breaking the api to annoy the external developers... 

Blame ATi or use an older kernel. They are well known because they always lag behind the kernel and xorg. nVidia can keep the pace and so should ATi, it's just that their driver is such a blob that not even them can maintain it within a reasonable time frame.

----------

## DevSolar

 *i92guboj wrote:*   

>  *DevSolar wrote:*    *VoidMage wrote:*   it's ati-drivers that are broken, not kernel. 
> 
> It's the kernel policy of changing API / ABI between versions on a whim that's broken, and breaking many things for many people for years now. 
> 
> That's completely irrelevant.

 

I actually believe that to be very relevant, nay, at the core of what deficencies Linux still has before it can be a truly great OS.

 *Quote:*   

> The kernel development can't remain stagnated due to the release cycles of external projects (and much less when they're closed source projects and the kernel developers can't do anything about that).

 

Stable / backward-compatible / legacy-supported APIs != stagnated development.

Forward compatible / extensible API design, clean upgrade paths and testing phases including third-party vendors == good software engineering.

(This isn't just targeting the LKM's, but the Gentoo maintainers, too. The latest stable ati-drivers doesn't compile with the latest stable gentoo-sources. So what's "stable" here?)

 *Quote:*   

> So your solution would be holding back the whole community because ATI -whom don't even belong to this opensource community- can't keep the pace?

 

First, it doesn't matter squat if someone belongs to "the opensource community" or not. An operating system is about computing productivity, not about philosophy or communities.

Second, you are talking about "keeping the pace". Was there advance warning in due time that a relevant API would change, including comprehensive information about the new API?

Since they did away with the "2.<even> for stable, 2.<uneven> for experimental" scheme, things have gone from bad to worse IMHO.

 *Quote:*   

> When the api breaks is for a good reason, because *something* is happening in that regard in the kernel, like kms and a lot of other goodies that are coming into scene right now.

 

I (and I assume many others here) have, before they bought their hardware, checked that it actually works with Linux. Now it works better for some, but not at all for others.

 *Quote:*   

> It's not like the developers enjoy breaking the api to annoy the external developers...

 

Even if those external developers "don't belong to this community"? I'm not so sure about that.

 *Quote:*   

> Blame ATi or use an older kernel.

 

Will the LKM's provide security patches for my older kernel for, uh, what's usual in the business, two years or so, minimum? Will security patches by other package maintainers be compatible with my older kernel for that time period?

No, they won't.

Thanks to the fact that the LKM's consider a stable API "nonsense" (as documented in /usr/src/linux/Documentation), Linux is, and probably always will be, the OS that breaks every now and again because the kernel gets out of sync with the "supporting cast". XFree86, wireless, now it's the graphics driver. I'm curious as to what it will be next time.

 *Quote:*   

> They are well known because they always lag behind the kernel and xorg. nVidia can keep the pace and so should ATi...

 

Well, back when I last thought about which hardware to buy, it was the other way 'round - if you wanted 3D hardware, ATI was the ticket and nVidia sucked. Such things change, the hardware on my desk doesn't, at least not without investing in new shiny.

I don't say ATI is free of blame. but the LKM's have to accept their share of it.

----------

## DevSolar

Sorry for the diatribe above. I'm just annoyed that, even with the otherwise so superior Gentoo, every update involving the kernel runs the risk of breaking things that previously worked without a hitch.

This time (hello Murphy) it hit me while demonstrating the powers of Portage to a friend. "You see, they test packages for stability, so unless you go ~x86 everything just works" - wham, blam, ati-drivers failed. Such things can ruin your day.

----------

## energyman76b

so don't touch the kernel without informing yourself. That is something you should do anyway.

And about that backward-compatibility, stable api bullshit:

read the stuff in /usr/src/linux/Documentation

read/search the lkml archives.

It has been explained numerous times why it can not be easily done AND is a very bad idea.

Oh - and the userspace api?

That one is stable since 0.X times. You can take a piece of software compiled 15 years ago and run it on todays linux boxes.

----------

## DevSolar

 *energyman76b wrote:*   

> so don't touch the kernel without informing yourself. That is something you should do anyway.

 

Do you? Are you aware of everything that new kernel might break, before you try it?

 *Quote:*   

> And about that backward-compatibility, stable api bullshit:
> 
> read the stuff in /usr/src/linux/Documentation
> 
> read/search the lkml archives.
> ...

 

Why do you assume I haven't, and simply disagree? The LKM's aren't gods, you know, and have been known to utter BS from time to time. (I recommend the part in the LKML FAQ about C++, it's quite funny to watch a bunch of xenophobes trying the FUD game.)

 *Quote:*   

> Oh - and the userspace api?
> 
> That one is stable since 0.X times. You can take a piece of software compiled 15 years ago and run it on todays linux boxes.

 

Yep. Too bad the LKM's don't realize that they have clients that aren't in userspace.

----------

## energyman76b

why should lkml cater to bullshit that is very probably illeagal anyway?

hm? tell me a good reason why they should do it?

And what has xenophobia (funny to accuse such a diverse group as xenophobic) to do with c++? Nothing? Well...

If you stay outside of the kernel, you keep the pieces when something breaks. That simple. Breakage is necessary for progress. 

If you disagree, fine, have a look at that other more 'stable' OS out there, shall we?

AIX?

Mostly dead

Solaris?

Mostly dead

Irix?

Dead

HP-UX?

Mostly dead

and who killed the bunch above?

Linux

do you see a trend?

----------

## DevSolar

 *energyman76b wrote:*   

> why should lkml cater to bullshit that is very probably illeagal anyway?

 

No idea what you're talking about here.

 *Quote:*   

> And what has xenophobia (funny to accuse such a diverse group as xenophobic) to do with c++? Nothing? Well...

 

This is getting grossly OT, but you asked, so I'll answer.

1) Nobody (sane, and to my knowledge) ever asked to "rewrite" the kernel. It was about the ability to write kernel space code in C++.

2) They state it's a bad idea to write a driver in C++ as there is no support for C++, and then they state it's nonsense to make the kernel headers C++ compliant as there are no C++ drivers anyway. Circular logic at its best.

3) Next sentence they state that any kind of C++ compatibility would be ignored anyway because they don't like C++. That's some way to deal with people wanting to support Linux by writing drivers.

4) Then they blurb about "namespace encroaching". How often did new releases of the C++ standard extend the namespace? Hm? While we're at it, how many new releases of the C++ standard were released since the first? And how many new releases of the C standard? Hm? I call BS.

5) Then they quote how "Erik Mouw did a short back-of-the-envelope calculation to show that searching the kernel sources for possible C++ keywords is a nightmare." I quote Erik: "Each of those lines has to be checked for C++ keywords. Assume that you can do about 5 seconds per line (very optimistic)...". Serious, here. C++ introduced about 30 keywords, give or take, and Erik showed a nice 'find' statement to identify the files to be searched. '-exec grep -H <keyword_replacement_candidate> {} \;' to check if the replacement candidate is already used, and '-exec sed -i "s/<keyword>/<keyword_replacement_candidate>/" to do a search & replace. How hard is that? And certainly not 5 seconds per line. I call BS.

6) Then they quote Linus, and here it gets really funny. As for C++ exceptions, there is something called '-fno-exceptions', and it is a constraint many C++ kernel developers have grown to live with. As for his berating anyone writing kernel code in C++ as being some kind of stupid, I'd like to place him in one room with one of the many people who wrote whole kernels in C++, like the AtheOS authors, but I fear his ego won't fit.

Bottom line, if the LKM's can't write efficient C++, that's no problem, everyone has some languages he can and some he can't do. But I find it funny to see such vehement opposition to not putting roadblocks in other people's way who can, and want to. Especially when it comes in the flavors of FUD and BS. Had they simply stated "we don't want to have C++ in kernel space because we don't feel up to it", that'd have been OK with me, but by trying to discredit C++ for kernel work as a whole, they're just being ridiculous.

 *Quote:*   

> If you stay outside of the kernel, you keep the pieces when something breaks. That simple.

 

I got it that this is the policy of the LKM's. That doesn't mean it's a good policy, or that I have to agree.

 *Quote:*   

> Breakage is necessary for progress.

 

One, I don't agree, and two, even breakage can be handled elegantly.

So what do we do about the latest "Gentoo stable" kernel not compiling with the latest "Gentoo stable" ATI driver? Because that's the point where something could be done about the affair. 

 *Quote:*   

> If you disagree, fine, have a look at that other more 'stable' OS out there, shall we? [...] who killed the bunch above?
> 
> Linux
> 
> do you see a trend?

 

Yep. Architecture, policy, even competence doesn't matter when you're the cool kid on the block and the stupid masses love you.

----------

## energyman76b

 *DevSolar wrote:*   

>  *energyman76b wrote:*   why should lkml cater to bullshit that is very probably illeagal anyway? 
> 
> No idea what you're talking about here.
> 
> 

 

then you shouldn't even talk about stable apis or breakage of external modules in the first place. 

 *DevSolar wrote:*   

> 
> 
>  *Quote:*   And what has xenophobia (funny to accuse such a diverse group as xenophobic) to do with c++? Nothing? Well... 
> 
> This is getting grossly OT, but you asked, so I'll answer.
> ...

 

and all that has nothing to do with xenophobia.

Also, c++ is brought up on lkml every 12 month. Just go to the lkml archive of your choice and have a look. There you will find a lot more arguments.

 *DevSolar wrote:*   

> 
> 
>  *Quote:*   If you stay outside of the kernel, you keep the pieces when something breaks. That simple. 
> 
> I got it that this is the policy of the LKM's. That doesn't mean it's a good policy, or that I have to agree.
> ...

 

again, why should the kernel devs slow down development, the kernel or don't fix bugs just because of some external modules? Authors who obviously do not care about the kernel - or their code would not be outside of the kernel.

You don't understand that, right?

 *DevSolar wrote:*   

> 
> 
>  *Quote:*   Breakage is necessary for progress. 
> 
> One, I don't agree, and two, even breakage can be handled elegantly.
> ...

 

sure - it is done between rc1 and -release.

You are outside of the kernel? then go and become part of it and the breakage will be handled for you.

 *DevSolar wrote:*   

> 
> 
> So what do we do about the latest "Gentoo stable" kernel not compiling with the latest "Gentoo stable" ATI driver? Because that's the point where something could be done about the affair. 
> 
> 

 

go to bugs.gentoo.org.

There you findebuilds for the latest ati drivers with all the patches needed to compile the driver with 2.6.29 and 2.6.30.

Linux energy 2.6.30r4 #1 SMP Tue Jun 23 23:52:37 CEST 2009 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ AuthenticAMD GNU/Linux

II) Loading /usr/lib64/xorg/modules/drivers//fglrx_drv.so                                                                                

(II) Module fglrx: vendor="FireGL - ATI Technologies Inc."                                                                                

        compiled for 1.4.99.906, module version = 8.62.4  

that translates to 9.6

why is that not in the tree?

maybe ... man power?

 *DevSolar wrote:*   

> 
> 
>  *Quote:*   If you disagree, fine, have a look at that other more 'stable' OS out there, shall we? [...] who killed the bunch above?
> 
> Linux
> ...

 

wow. The people of the 88% using linux of the TOP500 list must all be idiots compared to you....

which raises the question:

if you hate linux so much, what are you doing here?

----------

## DevSolar

 *energyman76b wrote:*   

>  *DevSolar wrote:*    *energyman76b wrote:*   why should lkml cater to bullshit that is very probably illeagal anyway? 
> 
> No idea what you're talking about here.
> 
>  
> ...

 

Now, please, could we leave the personal out of it? I didn't understand what you consider "probably illegal anyway". On the language level.

I'll cut down on the rest, as it's OT and leading nowhere anyway.

 *Quote:*   

> why is that not in the tree?
> 
> maybe ... man power?

 

Yep. You need that manpower to keep up with the whooping progress of the Linux kernel and the general beauty of an OS built from hundreds of seperate building blocks that are held in sync by prayers, duct tape and thousands of people who actually think that's the right way to do things...

 *Quote:*   

>  *Quote:*   Architecture, policy, even competence doesn't matter when you're the cool kid on the block and the stupid masses love you. 
> 
> wow. The people of the 88% using linux of the TOP500 list must all be idiots compared to you....

 

Actually, with "stupid masses" I wasn't referring to those who calculated a business case out of using Linux but to the GPL / LKM fanboys who take this stuff religiously.

 *Quote:*   

> which raises the question:
> 
> if you hate linux so much, what are you doing here?

 

Because AmigaOS died, and Windows sucks almost as bad, while being a lot more expensive.

----------

## MrMarco

 *energyman76b wrote:*   

> If you disagree, fine, have a look at that other more 'stable' OS out there, shall we?
> 
> AIX?
> 
> Mostly dead
> ...

 

AIX, Solaris, Irix are still up and running in MANY Companys in Germany.

Please stop pushing your own opinion to be the one and only true one and go on speaking about things which you know.

And yes, we understand, that you are a real gpl fanboy. You can stop telling this.

Please come back to the main discussion. Flames about companys, which are not willing to work under the gpl can be placed somewhere.

DevSolar tries to point on a big problem and running around this problem and fingerpointing to someone other isn't a solution.

----------

## energyman76b

 *DevSolar wrote:*   

>  *energyman76b wrote:*    *DevSolar wrote:*    *energyman76b wrote:*   why should lkml cater to bullshit that is very probably illeagal anyway? 
> 
> No idea what you're talking about here.
> 
>  
> ...

 

what are you talking about? the latest ati driver is not in the portage tree because no gentoo dev has dumped the ready-to-go ebuild into the tree yet. That has nothing to do with the kernel. 

Could you stop with the stupid talk?

 *DevSolar wrote:*   

> 
> 
>  *Quote:*    *Quote:*   Architecture, policy, even competence doesn't matter when you're the cool kid on the block and the stupid masses love you. 
> 
> wow. The people of the 88% using linux of the TOP500 list must all be idiots compared to you.... 
> ...

 

and Freebsd does not even have a c86_64 nvidia driver because they refuse to fix some 'bugs' nvidia told them years ago?

If Windows only sucks 'almost as bad' then use windows. It is easy to get legally for a low price - if you know where to look.

----------

## sylvain_

 *energyman76b wrote:*   

> 
> 
> HP-UX?
> 
> Mostly dead

 

not sure about that one. still rolling in computer assisted production management as i'm aware of.

----------

## DevSolar

 *energyman76b wrote:*   

>  *Quote:*    *Quote:*   why is that not in the tree?
> 
> maybe ... man power? 
> 
> Yep. You need that manpower to keep up with the whooping progress of the Linux kernel and the general beauty of an OS built from hundreds of seperate building blocks that are held in sync by prayers, duct tape and thousands of people who actually think that's the right way to do things...
> ...

 

Lather, rinse, repeat: The latest "stable" ati-drivers does not compile with the latest "stable" gentoo-sources. That is because the kernel changed its API (again), so yes, it's breaking things for people on the "stable" (!) branch because gentoo-sources and ati-drivers got out of sync.

 *Quote:*   

> Could you stop with the stupid talk?

 

Could you stop with the personal stuff?

 *Quote:*   

> If Windows only sucks 'almost as bad' then use windows. It is easy to get legally for a low price - if you know where to look.

 

Could you please stop pretending I'm an idiot not capable of making return-on-investment calculations for myself, given that I know what I am looking for and you don't? I'm a Linux user, I'm actively helping people out with their Linux-related problems, I submit patches to OpenSource projects when I find bugs.

But that doesn't mean I have to be happy with everything. This "then go and leave us alone" attitude p***es me off no end. Linux got a (structural) problem here, but everyone pointing it out is not-so-politely told to take a hike. Great.

----------

## MrMarco

@DevSolar:

Forget it. He is a fanboy and can't think about the thing, that others may have their own oppinions.

Btw... i'm still missing the RTFM and "man man" answers  :Smile: 

Hey... come on...  :Wink: 

----------

## jserink

 *h2sammo wrote:*   

> i am thinking of updating but am worried about compatibility with my radeon X1950 card.  any of you had expereince with 2.6.29 and ati drivers and how do they fare?

 

I gave the ati-drivers the boot for that very reason.

I'm using the xf86-video-ati drivers now on my M56 x1600 amd64 and they work fine. Only thing that doesn't work is google earth.

I no longer have drama when updating a kernel nor do I have to hold my breath when I do an emerge -uDp world. Plus, xrandr rocks, makes aticonfig look silly.

Cheers,

John

----------

## milomak

Would it be a problem having all the ati related x11 drivers compiles?

```

x11-drivers/ati-drivers

x11-drivers/xf86-video-ati

x11-drivers/xf86-video-radeonhd

```

----------

## i92guboj

 *milomak wrote:*   

> Would it be a problem having all the ati related x11 drivers compiles?
> 
> ```
> 
> x11-drivers/ati-drivers
> ...

 

Some people have reported that radeon and/or radeonhd can fail to operate properly if ati-drivers is installed. Don't ask me the reason, but I've also experienced that same behavior. I am sure there's an scientific explanation, I am just too bored of all the ati problems to investigate this one.

When I want to give another try to radeon or radeonhd I just quickpkg ati-drivers and xorg-x11 to quickly restore them afterwards.

----------

## jserink

 *DevSolar wrote:*   

> Sorry for the diatribe above. I'm just annoyed that, even with the otherwise so superior Gentoo, every update involving the kernel runs the risk of breaking things that previously worked without a hitch.
> 
> This time (hello Murphy) it hit me while demonstrating the powers of Portage to a friend. "You see, they test packages for stability, so unless you go ~x86 everything just works" - wham, blam, ati-drivers failed. Such things can ruin your day.

 

Why are you blaming Gentoo for the shit ATI-Drivers package?

I had the same problem and finally dumped ATI-Drivers and am running sweet with the xf86-video-ati package. Every new mesa linraries release and drivers release, the glxgears goes higher and higher...EVERYTHING works except googleearth.

AND IT DOESN'T BREAK when I do emerge -uDp world.

Don't use closed source SW and portage works a dream. The ati-drivers are too delicate, my advice is to drop them. The open source radeon driver is in many cases superior.

I made the jump in May and have never looked back. I now look forward to updating the kernel as it always means improved video performance. See here: https://forums.gentoo.org/viewtopic-t-748931-highlight-.html

Cheers,

John

----------

## Karlhungus

I've tried the basic radeon drivers, with awful video performance 

I've got a 

```
VGA compatible controller: ATI Technologies Inc RV530 [Radeon X1600]

```

. Anybody know if radieonhd drivers have better video performance, or is my only option to try?

----------

## DaggyStyle

 *Karlhungus wrote:*   

> I've tried the basic radeon drivers, with awful video performance 
> 
> I've got a 
> 
> ```
> ...

 

strange, I have a r620 chipset, viewing video with the fgrlx was a pain in the ass, using the radeon drivers, I see perfect... check your settings.

----------

## jserink

 *Karlhungus wrote:*   

> I've tried the basic radeon drivers, with awful video performance 
> 
> I've got a 
> 
> ```
> ...

 

Which version of the drivers did you use?

Which xorg server?

Which mesa libraries?

Which kernel?

Reason I ask is that I have a X1600 M56 card in my laptop and it works perfectly.

I'm running the latest unmakes versions of everything on kernel 2.6.29.

----------

## Karlhungus

 *jserink wrote:*   

> Which version of the drivers did you use?

 

```

*  x11-drivers/ati-drivers

      Latest version available: 8.552-r2

      Latest version installed: 8.552-r2

      Size of files: 74,041 kB

      Homepage:      http://www.ati.com

      Description:   Ati precompiled drivers for recent chipsets

      License:       AMD GPL-2 QPL-1.0 as-is

```

 *jserink wrote:*   

> Which xorg server?

 

```

*  x11-base/xorg-server

      Latest version available: 1.5.3-r6

      Latest version installed: 1.5.3-r6

      Size of files: 5,549 kB

      Homepage:      http://xorg.freedesktop.org/

      Description:   X.Org X servers

      License:       xorg-server MIT

```

 *jserink wrote:*   

> Which mesa libraries?

 

```

*  media-libs/mesa

      Latest version available: 7.3-r1

      Latest version installed: 7.3-r1

      Size of files: 3,322 kB

      Homepage:      http://mesa3d.sourceforge.net/

      Description:   OpenGL-like graphic library for Linux

      License:       LGPL-2

```

 *jserink wrote:*   

> Which kernel?

 

Well attempting to use:

```

*  sys-kernel/gentoo-sources

      Latest version available: 2.6.29-r5

      Latest version installed: 2.6.29-r5

      Size of files: 55,375 kB

      Homepage:      http://dev.gentoo.org/~dsd/genpatches

      Description:   Full sources including the Gentoo patchset for the 2.6 kernel tree

      License:       GPL-2

```

Actually using: 2.6.28-r5

 *jserink wrote:*   

> Reason I ask is that I have a X1600 M56 card in my laptop and it works perfectly.
> 
> I'm running the latest unmakes versions of everything on kernel 2.6.29.

 

For what it's worth i don't even believe the propritary drivers are providing me with 3d: 

```

$glxgears

libGL error: open DRM failed (Operation not permitted)

libGL error: reverting to (slow) indirect rendering

XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"

      after 3204 requests (41 known processed) with 0 events remaining.

```

My xorg:

```

$ cat /etc/X11/xorg.conf

Section "ServerLayout"

        Identifier     "X.org Configured"

        Screen      0  "aticonfig-Screen[0]-0" 0 0

        InputDevice    "Mouse0" "CorePointer"

        InputDevice    "Keyboard0" "CoreKeyboard"

EndSection

Section "Files"

        FontPath     "/usr/share/fonts/misc"

        FontPath     "/usr/share/fonts/75dpi"

        FontPath     "/usr/share/fonts/100dpi"

        FontPath     "/usr/share/fonts/TTF"

        FontPath     "/usr/share/fonts/Type1"

EndSection

Section "Module"

        Load  "glx"

        Load  "extmod"

        Load  "xtrap"

        Load  "record"

        Load  "dbe"

        Load  "dri"

EndSection

Section "InputDevice"

        Identifier  "Keyboard0"

        Driver      "kbd"

        Option      "CoreKeyboard"

        Option      "XkbRules" "xorg"

        Option      "XkbModel" "pc102"

EndSection

Section "InputDevice"

        Identifier  "Mouse0"

        Driver      "mouse"

        Option      "Protocol" "auto"

        Option      "Device" "/dev/input/mice"

        Option      "ZAxisMapping" "4 5 6 7"

        Option      "Dev Name" "PS2++ Logitech MX Mouse"

        Option      "Buttons" "7"

        Option      "Resolution" "800"

        Option      "Emulate3Buttons" "no"

EndSection

Section "Monitor"

        Identifier   "aticonfig-Monitor[0]-0"

        Option      "VendorName" "ATI Proprietary Driver"

        Option      "ModelName" "Generic Autodetecting Monitor"

        Option      "DPMS" "true"

        HorizSync   30.0 - 64.0

        VertRefresh 60.0 - 75.0

        #Option     "DPI"   "100 x 100"

EndSection

Section "Device"

        Identifier  "aticonfig-Device[0]-0"

        Driver      "fglrx"

        #Driver      "radeon"

        BusID       "PCI:1:0:0"

        Option      "AGPMode" "8"

        Option      "AGPFastWrite" "True"

        Option      "EnablePageFlip" "True"

EndSection

#Section "dri"

       #Mode 0666

#EndSection

Section "Screen"

        Identifier "aticonfig-Screen[0]-0"

        Device     "aticonfig-Device[0]-0"

        Monitor    "aticonfig-Monitor[0]-0"

        DefaultDepth     24

        SubSection "Display"

                Viewport   0 0

                Depth     24

                Modes     "1920x1080"

        EndSubSection

EndSection

Section "Extensions"

        Option      "Composite" "Enable"

EndSection

```

----------

## DaggyStyle

did eselect the ati opengl implementation?

----------

## jserink

Ah ok.....

Found your problem:

 *Karlhungus wrote:*   

>  *jserink wrote:*   Which version of the drivers did you use? 
> 
> ```
> 
> *  x11-drivers/ati-drivers
> ...

 

Those are the proprietary ati drivers, not the xorg drivers.

The xorg drivers are xf86-video-ati.

You can't mix the two. Do emerge -C ati-drivers then emerge xf86-video-ati.

Make sure your video card is correctly stated in the /etc/make.conf file.

Also, follow my instructions from https://forums.gentoo.org/viewtopic-t-748931-highlight-.html

Cheers,

john

Your mesa librearies are very old....

----------

## i92guboj

According to the xorg.conf posted above, he's using fglrx, so ati-drivers is right.

----------

## red-wolf76

 *jserink wrote:*   

>  *DevSolar wrote:*   Sorry for the diatribe above. I'm just annoyed that, even with the otherwise so superior Gentoo, every update involving the kernel runs the risk of breaking things that previously worked without a hitch.
> 
> This time (hello Murphy) it hit me while demonstrating the powers of Portage to a friend. "You see, they test packages for stability, so unless you go ~x86 everything just works" - wham, blam, ati-drivers failed. Such things can ruin your day. 
> 
> Why are you blaming Gentoo for the shit ATI-Drivers package?

 

Perhaps because it wasn't the ATI-Drivers package that somehow injected itself into the stable tree?

 *Quote:*   

> I had the same problem and finally dumped ATI-Drivers and am running sweet with the xf86-video-ati package. Every new mesa linraries release and drivers release, the glxgears goes higher and higher...EVERYTHING works except googleearth.
> 
> AND IT DOESN'T BREAK when I do emerge -uDp world.

 

Wow! Good for you. Bring on the naked slave-girls and let's have an orgy!

But you're not really helping him with his problem by promoting something else from what he is using. Or are you answering "Oh, just use Gnome. It's ultra-dandy!" in threads that deal with KDE packages not compiling?

In other words: You fail. Try again.

----------

## jserink

[quote="red-wolf76"] *jserink wrote:*   

>  *DevSolar wrote:*    
> 
> Wow! Good for you. Bring on the naked slave-girls and let's have an orgy!
> 
> But you're not really helping him with his problem by promoting something else from what he is using. Or are you answering "Oh, just use Gnome. It's ultra-dandy!" in threads that deal with KDE packages not compiling?
> ...

 

have a good weekend wolfy.

Kisses.

John

----------

## red-wolf76

The only good reply that you could possibly make! Thumbs up!  :Wink: 

Already am having a good week-end. Hope you have the same.

Ciao

----------

## Snake

All praising of open source drivers in this topic made me try them. Of course it didn't go smoothly as it should and I am stuck with partly working drivers. More information is in this topic. Any help much appreciated.

Cheers

----------

## milomak

Is the HD4870 an Rxxx card?

```

 * Messages for package x11-drivers/xf86-video-radeonhd-1.2.5:

 * You will need dri from either a 2.6.30 kernel or x11-drm via git.

 * See http://wiki.x.org/wiki/radeonhd for details
```

----------

## jserink

 *milomak wrote:*   

> Is the HD4870 an Rxxx card?
> 
> ```
> 
>  * Messages for package x11-drivers/xf86-video-radeonhd-1.2.5:
> ...

 

According to here:

http://dri.freedesktop.org/wiki/ATIRadeon

You have a VERY new video card, its not even listed. Its either an R600 based or R700 based card.

if you look here:

http://www.x.org/wiki/RadeonFeature

you'll see the status of the driver sets, it lists both the radeon and the radeonhd drivers.

This will let you know what is known to work and what is not:

http://www.x.org/wiki/RadeonProgram

The radeon and radeonHD trees are slowly being merged. Its likely in a few months the radeonhd driver will no longer exist stand alone.

As your card is so new, you might be better off using the AMD closed source drivers, your call.

However, if you're game to compile by unmasking packages and are using a VERY recent kernel, give it a go.

the Opensource drivers to prevent the pain when you update your kernel that is always associated with the closed source drivers.

i've used both and when you finally get the closed source drivers to work, they are great. but they usually break after a kernel upgrade so touch call.

Cheers and good luck.

John

Cheers,

John

----------

## DaggyStyle

can you post a link that says both drivers are merging?

----------

## jserink

 *DaggyStyle wrote:*   

> can you post a link that says both drivers are merging?

 

Search the xf86-video-ati mailing list.

You'll see many posts from the developers stating that.

Cheers,

John

----------

## Snake

AMD finally released Catalyst drivers which support 2.6.29 and 2.6.30 kernel.

Meanwhile I've already changed to open source drivers, which are working fine, but some artefacts are shown here and there. Anyone with similar problem?

----------

## stalker

I've seen that with 9.7 on 2.6.28. So it's not open source specific. But I do seem to think it's more when I switch terminals. I can't remember what else causes mine to do that.

----------

## h2sammo

 *Hibbelharry wrote:*   

> @H2Sammo: You won't have any luck with Catalyst 9.4 since 9.3 was the last one to support your X1950 Card. Only Radeon HD 2000+ Series are supported since 9.4. You will either have to stay with 2.6.28 and Xorg 1.5 or you will need to migrate to open source ati driver which works mostly well nowadays.
> 
> Greetz
> 
> Hibbelharry

 

do the portage ati-drivers numbers correspond with the catalyst 9.x, etc enumeration? if not, what catalyst version is portage up to (10.6 is newest - masked) right now.

----------

