NOT [fixed] Re: about firefox ... / dont understand anything [radeon]

LarryT guess.who at
Thu Mar 16 08:53:59 UTC 2006

Freezing is back.
Forget it ! I will try the official iso ! This is too much

LarryT wrote:
> Well, all seem to perfectly work back now :)
> After the hell in this world, comes heaven :-p
> Seems that switching to radeon driver got the issue....
> LarryT wrote:
>> Thank you Mike :)
>> Well, after i read what you wrote, i realize that i could have a look 
>> on the driver used by other os i have on my pc (centos 4 and 4.2 and 
>> fc4) !
>> Centos  uses radeon driver. So i have just swith to radeon driver. So 
>> far so good !
>> Gonna see what happens , now :)
>> thx anyway
>> larry
>> Mike A. Harris wrote:
>>> LarryT wrote:
>>>>> A. Which graphics card are you using?
>>>> ATI Radeon 7000 RV6DL 32mo
>>>>> B. Which drivers for the graphics card are you using?
>>>> Not sur to kown how to get this info :!
>>>> going through system/admin/display :
>>>> "ati - ATI Mach8, Mach32, Mach64 ad Rage XL card"
>>>> Here is the pout put of xorg.conf :
>>>> Section "Device"
>>>>         Identifier  "Videocard0"
>>>>         Driver      "ati"
>>>                        ^^^
>>> The "ati" driver wrapper module is a problem which should be avoided.
>>> Ideally, in the perfect world, you should be able to use the "ati"
>>> wrapper module regardless of what ATI chip family and revision you
>>> have, and it should automatically load the proper actual driver for
>>> you, as all the "ati" module does, is scan your system and determine
>>> what (if any) ATI hardware is present, PCI, AGP, ISA, etc., and if it
>>> finds any, it looks up the device in a list which tells it which
>>> "real" driver to use.  The "real" drivers are "atimisc", "r128", and
>>> "radeon".  It then loads the proper driver, and unloads itself.
>>> Or at least that is the intention of "ati".
>>> Unfortunately, the real world doesn't quite line up with this ideal
>>> situation very well, and there are often PCI IDs which have been added
>>> to the "radeon" driver by one of the many upstream Radeon driver
>>> developers, which were not added to the "ati" wrapper's detection
>>> routines at the same time, resulting in the "ati" wrapper being
>>> unaware of a given chip, when in fact the chip is supported by the
>>> "radeon" driver.
>>> The result is that the "ati" wrapper will be unable to detect some
>>> hardware and reroute it to the "radeon" driver, but if you use the
>>> "radeon" driver directly you avoid the middle man, and avoid that
>>> problem path entirely.
>>> As such, it is very highly recommended to _never_ use the "ati"
>>> wrapper for Radeon hardware, as it is very highly likely to not
>>> be in perfect sync with the actual current Radeon hardware
>>> support.  There are other bugs/problems which have come up in
>>> the "ati" wrapper over time as well, and while they get fixed
>>> eventually, something else inevitably breaks.  It's just an extra
>>> layer of code which can cause unnecessary grief over just using
>>> the proper driver module to begin with:  radeon
>>> If you use "radeon" as the driver, and your video card doesn't work,
>>> don't even bother trying to use "ati", because as I stated above, all
>>> "ati" does, is say "oh, you have a Radeon" and load the "radeon"
>>> driver.  Instead, if the "radeon" driver does not work, file a bug
>>> report in X.Org bugzilla and describe the problem in detail, and
>>> attach your X server log and config file.
>>> Currently, our video detection should detect all supported Radeon
>>> hardware and automatically assign them to the "radeon" driver, all
>>> Rage 128 hardware and automatically assign it to the "r128" driver,
>>> and all Mach64, Rage, RageXL, and older hardware and assign it to
>>> the "ati" wrapper (although I suppose in light of what I said
>>> above, 'atimisc' might be more appropriate, but the problem case
>>> with "ati" has been Radeon hardware, rather than Mach64, so it's
>>> a moot point in practice).
>>> On a final note, I should state that if you ask around, you will get
>>> very different advice about this from some other people perhaps.  Some
>>> people recommend using the "ati" wrapper for all hardware, and that
>>> conflicts with what I am recommending.  People who suggest to use
>>> the "ati" wrapper for all ATI hardware unfortunately have not had
>>> the pleasure of maintaining XFree86 and X.Org X11 in 12 operating
>>> system releases over a period of 5.5 years and discovering just how
>>> unreliable the "ati" wrapper is in the real world.  My advice comes
>>> from experience in action, rather than ideological best-case
>>> wishful thinking of those who recommend the wrapper.  ;o)

Computers are like air conditioners - They stop working properly when 
you open Windows

More information about the fedora-test-list mailing list