patch: vanilla fglrx for 2.6.29

[acolomb]

Also works with Catalyst 8.12

Ok, new patch -> http://liquorix.net/patches/

It's a modification of Kano's, same procedure as the original patch.

I've just successfully compiled and used the Catalyst 8.12-4 driver package from Debian stable with the 2.6.29 kernel. The above patch also worked for the older kernel module sources.

This is a workaround for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=513222 which also affects me with my Radeon HD 3650. Shame on AMD for this regression ever since 9.1 (even 8.12 for some users apparently)! I hope it will be fixed with their next release.

Regards, Andre

[Kano]

This patch has nothing to do with xserver 1.6 support, only with 2.6.29 support. The huge patch is basically wrong, it only shows a packageing problem within the header packages which do not ship with the new acpi subdir.

[Sril]

liquorix does not work on debian

Hi,

Patch from liquorix.net applied and compile fine, but the patch simply reboot the debian(unstable) linux(2.6.29) X Window(1.4.2) box(Amd64X2).

Best regards.
See ya.

[acolomb]

Watch out for libdrm!

My success story from last night was tainted this morning when X froze up the computer again. The changes since then had been an update of libdrm2 from Debian version 2.4.4+git+20090205+8b88036-1 to 2.4.5-1 and module-init-tools 3.4-1 to 3.7-pre9-1.

I don't think the latter has anything to do with the problem (although there were some warning messages about module symbols on the console). Anyway, reverting those two packages to their prior versions made the patched fglrx 8.12-4 driver work with kernel 2.6.29 again.

Hope this helps somebody to regain their GUI :-)

[tettamanti]

The problem is that Debian/Ubuntu header packages are just wrong and do not include the new acpi dir.

Well, they are not wrong, the headers expose internal details of the interpreter and have been made private.

[Kano]

Thats nice, but when that crappy driver wants em, what do do? I added those to the kernel header package and did not include em in my script. But the example code from mandriva did not work - and i doubt it will ever work even with mandriva that way because they are not in the includes dir but in the drivers dir. A bad hack would be using ../drivers/ then.

[tettamanti]

Thats nice, but when that crappy driver wants em, what do do?

Rework using the proper API: for getting the child (the code assumes that there's only one...) you can use acpi_get_next_object, the notifier part is harder to fix since there's no API for updating the context nor the handler of an event... you'd have to write it. Or go for a workaround:

A bad hack would be using ../drivers/ then.

Well it seems that the only problem is the acpi_namespace_node struct, so maybe you can just put a definition of that in one of ATI's headers.

[Kano]

Good idea, please provide a nicer patch then

[tettamanti]

Good idea, please provide a nicer patch then

I'm somewhat uninterested in fixing the closed source driver

[Vighy]

I'm somewhat uninterested in fixing the closed source driver

you lazy italian!
(Anche io lo sono, e ti capisco :P)