This realy pis*ed me off !!!!!

[nanonyme]

Meh, I don't count it working for me until the open driver can do both DRI *and* FBO. (I recall someone say that the FBO support is dependdnt on GEM though and doesn't relate to any current NDA's) I did buy a new card too, didn't give up my old one though. Now the upgrade card (HD3870) is safe and sound in a locker waiting for a the drivers to mature.

[Kano]

@Odur

"The screen flickered now and then" - thats caused by xrandr, you can test it when you call it in a terminal. Mainly the used KDE4 version in Kubuntu has this problem, maybe because of krandrtray. Gnome does not call xrandr that often... I asked several times for a patch that disables this new "feature" which does not happen with fglrx or nvidia binary drivers when calling xrandr, but nobody liked to help me.

[nanonyme]

The radeonhd (which worked perfect in 8.04) gave me a blank screen. I had to update radeonhd from tormodvoldens ppa, but even then it didn't work as it should.

Might want to skip Ubuntu downstreams completely and install from RadeonHD project; preferably a git version.

I tried to install the 8.11 fglrx, but that only gave me ABI errors in the Xorg.0.log file and wouldn't start X, so I had to revert to 8.10.

Btw, since it's *buntu 8.10, you didn't technically revert to Catalyst 8.10 but Catalyst pre-release 8.10.*. Catalyst 8.10 had version number 8.542 and Catalyst 8.11 had version number 8.552 while the fglrx in Ubuntu has version number 8.543. Go figure.

ps. Graciously to AMD and Ubuntu, thank you oh so much for using the same numbering scheme so you need to always use full product names for the other person to understand what the heck you're talking about.

[Odur]

@Odur

"The screen flickered now and then" - thats caused by xrandr, you can test it when you call it in a terminal. Mainly the used KDE4 version in Kubuntu has this problem, maybe because of krandrtray. Gnome does not call xrandr that often... I asked several times for a patch that disables this new "feature" which does not happen with fglrx or nvidia binary drivers when calling xrandr, but nobody liked to help me.

Oh, I see. Is there a bug report on this somewhere?

[nanonyme]

Oh, I see. Is there a bug report on this somewhere?

Might already be fixed anyway, the version he tried was
xserver-xorg-video-radeonhd - 1.2.3+git20081030.a36896dd-0ubuntu0tormod

ps. Getting mixed with who wrote what. Be back later.

[elanthis]

Actually, by all accounts, the initial 2d and 3d acceleration for r600 and r700 is already mostly working

"initial" and "usefully complete for the kind of people who buy high-end graphics cards" are completely different things.

Bridgman says "real soon now" but he still can't give a date, nor any details on what the legal problem is.

Actually, details have been given. There isn't some specific issue holding things up. They're just waiting for a bunch of people to agree and say "OK, looks good" rather than trying to resolve some big, super-secret issue. It essentially comes down to the big shots saying, "we need everyone involved to be completely confident that this is safe to publish," rather than saying, "we're going to publish this unless anyone involved has reason to believe we can't." Combine the number lawyers, hardware engineers, driver developers, and management involved with the sheer amount of documentation and information needed to fully specify the new architecture, and you've got a time frame on your hands that could make a government body get impatient.

[Odur]

@Odur

"The screen flickered now and then" - thats caused by xrandr, you can test it when you call it in a terminal. Mainly the used KDE4 version in Kubuntu has this problem, maybe because of krandrtray. Gnome does not call xrandr that often... I asked several times for a patch that disables this new "feature" which does not happen with fglrx or nvidia binary drivers when calling xrandr, but nobody liked to help me.

So, now I have found an entry at Launchpad for this bug.
According to this comment, the source of the flickering seems to be the KRandR kded module which surprisingly is not in the KDE4 master but only in a unfinished working branch. That's definitly not good news. How the heck could the Kubuntu developers include this!?

[calica]

Review process for future gens?

Bridgeman,

What about future generations? (R800+) Will they need to go through the same review process or will they leverage the current work? Or are they being designed to have less problems in the first place?

Thanks.

[elanthis]

How the heck could the Kubuntu developers include this!?

(another off-topic rant... I'm a bad person, sorry)

Ever since the third Ubuntu release or so, all Ubuntu has been about is shoving half-baked and incomplete stuff into each release and then bragging about how many new (experimental) features it has, rather than focusing on a stable, consistent desktop. At least Kubuntu doesn't patch half of KDE with broken and ill-conceived customizations like Ubuntu does with GNOME.

The first few Ubuntu releases were -- despite being the "rough" releases -- the most stable and bug free. I switched to Ubuntu when it first released after Jeff suggested it to me, and I was quite happy with it at first. Then I switched to Fedora a year or so ago because I just got so sick of being Canonical's guinea pig. Fedora has been far more stable for me, even though Fedora is actually supposed to be bleeding edge and experimental. :/

I think it's a real shame that Ubuntu has become as popular as it is, because at this point, I really feel that it just gives the Linux desktop a bad rep. It's the equivalent of recommending Windows ME as the Microsoft desktop OS of choice.

I really, rally wish Ubuntu would go back to its roots of just giving users the most stable, consistent desktop it can, and completely avoid any and all customizations. If it isn't part of upstream, it doesn't belong. If the Ubuntu devs have an idea for a desktop modification, they should get it accepted into upstream first, and then wait for the feature to be a part of an upstream release.

Perhaps Ubuntu could use a second sub-OS just for experimental stuff, so users into that can play with it, and ideas get a chance to develop fully. The development tree of the distro is NOT the place for this, because then you end up at the end of the releae cycle having to decide between keeping all these broken, half-complete features, or backing them out and reverting to upstream code that wasn't being tested in the distro at all. You basically end up with two weeks to test the reverted code. Horribly bad situation. The distro development tree should only ocntain what they know they want in the final release for a fact, not experimental stuff they're not sure about yet.

... I really need to stay on topic around here. Sorry.