Are AMD HD video card users all using older versions of GNU/Linux?

[Yfrwlf]

I was just wondering what everyone was doing, since my 4850x2 won't run in Jaunty with the fglrx driver, and while the ati driver gives me something which is great, it doesn't give me my correct maximum resolution on my Samsung SyncMaster T260, and of course will not give me 3D support.

Are users of the 4xxx and possibly 3xxx (and lower?) AMD cards using older versions of Linux until AMD gets these issues solved? So much for the same day support promise. :/ Anyone tried Karmic Koala? Probably wouldn't work on that either tho...

Thanks.

[deanjo]

I was just wondering what everyone was doing, since my 4850x2 won't run in Jaunty with the fglrx driver, and while the ati driver gives me something which is great, it doesn't give me my correct maximum resolution on my Samsung SyncMaster T260, and of course will not give me 3D support.

Are users of the 4xxx and possibly 3xxx (and lower?) AMD cards using older versions of Linux until AMD gets these issues solved? So much for the same day support promise. :/ Anyone tried Karmic Koala? Probably wouldn't work on that either tho...

Thanks.

How are you connected to your T260? HDMI, Analog or DVI-I? I ask because the Samsung T2x0 series has broken DCC when plugged into the HDMI. Maybe post your xorg.conf here for us to see.

[bridgman]

Are users of the 4xxx and possibly 3xxx (and lower?) AMD cards using older versions of Linux until AMD gets these issues solved?

There seems to be an issue specific to X2 boards and Jaunty. Don't think we've been able to repro it in house which is why we're asking for users to accumulate their findings (particularly regression info) in a Bugzilla ticket.

So much for the same day support promise. :/ Anyone tried Karmic Koala? Probably wouldn't work on that either tho...

"Same day support" in the Linux Catalyst drivers was for new hardware, not for new distros / kernels / X servers.

The open source drivers will normally give very quick support on new kernels and X servers since they are part of those source trees and are often used by the developers who are making changes to the underlying framework.

[lordmozilla]

well i'm using radeonHD on jaunty on my hd4850. To be honest I'm really happy with it. I dont run compiz anyways, the only thing i like is to run AOE in vmware to lan with friends and red alert 2. That works fine. So i'm happy!

Fglrx 9.5 is out now? or so i read so maybe that fixes most issues with 9.4 on jaunty

[Yfrwlf]

How are you connected to your T260? HDMI, Analog or DVI-I? I ask because the Samsung T2x0 series has broken DCC when plugged into the HDMI. Maybe post your xorg.conf here for us to see.

No I'm using DVI/digital, and the ati driver is seeing 1600x1200 instead of 1920x1200. Installing the fglrx driver provided by the distro's repository breaks my system. I haven't tried the one from AMD's site since last time that broke my system as well.

and, sure thing, just a generic skimpy "automatic" xorg tho..

----------------------
Section "Device"
Identifier "Configured Video Device"
EndSection

Section "Monitor"
Identifier "Configured Monitor"
EndSection

Section "Screen"
Identifier "Default Screen"
Monitor "Configured Monitor"
Device "Configured Video Device"
EndSection

[Yfrwlf]

There seems to be an issue specific to X2 boards and Jaunty. Don't think we've been able to repro it in house which is why we're asking for users to accumulate their findings (particularly regression info) in a Bugzilla ticket.

The Ubuntu dev's say it's a problem specific to AMD, and AMD dev's say it's a problem specific to Ubuntu. Gotta love it.

If it is a problem caused by something wrong that Ubuntu is doing, they need to fix it, agreed. I'll try a different "distro" then I guess. Wish I could simply download Xorg myself though, then I'd know nothing would be screwed up. Would really be helpful if everyone stayed on the same page as one another.

"Same day support" in the Linux Catalyst drivers was for new hardware, not for new distros / kernels / X servers.

OK. But since the kernel and Xorg are the two (main?) things that should be tracked, maybe tracking them closer would be nicer for the users that are closer to the bleeding edge is all.

Perhaps more standards are needed though, so that close tracking won't be so needed. Perhaps Gallium3D will help with that.

The open source drivers will normally give very quick support on new kernels and X servers since they are part of those source trees and are often used by the developers who are making changes to the underlying framework.

And again, perhaps better communication and APIs/standards/etc are needed to solve this problem, so that we'll have less broken drivers for all, less headaches for all, and more Linux goodness.

[Yfrwlf]

well i'm using radeonHD on jaunty on my hd4850. To be honest I'm really happy with it. I dont run compiz anyways, the only thing i like is to run AOE in vmware to lan with friends and red alert 2. That works fine. So i'm happy!

Fglrx 9.5 is out now? or so i read so maybe that fixes most issues with 9.4 on jaunty

RadeonHD has 3D support for hd4850 that is good enough to play 3D games with through VMWare? That's pretty amazing if so, I'll give it a try, thanks.

[bridgman]

The Ubuntu dev's say it's a problem specific to AMD, and AMD dev's say it's a problem specific to Ubuntu. Gotta love it.

You might be talking about a different problem. I'm saying "the problem with X2 boards seems to happen on Jaunty but not on Intrepid, however since we haven't seen it on any of our systems yet we don't know what the root cause is".

If it is a problem caused by something wrong that Ubuntu is doing, they need to fix it, agreed. I'll try a different "distro" then I guess. Wish I could simply download Xorg myself though, then I'd know nothing would be screwed up. Would really be helpful if everyone stayed on the same page as one another.

Do you have an X2 card ? If not, then I don't think this issue applies to you anyways.

Staying on one page is tricky when there are so many distros each with different combinations and patches; metaprojects like xorg help but unfortunately xorg doesn't include DRI and that's where most of the rapid change (and the kernel impact) takes place.

OK. But since the kernel and Xorg are the two (main?) things that should be tracked, maybe tracking them closer would be nicer for the users that are closer to the bleeding edge is all.

We do intend to shorten the gap between new kernel/xorg release and fglrx support over time. The open source drivers will always have an advantage there, however.

Perhaps more standards are needed though, so that close tracking won't be so needed. Perhaps Gallium3D will help with that. And again, perhaps better communication and APIs/standards/etc are needed to solve this problem, so that we'll have less broken drivers for all, less headaches for all, and more Linux goodness.

I don't know if this will ever get really easy for binary drivers; in a sense you could say that the challenge is rooted in the standards. One of the things that lets Linux evolve quickly is a willingess to replace kernel APIs more rapidly than most OSes if the change is deemed to be worthwile overall. Right now I think the major issue is priorities; once we support the core set of distros we are generally prioritizing the addition of most-requested features over support for bleeding-edge kernels and distros. I'm hoping the demand for additional features will drop off with time, allowing us to spend relatively more effort on support for new kernel and xorg versions.

[lordmozilla]

RadeonHD has 3D support for hd4850 that is good enough to play 3D games with through VMWare? That's pretty amazing if so, I'll give it a try, thanks.

Uhm watch it at 3d support. It only works with AOE and red alert cause they arent actually 3d games.

Compositing wont work though!

[Yfrwlf]

You might be talking about a different problem. I'm saying "the problem with X2 boards seems to happen on Jaunty but not on Intrepid, however since we haven't seen it on any of our systems yet we don't know what the root cause is".

Perhaps, and hopefully that just means Xorg 1.6 in comparison to the version Intrepid uses (1.5?), because there were issues with fglrx working on the new 1.6 X Server apparently.

Do you have an X2 card ? If not, then I don't think this issue applies to you anyways.

Oookay...not that it matters, because if it's an issue, then it's an issue, but yes, I do have one, so it does directly effect me.

Staying on one page is tricky when there are so many distros each with different combinations and patches; metaprojects like xorg help but unfortunately xorg doesn't include DRI and that's where most of the rapid change (and the kernel impact) takes place.

"Tricky" means it's not as grown up and unified as it should be then, yes. Xorg development needs to get it's act together with a tight, unified development line, similar perhaps to kernel development or <insert tight software development project name here>, and since DRI is closely involved then of course the community and/or software is going to have to somehow adjust for that. What I mean is that perhaps if the kernel used better standards, maybe less kernel developers would need to be involved, etc.

I hope things improve in the future, is all I'm saying...

We do intend to shorten the gap between new kernel/xorg release and fglrx support over time. The open source drivers will always have an advantage there, however.

Which you could say, IMO, is a failing on several different levels or simply the system as a whole, but ultimately having a driver which is friendlier to open source will be tested by open source developers more. I hope AMD has plans to either dump it's proprietary driver and focus on open driver(s), or open up the proprietary driver. But again I'm sure there are other things that would help the process as well.

I don't know if this will ever get really easy for binary drivers; in a sense you could say that the challenge is rooted in the standards. One of the things that lets Linux evolve quickly is a willingess to replace kernel APIs more rapidly than most OSes if the change is deemed to be worthwile overall. Right now I think the major issue is priorities; once we support the core set of distros we are generally prioritizing the addition of most-requested features over support for bleeding-edge kernels and distros. I'm hoping the demand for additional features will drop off with time, allowing us to spend relatively more effort on support for new kernel and xorg versions.

Well thought out and implemented standards shouldn't require a complete overhaul every day, instead having APIs that are as stable as OpenGL for instance would be really wonderful, a lesson the kernel should take note of regarding all of it's drivers. Supporting specific distros shouldn't be needed, only the core programs like Xorg and the kernel IMO. You'll never be able to release Linux drivers on CDs, for example, if this doesn't change, which you need to do because not all kernels out there are the same version. Stability of the APIs and better planning would mean you could release a simple driver that worked across a wide range of kernels. If packaging standards got their act together, drivers on a CD in case a user needed them, like if they *weren't* using a bleeding edge kernel, would become a reality and would really help out Linux users and companies alike.

I think Linux needs more leaders to organise and push for standards in general, and that doing so will solve a lot of the mess Linux faces right now.