AMD 8.40.4 Driver -- One Bug A Day Keeps AIGLX Away

[yoshi314]

Ever since I read ESR's view on the American military and its major oversteppings, I just hate the guy, but he's got a few things about software development very well. "Release early and often". That probably means, more often than each month, each time with 4-5 who-gives-a-crap fixes. It means, "for each change you make", basically.

they're too often in the context of their development cycle - remember "every commit triggers a build + automated testsuite" or something along the lines.

that effectively slows down development, i'm afraid. besides fglrx is not open source.

if it were they could release early and often. people could just fix the bugs themselves, having access to the source. this is not a esr's bazaar model where you can release early, release often.

[glussier]

By GUI are you meaning the "automatic installation" or graphically generating the packages? For graphically generating the packages its SuSE and Red Hat.

I mean automatic installation. We can't generate the Slackware packages for the gui install.

[lenrek]

I mean automatic installation. We can't generate the Slackware packages for the gui install.

Same here.

I never really much problem with the installation process. It is the editing of xorg.conf that can be horrible.

Though, I do have to admit, compare to almost 2 years ago, the situation does improve a bit. I don't really have to hack the xorg.conf file that often.

Actually, reading these few exchanges, I am curious, if you are to upgrade a new release of kernel, how to install the fglrx? Did you run the whole installation process or go to /lib/module/fglrx and manually run the make.sh and make_install.sh (or simply copy the fglrx.ko to the appropriate kernel modules tree)? I did the later.

[opera]

they're too often in the context of their development cycle - remember "every commit triggers a build + automated testsuite" or something along the lines.

that effectively slows down development, i'm afraid. besides fglrx is not open source.

if it were they could release early and often. people could just fix the bugs themselves, having access to the source. this is not a esr's bazaar model where you can release early, release often.

The parts of fglrx which doesn't make it compile against 2.6.23, or any other version for that matter, is perhaps not open source, but we Do have the source for that. It's just that ATI treats that parts of the driver equal to the closed object module. If they would make a split in between them, an open source community could take responsibility for the "glue" part. That would probably not do any damage at least.

And that DOES fit into the bazaar model. Because including the right header files or whatever is needed to build against a certain kernel or Xorg version, will in some cases (perhaps most) not require any changes to the closed part, but only to the glue.

Instead we're left in the forum discussing what doesn't work for FC7, FC8, Slackware 47 etc... Which is nonsense. Someone makes a hack which makes fglrx work against a certain kernel+distro setup, instead of people working together fixing the glue-part of the driver in the first place.

This just sickens me.

[glussier]

Same here.

I never really much problem with the installation process. It is the editing of xorg.conf that can be horrible.

Though, I do have to admit, compare to almost 2 years ago, the situation does improve a bit. I don't really have to hack the xorg.conf file that often.

Actually, reading these few exchanges, I am curious, if you are to upgrade a new release of kernel, how to install the fglrx? Did you run the whole installation process or go to /lib/module/fglrx and manually run the make.sh and make_install.sh (or simply copy the fglrx.ko to the appropriate kernel modules tree)? I did the later.

When I upgrade the kernel, in Slackware I only rebuild the kernel module.

As for the xorg.conf file, I don't have much of a problem as I pretty much reuse the same xorg.conf file everytime.

[d2kx]

New kernel?

m-a a-i fglrx

and reboot (or unload, load fglrx module and restart X)

[hobophobe]

Man, I spoke too soon. Turns out that this release is even worse than previous for me.

The console switching bug now affects me; that's in direct opposition to the claim in the release notes that this issue was 'resolved' by this driver. It had never happened to me before this driver.

There was some very annoying mouse bug that cropped up where the vertical distances for the mouse were skewed (the further down the screen, the larger the offset between the pointer was drawn and actually clicked).

And finally not only is the 'no signal' display-init bug still there, it seems to have regressed. Previous releases actually had the EDID hex dump fill up where this one went back to mostly 0s.

Any driver that even tries to work with the 1.3 server thinks I have a crt1 and tmds1 connected when only the latter is connected. Under older servers it works just fine.

I have a very hard time believing future versions will improve for me. They claim to make progress but now I get more bugs than ever. I'm going to see how the free drivers are doing, and if they aren't working well enough I guess it's time to jump on the Nvidia bandwagon.

[twistedself]

Xv? Or am i hoping for to much?

No, they fixed something. I can now run mythfrontend without the NO_XV=1. Yay, I get proper overlays without the blue smurf faces.

Twisted

[d2kx]

Just found out that fglrx 8.40 only works on my 64Bit Sidux for me. I won't try anything to fix that, I just wait :P

[peper]

Important question - is x86_64 driver finally working properly? Anyone tested this driver under x86_64 machine with FC7? I guess its working fine on i386 FC7?