MASTER: fglrx does not support xserver 1.6

Bug #313027 reported by Timo Aaltonen on 2009-01-01
450
This bug affects 39 people
Affects Status Importance Assigned to Milestone
fglrx-installer (Ubuntu)
High
Bryce Harrington
Jaunty
Wishlist
Unassigned

Bug Description

Don't try to install it on jaunty, it won't work until the driver is updated to work with the new ABI.

The workaround is to manually purge fglrx
$ apt-get remove --purge fglrx*
and you can run the open source version with desktop effects until AMD fixes this bug.

And if that doesn't help, do try to purge ati and radeon drivers and reinstall ati
$ apt-get remove --purge xserver-xorg-video-ati
$ apt-get remove --purge xserver-xorg-video-radeon
$ apt-get install xserver-xorg-video-ati

Timo Aaltonen (tjaalton) on 2009-01-01
Changed in fglrx-installer:
importance: Undecided → Wishlist
status: New → Confirmed
Arenlor (arenlor) wrote :

Question, why Wishlist? This is a pretty big bug. It broke one of the pieces of functionality. I'd give it at least Low. Is there a work around to get Desktop Effects working at least? Or did Ubuntu break for an entire user base? If this is Wishlist will it be fixed in time for the April release? This breaking is the very reason I test the Alphas, so that I know that people with my lovely set (b43 and FGLRX) will be supported. What is being done to fix this?

Timo Aaltonen (tjaalton) wrote :

We can't fix it, it's AMD:s responsibility to fix their driver, and they are aware of it.. The same happened during 8.10 cycle, and they released an unofficial driver just for ubuntu a week before release or so.

Bowmore (bowmore) wrote :

> Is there a work around to get Desktop Effects working at least?

The workaround (worked for me) is to manually purge fglrx
$ apt-get remove --purge fglrx*
and you can run the open source version with desktop effects until AMD fixes this bug.

And if that doesn't help, do try to purge ati and radeon drivers and reinstall ati
$ apt-get remove --purge xserver-xorg-video-ati
$ apt-get remove --purge xserver-xorg-video-radeon
$ apt-get install xserver-xorg-video-ati

Sam Liddicott (sam-liddicott) wrote :

Desktop effects can't be enabled in the open source drivers;

further more they are abysmal, it takes about half a second to paint my screen when I switch desktops.

I can see the painting wipe down the screen vertically.

My xorg loaded driver is radeonhd

lspic: 01:05.0 VGA compatible controller: ATI Technologies Inc RS780M/RS780MN [Radeon HD 3200 Graphics]

lspci -vn:
01:05.0 0300: 1002:9612
 Subsystem: 103c:30e3
 Flags: bus master, fast devsel, latency 0, IRQ 11
 Memory at c0000000 (32-bit, prefetchable) [size=256M]
 I/O ports at 5000 [size=256]
 Memory at d6400000 (32-bit, non-prefetchable) [size=64K]
 Memory at d6300000 (32-bit, non-prefetchable) [size=1M]
 Capabilities: [50] Power Management version 3
 Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-

(I'm using 64bit Jaunty, with 2 monitors)

Sam

Sam Liddicott (sam-liddicott) wrote :

Xorg.0.log also said:

(II) RADEONHD(0): Unknown card detected: 0x9612:0x103C:0x30E3.
        If - and only if - your card does not work or does not work optimally
        please contact <email address hidden> to help rectify this.
        Use the subject: 0x9612:0x103C:0x30E3: <name of board>
        and *please* describe the problems you are seeing
        in your message.
(--) RADEONHD(0): Detected an RS780 on an unidentified card
(II) RADEONHD(0): Mapped IO @ 0xd6400000 to 0x7f0851941000 (size 0x00010000)
(II) RADEONHD(0): Getting BIOS copy from legacy VBIOS location
(II) RADEONHD(0): ATOM BIOS Rom:
        SubsystemVendorID: 0x1002 SubsystemID: 0x1002
        IOBaseAddress: 0x5000
        Filename: br29274.bin
        BIOS Bootup Message:
HP_TT2 RS780M DDR2 200e/500m

I don't know if my draw slowness counts as "not work optimally" in the context of the radeonhd driver

Bryce Harrington (bryce) wrote :

The slow performance with compiz may just be bug 320813.

Changed in fglrx-installer:
status: Confirmed → Triaged
description: updated
Bryce Harrington (bryce) on 2009-02-04
Changed in fglrx-installer:
milestone: none → ubuntu-9.04-beta
Changed in fglrx-installer:
assignee: nobody → bryceharrington
Timo Jyrinki (timo-jyrinki) wrote :

The card in question (HD 3200) has currently zero acceleration support in the open source drivers, so it's not a compiz problem. Hopefully with the new documentation available from AMD, the open source driver will soon gather at least some level of acceleration so that people can get rid of the closed source fglrx pain which occurs every release.

For 9.04, one can only wait for updated driver from AMD.

bert07 (marien.bert) wrote :

I have a ATI radeon HD 2400 pro.
I can do nothing but wait.
Somewhere here it was said that the "fix date" target was the beta release of Ubuntu 09.04.
It cannot come too soon.

Though just disabling "fglrx" in "xorg.conf", and adding some info about your own preferences in the "corg.conf" file (e.g.: resolution of your working desktop, lets you keep on working.

I will not file another bug report about this before the release of the first beta. You people know what's going on.
But for working smoothly on a machine running an ATI card, this bug needs to be resolved rather fast.

I do not mean to push. But Ubuntu 08.10 was released too soon too be a stable release.

Hopefully the next release is not about "time", but about "ready" and "finished".

In my opinion 08.10 had not been allowed to be released at that point.
Hopefully 09.04 is what 08.10 should have been.

Bryce Harrington (bryce) wrote :

Update - I've been told that the FOSS -radeon driver will be gaining EXA/Xv support for 6xx/7xx cards in the upcoming 6.12.0 release, which sounds like it will hit in time for us to consider pulling in for Jaunty. If that comes through and is sufficiently stable, it may mitigate the need for -fglrx.

The 6.12.0 driver won't have full 3D functionality, so no compiz unfortunately. But for all basic 2D usage it hopefully should be up to the task.

Of course, -radeonhd also continues to be available as an alternative and should support 6xx/7xx as well.

Martin Pitt (pitti) wrote :

Bryce, thanks for the update. That's in fact the best solution. Do we have a separate bug for tracking the migration of fglrx->ati in update-manager, and updating -radeon to 6.12.0? Or should we use this one?

Bryce Harrington (bryce) wrote :

We can use this one for the fglrx->ati transition. We've got some 6xx/7xx support bugs, which would be better suited for hanging the 6.12.0 FFe on. #325394 possibly.

hunger (hunger) wrote :

For me this bug breaks ubuntu: I have a Radeon HD4670 and the open driver does not produce a picture for me:-(

So for me this is not a wishlist bug.

Tormod Volden (tormodvolden) wrote :

hunger, please file a bug on xserver-xorg-video-ati if it does not produce a picture with your card.

Bryce Harrington (bryce) wrote :

HD4670 is a newer chipset not yet fully supported by -ati 6.11.0. Maybe try -radeonhd or the snapshot of the 6.12.0 development branch in my PPA. See also bug #279762 and bug #336511

bert07 (marien.bert) wrote :

I have a radeon hd 2400 pro and have the same problems.
Jaunty can't run fglrx. If I do, it boots in a screen that is not readable, but the one thing I can make of it, is that it for some reason took a lower colour mode and a lower screen resolution.
From thereon I have to stop the computer because I can not read anything the screen displays.

To make my computer run again, I have to change the xorg.conf file and remove "Driver "fglrx"" in the section "Device". (Using another distro to get into the partition.)

Also when running openSUSE although the still run the 2.6.27 kernel. But there the screen colour varies from almost yellow to green and sometimes even purple. (without fglrx).

Angel Guzman Maeso (shakaran) wrote :

I have a ATI MOBILITY RADEON X600 SE and have the same problems.
Jaunty can't run fglrx.

fglrx BREAK ubuntu, the open source driver not have enough power.

This need to be fixed before 9.04!! Go ATI release your new drivers such as open source!!

+1

Oibaf (oibaf) wrote :

According to phoronix:
http://www.phoronix.com/scan.php?page=news_item&px=NzExOQ
the fglrx driver will drop support for <= R5xx cards in the release compatible with xserver 1.6.

So starting from jaunty fglrx will work only on R600 and R700 cards (Radeon HD 2xxx and later, excluding some 2xxx which). All other users should upgrade to the xserver-xorg-video-ati driver.

Angel Guzman Maeso (shakaran) wrote :

Yeah...amazing (irony)...four years waiting good support for my graphic card in ubuntu and now I can wait a eternity.

The driver open source is my unique hope.

"All other users should upgrade to the xserver-xorg-video-ati driver"

'Upgrade' surely you mean downgrade or regress - my laptop lid switch doesn't work with those drivers and 3D support seems to be lacking and logging faults doesn't seem to lead anywhere (89860). Time for a new laptop me thinks, even though it works a treat it needs a bit more pep.

Tormod Volden (tormodvolden) wrote :

David, didn't you just report in bug 89860 that your lid switch now works (in Jaunty)? The open source 3D support is getting better all the time. Please report separate bugs if there are serious performance issues.

"David, didn't you just report in bug 89860 that your lid switch now works (in Jaunty)?"

Nope, it works with ATI's driver but not with the open source driver, strange wouldn't have thought the graphics driver would have made a difference but it does.

Kẏra (thekyriarchy) wrote :

Could restricted driver manager also suggest open source drivers? I created a wishlist bug 340669

Bryce Harrington (bryce) wrote :

Status update - still waiting on AMD for an -fglrx build for jaunty.

For those on r5xx considering -ati, Canonical has been focusing efforts towards QA for that driver to resolve issues and make it more viable to migrate to. With upstream's help we've reduced the bug count in launchpad from nearly 200 bugs a year ago, to around 100 today. We have some documentation for troubleshooting and resolving several common classes of bugs people encounter, at http://wiki.ubuntu.com/X/Troubleshooting, and are ready to work with you on resolving or forwarding upstream bugs you encounter using -ati.

Tormod Volden (tormodvolden) wrote :

> Canonical has been focusing efforts towards QA for that

Ahem, Canonical _and_ the Ubuntu community, maybe? ;)

Angel Guzman Maeso (shakaran) wrote :

For my card Radeon X600 M24, how can I downgrade to xserver 1.5 with an ATI driver that works? What steps should I follow? Is there any page in the Ubuntu wiki or tutorial?

Ilja Pavkovic (ipavkovic) wrote :

Today I improved my knowledge about the drivers ati and radeon:

For those on r5xx considering -ati and are confused why they use -radeon, "The ati driver is a small wrapper that probes your card and then loads the appropriate driver, either radeon, r128, or atimisc." (see http://www.x.org/wiki/ati ).

For r5xx cards this means the radeon driver from package xserver-xorg-video-radeon is used. Hope this information helps to reduce confusion. At least for me :)

Bryce Harrington (bryce) wrote :

>> Canonical has been focusing efforts towards QA for that
> Ahem, Canonical _and_ the Ubuntu community, maybe? ;)

Oops, sorry, of course what I really meant is, "Canonical thinks this is important enough we've been putting work into it, to supplement the great work being done already by the community." :-)

@Angel, please refer to answers.launchpad.net for that question.

Igor Katalnikov (izia) wrote :

ATI proprietary driver v.8.12 does list Ubuntu/jaunty as supported distribution and also mentions it in the release notes. Tried to install on 20090311.1 daily build with –buildandinstallpkg.
Result: According to Xorg.log DRM module fails to load. Reason: X.org version 7.1 detected. Expected version 7.4.
Kernel module loaded correctly.

Also tried to install on a recompiled from GIT kernel/headers. Initial module build fails. Reason – can not find version.h.

Video card - Radeon 9550 (RV350)

Martin Pitt (pitti) wrote :

AMD is not making any progress for this, and there's little we can do about that beyond the regular nagging on the status calls. We are now focusing on providing the latest free -ati driver which will work on modern chips as well. Please see bug 334101 for details.

Thus I take this off the release blocker list. That doesn't mean that we shouldn't provide a working fglrx driver in jaunty, of course, but it shouldn't be on the release team radar any more.

Changed in fglrx-installer:
milestone: ubuntu-9.04-beta → none
status: Triaged → Won't Fix
assignee: bryceharrington → nobody
Bryce Harrington (bryce) wrote :

I have tested -fglrx 6.80 on an hd2600 and hd4850 with Jaunty and found it works acceptably.

Changed in fglrx-installer (Ubuntu):
importance: Wishlist → High
status: Triaged → In Progress
quequotion (quequotion) wrote :

"We can't fix it, it's AMD:s responsibility to fix their driver, and they are aware of it.. The same happened during 8.10 cycle, and they released an unofficial driver just for ubuntu a week before release or so."

I find this attitude counterproductive and naive.

Not being a developer myself, I can't claim to have pushed the Linux movement forward beyond having reported a few dozen bugs on one forum or another, but isn't an issue like this larger than just one development team?

Of course AMD does need to update their drivers as kernels and x-window servers evolve, but don't the kernel and x-window development teams also have a responsibility to work toward more compatible products?

At the very least this issue is divided two ways: between the AMD development team and the X-Org development team. As I see it, the X-Org team is responsible for developing a more flexible, stable, and compatible server while the AMD team is responsible for making a more universal driver.

It's not productive to say we should "just wait" for one team to work it out, especially one with no obligation to comply.
The AMD team has been great about keeping up with evolving distros, but keep in mind those guys are actually paid for the work which they distribute for free, so the decision to update probably comes from higher-ups who may not see the problem as the driver they've been pouring money into, but the X-Org server which has broken compatibility with it.
The X-Org team, as volunteers, have no obligation to consider proprietary software support in their plans, but at least a few developers do make patches to supplement the main tree for these issues. Why? Lots of reasons, but the most important being: it is necessary and it is good for development. By fixing up the server to be compatible with another driver, proprietary or otherwise, the server becomes a better product.

Also, while I do sincerely hope that the open-source ATI driver will one day offer all the features of the hardware it's designed for, it does not and will not for quite a while yet. From the average user point of view, not the open-source freedom fighter, this driver is a severe downgrade and regression from the proprietary; from the Aunt Tillie point of view, "It don't work." and both are reason enough for many people to give up on the distro entirely, stop testing, stop reporting bugs, and switch to some proprietary operating system that gives them what they want even though it costs much more. That's bad for development and that's bad for Linux, not only Ubuntu.

tl;dr: Doing nothing is never the answer. Dev teams should work toward mutual rather than independent growth for the good of Linux.

Also, regarding the bug: Has anyone had experience compiling their own X-Org server and using the proprietary driver? Is it possible for the X-Org server from Intrepid be forward-ported to Jaunty in the interim? It looks like more data on where exactly this breaks down must be found if the X-Org developers are to come up with a patch OR the AMD developers are going to rework their driver.

fejes (anthony-fejes) wrote :

"I find this attitude counterproductive and naive."

That comment is pretty hurtful to the devs, who volunteer their time (and I'm not one of them). I think you should reconsider your position: either move back to intrepid (where your hardware is supported), wait till the fglrx driver becomes available or look into the open source drivers. No one is forcing you to use jaunty.

The whole premise of your argument is that the fglrx driver isn't being developed fast enough for you, but you can't ask people to fix the fglrx closed source driver - they don't have the source.

You also can't expect them to build support for your card from scratch overnight. Open source support is coming in the radeon and radeonhd drivers, and for many people it's already there.

"At the very least this issue is divided two ways: between the AMD development team and the X-Org development team. As I see it, the X-Org team is responsible for developing a more flexible, stable, and compatible server while the AMD team is responsible for making a more universal driver."

Why do you think you should be allowed to dictate the priorities of the X-Org team? And why do you think you should be able to enforce anything on the AMD team who have put out a binary blob? If you want stability, use the open source drivers, where these issues don't come up.

You might want to take note that the comparable nvidia driver was already released last month, so if anyone has the right to complain about the shifting API, it should be the nvidia crew, who seem to be putting the most effort into keeping up with it - but I don't seem to be hearing any grumbling coming from them anywhere.

I have also heard that AMD has also been very supportive of providing documentation for the development of open source drivers for their hardware - I think you can see where the priorities will be shifting in the future.

At any rate, I think there are several viable solutions available to you, depending on your hardware. This afternoon, I discovered that removing all of the fglrx packages and switching to ati (radeon) driver actually gave me better performance on my card than fglrx ever did, and allowed me to get compiz running again. (You can find instructions on how to do this on several forums and wikis...)

So, rather than complaining about the closed source drives, give the open source ones a shot - you might be surprised at how much these people have already done with the resources available to them.

Meanwhile, if you want the driver put out by ATI, you'll either have to send letters to *them* to hurry up, or you can join the rest of the people and "just wait". (=

fejes, I think you have misunderstood quequotion's point of view:

His opinion is that the X-Server that is used in Jaunty should be held back on this release until the fglrx drivers have had time to catch up and are compatible. He was neither criticising the X developers not the STI team but stating their point of view thus explaining why releasing the older version of X would be the saner point of view.

One could argue that Ubuntu's only priority should be the open drivers and that the closed source drivers should be secondary but that is somewhat a closed perspective as it does seem to me that most use the closed drivers as they are superior to the open ones. This does not help the development of the open drivers but is an unavoidable way that things work.

One could also argue that if the ATI team do not have the imputus to develop for the new version of X (because no one is using that version of X) they never will and X will become stagnant. I do not see this as the case as the fglrx drivers have continued development with no other impetus than normal market forces and I don't see that changing.

My point (and quequotion's) being is that holding back X should be considered as it would aid to stability and compatibility with the X server that we have at the moment.

Pavel Kuzin (pk-nodex) on 2009-03-17
Changed in fglrx-installer:
status: Won't Fix → Confirmed
Martin Pitt (pitti) on 2009-03-17
Changed in fglrx-installer (Ubuntu Jaunty):
status: Confirmed → Won't Fix
Allcolor-g (allcolor) wrote :

Hi,
and where the fglrx 6.80 can be found ? The latest available driver on amd site ( http://support.amd.com/US/GPUDOWNLOAD/linux/Pages/radeon_linux.aspx?type=2.4.1&product=2.4.1.3.1&lang=English ) are the catalyst 9.2. And these does not work, X launch in low res mode and in Xorg log it is said that the driver is not compatible with the xserver version.

Thanks

fejes (anthony-fejes) wrote :

Hi David,

I think we all understood your (and quequotion's) point, but the heart of the matter (in my mind) is that jaunty is not yet final release software, so why should it feel constrained to being a stable release? Presumably the dev team is building into it the functionality that they believe will be stable by the time it is released. It's just hardly fair to suggest that they should wait for the closed source functionality to exist before migrating to the new XOrg, when there's a pretty good chance the drivers will follow in short order.

If you'd like stability, should you be running an alpha release of your OS?

Bryce Harrington (bryce) wrote :

Take it to the discussion forums guys.

Bryce Harrington (bryce) wrote :

Also, to clear up one point, I've been working directly with ATI on their scheduling for ensuring we get an -fglrx for Jaunty since before Jaunty started.

Regarding the proprietary/foss stuff and so on, that's off topic for this bug and just adds clutter. Better to discuss all that on the forums.

Jakub Caban (kuba-iluvatar) wrote :

Bruce, how about you post:

"I have tested -fglrx 6.80 on an hd2600 and hd4850 with Jaunty and found it works acceptably."

If we can use it somehow now please post any details, e.g. where/how to get it?

Jakub Caban (kuba-iluvatar) wrote :

Bryce, how about you post:

"I have tested -fglrx 6.80 on an hd2600 and hd4850 with Jaunty and found it works acceptably."

If we can use it somehow now please post any details, e.g. where/how to get it?

Bryce Harrington (bryce) wrote :

Uploading 8.600 now

Changed in fglrx-installer (Ubuntu):
status: In Progress → Fix Committed
Changed in fglrx-installer:
status: Won't Fix → Fix Released
Bryce Harrington (bryce) on 2009-03-19
Changed in fglrx-installer (Ubuntu Jaunty):
status: Fix Released → Won't Fix
Changed in fglrx-installer (Ubuntu):
status: Fix Committed → Fix Released
28 comments hidden view all 108 comments
Angel Guzman Maeso (shakaran) wrote :

@Sam Liddicott
it didn't work, i get BSOD with Option "TexturedVideo" "off" or Option "TexturedVideo" "on"
I back to mesa, another ideas?

Bryce Harrington (bryce) wrote :

> Why isn't there the possibility in Ubuntu to choose older versions of xorg and fglrx with a new release?

ROTFL.

RV560:
root@bkb-desktop:~# modprobe fglrx
WARNING: All config files need .conf: /etc/modprobe.d/fglrx, it will be ignored in a future release.
WARNING: All config files need .conf: /etc/modprobe.d/nvidia-kernel-nkc, it will be ignored in a future release.
FATAL: Error inserting fglrx (/lib/modules/2.6.28-11-generic/updates/dkms/fglrx.ko): Cannot allocate memory
root@bkb-desktop:~# dmesg | tail
[ 283.514906] [fglrx:firegl_init_device_list] *ERROR* Out of memory when allocating device heads
[ 283.514948] [fglrx:firegl_init_module] *ERROR* firegl_init_devices failed
[ 307.346368] [fglrx] Maximum main memory to use for locked dma buffers: 1886 MBytes.
[ 307.346589] [fglrx:drm_alloc] *ERROR* [driver] Allocating 0 bytes
[ 307.346630] [fglrx:firegl_init_device_list] *ERROR* Out of memory when allocating device heads
[ 307.346669] [fglrx:firegl_init_module] *ERROR* firegl_init_devices failed
[ 319.440311] [fglrx] Maximum main memory to use for locked dma buffers: 1886 MBytes.
[ 319.440532] [fglrx:drm_alloc] *ERROR* [driver] Allocating 0 bytes
[ 319.440572] [fglrx:firegl_init_device_list] *ERROR* Out of memory when allocating device heads
[ 319.440611] [fglrx:firegl_init_module] *ERROR* firegl_init_devices failed

hardhu (qzerty) wrote :

  Bryce Harrington wrote 23 minutes ago: (permalink)

>> Why isn't there the possibility in Ubuntu to choose older versions of xorg and fglrx with a new release?

>ROTFL.

In this is Ubuntu developers attitude, I understand why bug #1 is still open...

Konstantin Bukharov wrote:
> RV560:
> root@bkb-desktop:~# modprobe fglrx
> WARNING: All config files need .conf: /etc/modprobe.d/fglrx, it will be ignored in a future release.
> WARNING: All config files need .conf: /etc/modprobe.d/nvidia-kernel-nkc, it will be ignored in a future release.
> FATAL: Error inserting fglrx (/lib/modules/2.6.28-11-generic/updates/dkms/fglrx.ko): Cannot allocate memory
> root@bkb-desktop:~# dmesg | tail
> [ 283.514906] [fglrx:firegl_init_device_list] *ERROR* Out of memory when allocating device heads
> [ 283.514948] [fglrx:firegl_init_module] *ERROR* firegl_init_devices failed
> [ 307.346368] [fglrx] Maximum main memory to use for locked dma buffers: 1886 MBytes.
> [ 307.346589] [fglrx:drm_alloc] *ERROR* [driver] Allocating 0 bytes
> [ 307.346630] [fglrx:firegl_init_device_list] *ERROR* Out of memory when allocating device heads
> [ 307.346669] [fglrx:firegl_init_module] *ERROR* firegl_init_devices failed
> [ 319.440311] [fglrx] Maximum main memory to use for locked dma buffers: 1886 MBytes.
> [ 319.440532] [fglrx:drm_alloc] *ERROR* [driver] Allocating 0 bytes
> [ 319.440572] [fglrx:firegl_init_device_list] *ERROR* Out of memory when allocating device heads
> [ 319.440611] [fglrx:firegl_init_module] *ERROR* firegl_init_devices failed
>

is this after a reboot? What does lsmod | grep radeon show? or lsmod |
grep drm

I got out of memory errors when I tried to modprobe drm while fglrx was
loaded, so maybe a similar cause?

Sam

Sam Liddicott (sam-liddicott) wrote :

hardhu wrote:
> Bryce Harrington wrote 23 minutes ago: (permalink)
>
>>> Why isn't there the possibility in Ubuntu to choose older versions of
>>>
> xorg and fglrx with a new release?
>
>
>> ROTFL.
>>
>
> In this is Ubuntu developers attitude, I understand why bug #1 is still
> open..

guys.... intrepid still works...

and remember it's closed-source-ati that isn't supported - and lets
think how long ago it was since ati got any money for that card - how
long should they support it? I think they've given value for money.

However, the open source drivers _are_ being worked on for your card,
and this is how bug #1 is being fixed.

Sam

Tormod Volden (tormodvolden) wrote :

Please note that the new fglrx does not support R5xx cards, only R6xx/R7xx. (http://www.phoronix.com/vr.php?view=13559)

ATI/AMD is providing support for R5xx cards through the open-source -ati/-radeon driver.

This bug, "fglrx does not support xserver 1.6", has now been fixed, so please don't spam it with discussions and debugging. File new bug reports for issues that you have, against fglrx-installer if your using fglrx, and against xserver-xorg-video-ati if you are using -ati/-radeon. Again, please check https://wiki.ubuntu.com/X/Troubleshooting/FglrxInteferesWithRadeonDriver if you have trouble switching to -ati/-radeon.

Bryce Harrington (bryce) wrote :
Download full text (7.2 KiB)

On Thu, Mar 19, 2009 at 09:57:51PM -0000, Sam Liddicott wrote:
> hardhu wrote:
> > Bryce Harrington wrote 23 minutes ago: (permalink)
> >>> Why isn't there the possibility in Ubuntu to choose older versions of
> >>> xorg and fglrx with a new release?
> >> ROTFL.
> > In this is Ubuntu developers attitude, I understand why bug #1 is still
> > open..
>
> guys.... intrepid still works...
>
> and remember it's closed-source-ati that isn't supported - and lets
> think how long ago it was since ati got any money for that card - how
> long should they support it? I think they've given value for money.
>
> However, the open source drivers _are_ being worked on for your card,
> and this is how bug #1 is being fixed.

Thanks, that's a better answer than mine. It's been a busy week for me
as you can imagine.

The fact is, with -fglrx being a binary proprietary driver, we're
limited in what we can do. There are of course some legal limitations
due to the licensing, but also some real technical limitations.

Let me explain just one.

All software communicates via standardized protocols and interfaces.
Video drivers also have specific interfaces they use to talk to the X
server, its libraries, and the underlying Linux kernel. Over time these
interfaces evolve.

We can broadly divide these evolutions into two classes: code (API)
incompatibility, and binary (ABI) incompatibility.

Code incompatibility means that ALL of the drivers must be recoded to be
usable with the new X server. It can be caused, for example, if a
function that used to take one argument, now takes too. E.g.,
foo(bar) changes to foo(bar, baz). This affects even open source
drivers!

The good news with open source is that generally whomever introduces the
breakage, at least then goes through all of the video drivers hosted at
freedesktop.org and fixes them. As you can imagine, the X developers
strive to avoid these kinds of breakages, since they're a lot of work.

Proprietary drivers are not hosted at freedesktop.org, obviously, so
don't get this help. Further, the vendors need to keep their ears open
even to hear about the changes, and then must research into what the
change was, and allocate the engineering resources to address it.

Binary incompatible changes are simpler, at least for open source
drivers. These come about when some data structure gets a new field
added, for example. They don't break source code, it just requires a
recompilation of the code. As such, upstream doesn't worry too much
about introducing such changes as they need them, and thus typically
every new xserver release will contain a few of these kinds of changes.

With open source drivers, this ain't a big deal - here at the distro
level we can just queue up rebuilds of all affected drivers... EXCEPT
for binary drivers.

With binary drivers, we don't have the source code, so we can't
recompile them ourselves to address the ABI changes. Instead, we must
wait for the upstream vendors to provide us with re-builds of their
drivers.

This is why when a new Ubuntu gets its new xserver (and/or new kernel),
the binary drivers stop working, and you have to switch to the open
drivers (which get rebuil...

Read more...

l3iggs (l3iggs) wrote :

"Please note that the new fglrx does not support R5xx cards..."

That's a real bummer.

"ATI/AMD is providing support for R5xx cards through the open-source -ati/-radeon driver."

I question the level of support being provided through the -ati/-radeon driver for R5xx cards. -ati is broken with my R580 and it doesn't really seem like anyone cares too much about my bug report (342899).

Bryce Harrington (bryce) wrote :

On Sat, Mar 21, 2009 at 10:51:57PM -0000, l3iggs wrote:
> "ATI/AMD is providing support for R5xx cards through the open-source
> -ati/-radeon driver."
>
> I question the level of support being provided through the -ati/-radeon
> driver for R5xx cards. -ati is broken with my R580 and it doesn't really
> seem like anyone cares too much about my bug report (342899).

Well, you received a reply to your bug from an -ati triager within a day
of your report, which you indicate partially helped. Compared with the
many bugs in Launchpad which never get a reply, it seems you're getting
pretty decent service.

Take care that you don't confuse ATI/AMD's support for bug support in
launchpad. They do not deal directly with ubuntu bug reports, only ones
that we upstream to them.

If you wonder whether we are upstreaming -ati bugs, indeed yes we are.
Look at the upstream report:

  https://bugs.edge.launchpad.net/ubuntu/+upstreamreport

-ati has the highest % bugs upstreamed of all the major video drivers.

AMD employs an engineer to work on -ati bugs, and indeed of the bugs
I've upstreamed, he responds and usually fixes the majority of them.
So you may question their level of support, but I don't!

If you are anxious to get your issue upstreamed, you're welcome to
upstream it yourself. We've documented the guidelines for doing this
here:

  https://wiki.ubuntu.com/X/Triaging#Reporting X issues upstream

Bryce

Phil Hughes (phil-hughes) wrote :

I knew that my card was no longer supported by fglrx in 9.04. However, I went ahead and tried to upgrade from 8.10 to 9.04a6 anyway to see what would happen (it was not on my main computer). The installer correctly identified that my card was not supported by the new fglrx driver. I assumed (incorrectly!) that it would therefore disable the fglrx driver whilst doing the upgrade and went ahead. This left me with an unbootable computer (in graphics mode) until I ran some command line voodoo.

Can I suggest that as a minimum that if the installer detects an unsupported card and fglrx is being used, it refuses to go ahead with the upgrade until the user has switched back to the ati driver. Preferably the installer would do this.

Not being a dev, I don't how easy or possible this is, but is would save a lot of broken upgrades.

Lorenzo Bettini (bettini) wrote :

Bryce Harrington wrote:
> On Thu, Mar 19, 2009 at 09:57:51PM -0000, Sam Liddicott wrote:
>> hardhu wrote:
>>> Bryce Harrington wrote 23 minutes ago: (permalink)
>>>>> Why isn't there the possibility in Ubuntu to choose older versions of
>>>>> xorg and fglrx with a new release?
>>>> ROTFL.
>>> In this is Ubuntu developers attitude, I understand why bug #1 is still
>>> open..
>> guys.... intrepid still works...
>>

Hi
I still have intrepid, but fglrx does not seem to work pretty well: I
mean 3d effects are not very fluent... is there any specific
configuration to add to xorg.conf?

thanks in advance

Oibaf (oibaf) wrote :

There is ongoing effort to improve the open source 3D radeon/r200/r300 drivers (covering all radeon cards up to R500). Specifically for R3xx-R5xx GPU this add OpenGL 1.4 support (vs. OpenGL 1.3 in jaunty) and framebuffer object support. This work is being done in this mesa branch:
http://cgit.freedesktop.org/mesa/mesa/log/?h=radeon-rewrite

Since fglrx dropped support for R3xx-R5xx cards it would be nice to set up a testing PPA for jaunty for this improved driver for users that need these features and no longer can use the fglrx driver.

confirmed the workaround does work.

Milan Satala (milan-satala) wrote :

I have ATI mobility X300 and I find radeon driver performance to be acceptable. However there's another problem that makes the driver unusable for me. It's the lack of support for powerplay technology. Using open-source driver my computer lasts just 1:20h on batter power as opposed to 2:30 on fglrx. I use my laptop on the go and I do need that extra time. Since there's no way to downgrade xserver I'm gonna spend the afternoon reinstalling ubuntu 8.10. If I knew this before the upgrade I wouldn't do it.
I think this "lower battery time on older ati cards issue" should be highlighted somewhere in the upgrade notes. Maybe even on the downloads page once jaunty is out because many new users switching to ubuntu have older hardware.

kulight (kulight) wrote :

how can i install the new fglrx ?

i have a ati x1250 (rs690)

Konstantin Konev (skfd) wrote :

9.2 was a _first_ proprietary ATI driver to work _properly_. And now 9.3 is yet again. Broken.
Well, ATI's 9.3 drivers are said to be the last drivers to support R300. I have Radeon 9600, which is R300. Shouldn't it work in Jaunty for the last time?

So according to ATI, my x2300 (RV550) is no longer supported? This laptop is barely a year old (tho I bought the last one). I honestly consider it a bad move on their part but OK. I wonder if there will be a way around this (like the Mod Utility for the Windows Catalyst drivers which adds support for the cards that are sold by specific vendors, like mine)? RadeonHD doesn't seem to support the new GLX either, rather ridiculous in my opinion.

What about the M series? I just noticed in truth my card is an M64 (x1450/x2300). How will these be supported in the future? I've purged fglrx but now I've got MESA rendering?

l3iggs (l3iggs) wrote :

will fglrx ever support my R580 again?

I mailed ATI tech support about the situation, this is the reply:

Although we have drivers for Linux posted on the ATI website, we do not provide technical support for driver or multimedia issues in Linux directly.

The Linux drivers available (For laptops, RADEON and All in wonder Products) from AMD are provided are "as is".

Is it a good idea to file a bug for the below seperately?

" I knew that my card was no longer supported by fglrx in 9.04. However, I went ahead and tried to upgrade from 8.10 to 9.04a6 anyway to see what would happen (it was not on my main computer). The installer correctly identified that my card was not supported by the new fglrx driver. I assumed (incorrectly!) that it would therefore disable the fglrx driver whilst doing the upgrade and went ahead. This left me with an unbootable computer (in graphics mode) until I ran some command line voodoo.

Can I suggest that as a minimum that if the installer detects an unsupported card and fglrx is being used, it refuses to go ahead with the upgrade until the user has switched back to the ati driver. Preferably the installer would do this.

Not being a dev, I don't how easy or possible this is, but is would save a lot of broken upgrades. "

Phil Hughes (phil-hughes) wrote :

>Is it a good idea to file a bug for the below seperately?
>
>" I knew that my card was no longer supported by fglrx in 9.04. However, I went ahead and tried to upgrade from 8.10 to >9.04a6 anyway to see what would happen (it was not on my main computer). The installer correctly identified that my >card was not supported by the new fglrx driver. I assumed (incorrectly!) that it would therefore disable the fglrx driver >whilst doing the upgrade and went ahead. This left me with an unbootable computer (in graphics mode) until I ran some >command line voodoo.
>
>Can I suggest that as a minimum that if the installer detects an unsupported card and fglrx is being used, it refuses to >go ahead with the upgrade until the user has switched back to the ati driver. Preferably the installer would do this.
>
>Not being a dev, I don't how easy or possible this is, but is would save a lot of broken upgrades. "

I did wonder about this, but on the beta page it says:

"Upgrading a desktop system using an ATI video chipset with the fglrx binary-only driver may result in a warning that the driver needs to be replaced. There is a bug in the driver replacement logic, so if you see this prompt, please cancel the upgrade until this is fixed, which will happen immediately after the beta release. "

so I wondered if this was what it was referring to and they had it covered?

kalimatas (kalimatas) wrote :

There was a question earlier: "Are there any ways to downgrade xserver to 1.5 and to start using fglrx?"

Does anyone know the answer?

hervey (herveyallen) wrote :

I was running Desktop 8.04 on my Lenovo T60 with a an ATI Radeon X1300. I upgraded to Desktop 8.10 in hopes of moving up to Desktop 9.04. Luckily the Upgrade Manager warned me that no 3d support is available for 9.04 - i.e. AMD has not released a usable, proprietary, binary driver to support my hardware. For me this does several things:

* Stops me from upgrading to 9.04.
* Requires that I not purchase AMD/ATI hardware _ever_ again (their support for their hardware under Linux has been simply horrible the entire time I've owned this laptop).
* And, to continue my amazement at the piss-poor PR that AMD/ATI creates for Linux distros and hardware manufacturers everywhere.

My laptop might be 3-year-old technology, but it's much more than capable. The problem is that laptop hardware that's 3-years old is no longer obsolete, but according to ATI it's not worth supporting (i.e., my X1300). Best of luck Ubuntu to applying whatever pressure you can. ATI continues their phenomenal ball-dropping. It's not like I'm on some exotic piece of equipment using some exotic OS - they just _simply don't get it_

Many thanks and best of luck.

Sebastian Urban (surban) wrote :

@hervey:

Your card is well supported by the open source driver including 3d support. There is no reason to be angry at AMD, they are doing excellent work in supporting the open source community by publishing chip data sheets and helping the open source driver developers. I for my part am very happy that AMD positions the open source driver as the primary choice for AMD graphic cards.

I confirm, that specific hardware (T60 with a X1300 chip) is quite well supported by the open source driver. I have practically no special config in my xorg.conf, just the Virtual line required to support multiple screens. I run this on my work laptop. A coworker has a similar system with equally good results.

Aside from that, the only issue is occasional lines or corruption on the secondary (external) screen. I haven't been able to pinpoint it to a particular cause, but it's not really something that's overly annoying either. It stays well enough out of the way to be acceptable -- surely results will improve with new versions of the open source driver.

Thomas Ohms (tohms) wrote :

Sorry for reopening this bug again guys, but still seems to disharm in Jaunty.

I have the following card:
ATI Technologies Inc Mobility Radeon X2300

Tried your suggestions with aticonfig --initial:
"aticonfig: No supported adapters detected"

In Xorg.0.log everything seems fine, but in kdm.log:
"/usr/bin/X: symbol lookup error: /usr/lib/xorg/modules/extensions//libdri.so: undefined symbol: atiddxAbiDixLookupPrivate"

Is it still a bug in xorg-driver-fglrx or in libgl1-mesa-dri??

System starts up fine, but when reaching KDM start display just shows some weird colours and no matter what keys I press, nothing is recognized. Only key that works is off button so at least I can do a clean shutdown.

Changed in fglrx-installer (Ubuntu):
status: Fix Released → New
Oibaf (oibaf) wrote :

> I have the following card:
> ATI Technologies Inc Mobility Radeon X2300

According to the radeon man page the X2300 is a R500 and not supported by the fglrx driver. You should use the radeon driver after removing fglrx.

Sam Liddicott (sam-liddicott) wrote :
  • xorg.conf Edit (1.8 KiB, application/x-extension-conf; name="xorg.conf")

Thomas, here is my xorg.conf file. If I don't use it I get similar
problems to you. Perhaps it will help you.
You may want to simplify it and remove the Virtual line and the extra
monitors.

Even with this config file, after about 48 hours xorg has used up all my
RAM and swap, but at least I can work in the mean-time.

I have:
(--) fglrx(0): Chipset: "ATI Radeon HD 3200 Graphics " (Chipset = 0x9612)
(--) fglrx(0): (PciSubVendor = 0x103c, PciSubDevice = 0x30e3)

(One day radeonhd will support my card properly. I bought AMD instead of
Nvidia because AMD are supporting the open source drivers well. At work
we have now bought more 6 HP ATI laptops because of this AMD support.
Prior to that we were using Dell with nvidia - because nvidia's drivers
are way better than ATI IMHO, but AMD are helping the open source
drivers and they work well enough).

Thomas Ohms (tohms) wrote :

@Fabio: That's strange as it worked perfectly in Intrepid and Hardy before.

@Sam: I'll give it a try, thanks!

Thomas Ohms (tohms) wrote :

@Sam: Didn't work for me, but thanks for new idea. Right now I'm using radeonhd so at least my graphics are shown without errors.

Lorenzo Bettini (bettini) wrote :

@Thomas: but I guess 3d does not work, does it?

Bryce Harrington (bryce) wrote :

Thomas, reopening this bug is the wrong approach to having your bug looked at, since the original issue is solved.

Changed in fglrx-installer (Ubuntu):
status: New → Fix Released
emarkay (mrk) wrote :

Could this bug be the same issue as:
https://bugs.launchpad.net/bugs/369621

Jarl (jarl-dk) wrote :

Wouldn't it be a good idea to file a bug on AMDs ATI Linux Platform Bug Reporting:
http://ati.cchtml.com/ and track that bug on this bug. Just my 2 cents.

Yfrwlf (yfrwlf) wrote :

The restricted driver manager incorrectly recommends the fglrx driver for my 4850x2 video card, when installing this driver gives me the black screen of death.

gfx (oce) wrote :

The fglrx driver did work for me (ati 3200 onboard an Asrock A780-GM-LE) on the final 9.04 distribution of ubuntu with the 2.6.28-11-generic kernel. (with some issues)
If you have jaunty-proposed ticked in software sources you did get a new 2.6.28-12 version of the kernel
and fglrx crashes again.
The opensource radeon driver works best for me. (minus 3d) It seems that everytime something updates
the close source driver crashes, you could argue about flawed by design but this is probably not the place.

Sepero (cowpie2000) wrote :

Work Around/Fix/Solution

This guide worked a charm for me, and also appears to have solved the problem for several others:
http://tan-com.com/posts/technology/fix-ubuntu-904-ati-driver-issue

Displaying first 40 and last 40 comments. View all 108 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.