Open ATI Driver More Popular Than Catalyst

[kernelOfTruth]

while we're at it:

bridgman, could you please post any ETA for xf86-video-ati driver-support for the Juniper and Cypress chipsets ?

my Juniper (5770) is running fine here with fglrx and 2.6.31 but I'd rather like to use 2.6.32 which has lots of improvements for desktop / GUI users

thanks

[yotambien]

my Juniper (5770) is running fine here with fglrx and 2.6.31 but I'd rather like to use 2.6.32 which has lots of improvements for desktop / GUI users

Like what?

[bridgman]

bridgman, could you please post any ETA for xf86-video-ati driver-support for the Juniper and Cypress chipsets ?

Not really, we've already published everything we know

We're going to start reviewing agd5f's current analog VGA support next week for release, rather than waiting for digital output support. Should know later next week how that is looking.

[Kano]

@kernelOfTruth

Taken from my fglrx script:

# Kernel 2.6.32 fix
grep -q signal.h common/lib/modules/fglrx/build_mod/kcl_io.c || perl -pi -e 's|(#include <linux/poll.h>\n)|\1#include <linux/signal.h>\n|' common/lib/modules/fglrx/build_mod/kcl_io.c

[kraftman]

Like what?

Like CFS and CFQ improvements, better and more drivers, power management improvements, SFI and ACPI4.0 support, file systems improvements.

[Adarion]

When you think about 9-3 driver as last legacy driver release thats clear. The difference can be only R300-R500 cards and a few with R600+ who are oss believers - the users have just no other choice.

I tell you what: I got 2 R600 style chips and I use the free drivers. Horray me!
OSS believers go, go, go!
Okay I admit that there wasn't much choice for R100-500 users but at least the free drivers support these chips nicely. And maybe people ARE even more satisfied with them. By the way most distributors will preferably use the free drivers anyway and thus it is pre-set for users. It's me personally having the choice in Gentoo which drivers to use.

Now you can surely tell me where there is a choice for your always praised Nvidia?
I got some of their chips and they are li-la-legacy. So no nvidia binary blob for me. Aww. nv is the driver of choice there. Oh, wait. Was there a choice anyway?

[yotambien]

Like CFS and CFQ improvements, better and more drivers, power management improvements, SFI and ACPI4.0 support, file systems improvements.

I see, but how does that translate into real world improvements? They better be pretty good ones to offset the decreased performance and loss of features the OP would experience when passing from fglrx to radeon for his very recent card.

[kernelOfTruth]

Not really, we've already published everything we know

We're going to start reviewing agd5f's current analog VGA support next week for release, rather than waiting for digital output support. Should know later next week how that is looking.

so it could be within the next following weeks (I'm using DVI), I guess

thanks !

@kernelOfTruth

Taken from my fglrx script:

# Kernel 2.6.32 fix
grep -q signal.h common/lib/modules/fglrx/build_mod/kcl_io.c || perl -pi -e 's|(#include <linux/poll.h>\n)|\1#include <linux/signal.h>\n|' common/lib/modules/fglrx/build_mod/kcl_io.c

you, sir, are amazing !

thanks kano !

[kernelOfTruth]

Like CFS and CFQ improvements, better and more drivers, power management improvements, SFI and ACPI4.0 support, file systems improvements.

this and the improved flush algorithm

as kano already posted a nifty one-liner which should allow to use fglrx on 2.6.32 kernels

there should be no barrier (no visible at least for me atm) to migrate to 2.6.32 (with BFQ, BFS, and all of those other nice improvements - BFQ and BFS are included in the zen-kernel)

that should make desktop-computing with linux under massive load enjoyable and usable again (which until now seems to be the only platform which allows me to do so)

[duffman]

@kernelOfTruth

Taken from my fglrx script:

# Kernel 2.6.32 fix
grep -q signal.h common/lib/modules/fglrx/build_mod/kcl_io.c || perl -pi -e 's|(#include <linux/poll.h>\n)|\1#include <linux/signal.h>\n|' common/lib/modules/fglrx/build_mod/kcl_io.c

Why not put the fglrx public part of the kernel module source into a git-server and put new kernel support there?
Simple script downloads new kernel module source from the git-server for the Catalyst version user is running and then it can compile and use that.
Solve everyone's problem instead of just Kanotix users.

I mean this won't be possible for all Catalyst releases but for the ones that are it would be useful. It would also allow for backporting kernel support into some older drivers.

Phoro-git anyone?