Ati changed naming of Linux drivers. So review ebuild and bumb it please. I tried to install it, but no very nice outcome, so far. But it was possible (at least it looks like but the result is not perfect) to use the current ebuild with some modifications to install it. Reproducible: Always
Created attachment 136768 [details] ati-drivers-7.11.ebuild with fixes This is an ebuild for ati-drivers 7.11, that includes bug 196684 and bug 199146. I've also removed the unnecessary dependency emul-x86-linux-compat.
Created attachment 136770 [details, diff] ati-drivers-7.11-warnings.patch This is a port of the 8.42.3's warning patch. This is a replacement. This patch is not "needed", the driver will work without this patch. If you don't want to use it, just remove the epatch line from the ebuild. Put this patch in ${OVERLAY}/x11-drivers/ati-drivers/files/7.11/
Created attachment 136771 [details, diff] ati-drivers-2.6.23.patch This is the remaining hunk of the 2.6.23 patch for 8.42.3, that will apply. This patch is not "needed" as well, if you don't want to use it, remove the epatch line from the ebuild. This replaces the linux-2.6.23.patch, that is in portage for 8.42.3.
If you like I can also provide an ebuild without those two bug reports included. Correct way to install this ebuild: Download the files above and put the ebuild file in ${OVERLAY}/x11-drivers/ati-drivers/, then put those two patches in ${OVERLAY}/x11-drivers/ati-drivers/files/7.11/, copy over the files from /usr/portage/x11-drivers/ati-drivers/files/*, put them in ${OVERLAY}/x11-drivers/ati-drivers/files/ and digest. Anyone interested in a diff against current portage ebuild?
Something about the "naming issue". The problem is, that the current "older" versions have a "higher" version number than 7.11. One possible solution, that I can think of is renaming the current ebuilds to 7.8.42.3 (since they are from year 2007) 7.8.40.4 ... 7.8.33.6 6.8.32.5 (year 2006) ... 6.8.27.10-r1 but maybe there is a better solution.
AGP PCI-E boards still don't work properly. (realto chip i belive they are called?) fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY' taints kernel. [fglrx] Maximum main memory to use for locked dma buffers: 1898 MBytes. [fglrx] ASYNCIO init succeed! [fglrx] PAT is enabled successfully! [fglrx] module loaded - fglrx 8.43.2 [Nov 9 2007] on minor 0 ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 19 [fglrx] IRQ_MGR is disabled untill GART_CACHABLE memory will be implemented<6>[fglrx] Internal AGP support requested, but kernel AGP support active. [fglrx] Have to use kernel AGP support to avoid conflicts. [fglrx] AGP detected, AgpState = 0x1f000a1b (hardware caps of chipset) agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0. agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode [fglrx] AGP enabled, AgpCommand = 0x1f000312 (selected caps) other then that, it installed fine without the 2 patches, so i recommend those are removed entirely? Why apply them if they are not needed.
(In reply to comment #6) > other then that, it installed fine without the 2 patches, so i recommend those > are removed entirely? Why apply them if they are not needed. > I just took the patches, that are already in portage and cleared the failing hunks. It does work with and without the patches. It just shows less warnings with the patches, when compiling. But that really isn't the problem, there are other issues, that are really more critical. For example, this driver also has the wrong SONAME, which I think confirms what every one is already saying, that this driver is nothing but 8.42.3 renamed and a few (official) patches integrated.
(In reply to comment #7) > (In reply to comment #6) > > other then that, it installed fine without the 2 patches, so i recommend those > > are removed entirely? Why apply them if they are not needed. > > > > I just took the patches, that are already in portage and cleared the failing > hunks. > It does work with and without the patches. It just shows less warnings with the > patches, when compiling. > But that really isn't the problem, there are other issues, that are really more > critical. For example, this driver also has the wrong SONAME, which I think > confirms what every one is already saying, that this driver is nothing but > 8.42.3 renamed and a few (official) patches integrated. > This is already avaliable in je_fro's overlay. There are much more fixes then just the 2.6.23 support which is official no patching is needed all warnings should be cleaned up for next release of 8.44x. please refer to je_fro's overlay on overlays.gentoo.org.
Please see bug 200140. I believe I've produced a better ebuild that fixes some issues that this one and the one in jefros overlay has. Also, I've made a case for changing the name of the ebuild.
(In reply to comment #9) > Please see bug 200140. I believe I've produced a better ebuild that fixes some > issues that this one and the one in jefros overlay has. Also, I've made a case > for changing the name of the ebuild. > I didn't fix the libXrandr dep problem, because I wanted to check it myself first.
Created attachment 136838 [details] ati-drivers-7.11.ebuild with fixes including libXrandr dep New ebuild with fixed dep for libXrandr. Since everyone thinks, that those patches are useless, remove them.
Manually calculating the offset for unpacking is no longer necessary. The first section of src_unpack() can be replaced with: sh "${DISTDIR}/${A}" --extract "${S}" 2&>1 /dev/null
(In reply to comment #9) > Please see bug 200140. I believe I've produced a better ebuild that fixes some > issues that this one and the one in jefros overlay has. Also, I've made a case > for changing the name of the ebuild. > I can not support your work as it incorporates id's that were disabled for reason that are unknown to you as a user. As a beta tester I know these reasons and have stayed within what upstream has requested.
(In reply to comment #11) > Created an attachment (id=136838) [edit] > ati-drivers-7.11.ebuild with fixes including libXrandr dep > > New ebuild with fixed dep for libXrandr. > Since everyone thinks, that those patches are useless, remove them. > I will push this to je_fro's overlay soon as possible. Thanks for pointing it out.
Created attachment 136846 [details] ati-drivers-7.11.ebuild fixed paths I just realized, that there were two paths, that were just wrong. (two of the sed statements): This is fixed in this ebuild. Also removed the offset as suggested, works for me fine.
(In reply to comment #14) > (In reply to comment #11) > > Created an attachment (id=136838) [edit] > > ati-drivers-7.11.ebuild with fixes including libXrandr dep > > > > New ebuild with fixed dep for libXrandr. > > Since everyone thinks, that those patches are useless, remove them. > > > > I will push this to je_fro's overlay soon as possible. Thanks for pointing it > out. > Please push the new one out, I just realized, that I had an awful mistake in the ebuild (forgot "build_mod" in the path).
(In reply to comment #9) > Please see bug 200140. I believe I've produced a better ebuild that fixes some > issues that this one and the one in jefros overlay has. Also, I've made a case > for changing the name of the ebuild. > That powermode patch, that you listed isn't necessary. For the first thing (replacing "finger" with "who") it would be better to do this via sed and for the second thing there is a patch in portage already, but it doesn't get applied since 8.33.6. I don't know if there is a reason for that, but the patch you apply in the other bug report is definitely not needed and it is actually wrong, because it replaces finger only in one instance, when it appears to two times.
(In reply to comment #17) > That powermode patch, that you listed isn't necessary. > For the first thing (replacing "finger" with "who") it would be better to do > this via sed and for the second thing there is a patch in portage already, but > it doesn't get applied since 8.33.6. I don't know if there is a reason for > that, but the patch you apply in the other bug report is definitely not needed > and it is actually wrong, because it replaces finger only in one instance, when > it appears to two times. Apparently, some people have a problem with finger as discussed in bug 197470. Also, if you follow the codepath, you'll see that the authors of the script are depending on finger occassionally producing empty output. (The bit just after the patched part where they try again): - user=`finger| grep -m1 ":$displaynum " | awk '{print $1}'` + user=`who| grep -m1 ":$displaynum " | awk '{print $1}'` if [ x"$user" = x"" ]; then user=`finger| grep -m1 ":$displaynum" | awk '{print $1}'` fi The patch works - I have tested it. Also, "who" is a better choice since that is provided by coreutils which is a part of the system set. "finger" is provided by netkit-fingerd, which is not. So the patch works, fixes additional problems. I don't see why it shouldn't be in the ebuild.
(In reply to comment #18) > The patch works - I have tested it. Also, "who" is a better choice since that > is provided by coreutils which is a part of the system set. "finger" is > provided by netkit-fingerd, which is not. So the patch works, fixes additional > problems. I don't see why it shouldn't be in the ebuild. > I think I've figured this out and what happened with that patch and why whis appeared again. Still that patch, that you are providing is wrong, because it only replaces finger once, while it should replace it twice. Look at that bug report over there, I've posted what I think should be the correct solution. (Look at the revisions of 8.34.* (or was it 8.33.*) and you might see what happened here.) I will include that in the ebuild, but actually this problem is not specific for this ebuild and with that patch it should be fixed for older versions, too (>=8.34.*).
Created attachment 136881 [details] ati-drivers-7.11.ebuild - replace 'finger' with 'who' New ebuild, which includes replacing "finger" with "who". "who" is part of every system, while "finger" would have to be installed manually. So it is better using that one.
Created attachment 136882 [details, diff] Replacement for the ati-powermode-opt-path.patch in portage The ati-powermode-opt-path.patch replaced ati-powermode.sh.patch because of changed path of aticonfig. The above patch is the replacement, that should have been made, instead another patch was introduced, which opens up the problem with default state again, that was fixed before. This does affect all versions, that apply ati-powermode-opt-path.patch. See bug 197470.
uhm, guys a short question what is about the console switch problem (it seems that it is garbaging my suspend 2 ram)? And what is with suspend in general? should it work with the current ebuild? (IBM T60 CoreDuo T2500 X1400) Thx, so far, hope to see this soon in portage ;)
(In reply to comment #22) > uhm, guys a short question what is about the console switch problem (it seems > that it is garbaging my suspend 2 ram)? This can only be fixed by ATI/AMD themselves.
Thanks for the ebuild - but... *ARGH* when enabled in amdcccle, vsync happens in the middle of the screen with these drivers ! Back to 8.42.3 for me...
btw, what is with the naming issue? how it should be integrated in portage to keep versions in order?
(In reply to comment #25) > btw, what is with the naming issue? how it should be integrated in portage to > keep versions in order? > As I wrote on the forums I think there are three solutions: - Rename this "new" driver to ati-catalyst, amd-drivers, amd-catalyst - See comment #5 - Rename current drivers to ati-drivers-legacy and make this ati-drivers - Even more stupid ideas like p.masking everything "older" I don't really like any of them. Renaming to "amd-drivers" or similar wouldn't be really correct, because the graphics cards are still named "ATI ..." and that could lead into confusion, if there are "ati-drivers" and "amd-drivers". Similar with the third solution, because many people would think, at least if they know about the nvidia drivers legacy part, that their graphics card won't be supported by ati-drivers in the future. Because of this I would minimize the confusion and don't split the drivers up and because solution four is of course a no go (keep in mind, that some cards won't work with this driver and that AMD still recommends to distribute 8.40.4) I would choose solution 2. Maybe there are other solutions I don't know about (maybe slots?). But we will see what the maintainer will choose.
I have just updated je_fro's overlay I do not see the point in changing the patch for opt it is fine only issue that is truely there is finger issue which is easily fixed with the sed over file. Please test it and report back naming scheme actually follows that of the glx string and not that of catalyst I have spoken with the maintainer of this and are working toward a better solution.
(In reply to comment #27) > I have just updated je_fro's overlay I do not see the point in changing the > patch for opt it is fine only issue that is truely there is finger issue which > is easily fixed with the sed over file. Please test it and report back naming > scheme actually follows that of the glx string and not that of catalyst I have > spoken with the maintainer of this and are working toward a better solution. > Since I am not really interested in that naming issue, I'll change the SRC_URI, so PV isn't included anymore and that cuts it down to the name of the ebuild, which I'll leave as it is for this bug (but that isn't really a problem I think), to make it not more confusing than it already is. I've had a look at the ebuild in je_fro's and I spotted, that you forgot to change the paths of the debug and suspend sed parts: - "${S}/common/lib/modules/fglrx/firegl_public.c" \ + "${S}/common/lib/modules/fglrx/build_mod/firegl_public.c" \ and: - "${S}/common/lib/modules/fglrx/firegl_public.h" \ + "${S}/common/lib/modules/fglrx/build_mod/firegl_public.h" \ I don't know when that "build_mod" got lost, because when I made the first patch for debug it was correct (and I tested it) and I copied the paths from the patch. Nevertheless it got lost somewhere and it has to be corrected or the sed parts will fail. But when I looked at the ebuild I spotted, that this path to the module dir is used quite often, so I guess it might be a good idea to introduce a variable for that. It might be usefull if ati (for whatever reason) changes the name of that path. They like to surprise us, don't they? ;) The thing with the opt patch is, that by default the "default state" is state 3 which doesn't seem to be always correct. Because of that a patch has been introduced, that detects which is the default state by analysing the output of aticonfig. This got lost, when the new patch has been introduced, which resulted in a new bug being opened about that issue.
Created attachment 137017 [details] ati-drivers-7.11.ebuild - Removed multilib from IUSE - SRC_URI is now static - Added libs to QA_TEXTRELS, like in je_fro's - Introduced ${MODULE_DIR} - Added a reference to bug 199633 (libGL.so issue) - Minor things (url to ati's page)
Created attachment 137025 [details] Cleanups - Done some cleanups - Removed SLUB warning, seems to be fixed in this release
(In reply to comment #28) > The thing with the opt patch is, that by default the "default state" is state 3 > which doesn't seem to be always correct. Because of that a patch has been > introduced, that detects which is the default state by analysing the output of > aticonfig. This got lost, when the new patch has been introduced, which > resulted in a new bug being opened about that issue. > I can understand that and will ajdust it in the overlay a bit later today I would rather see a -1 added to the patch name this is to prevent collision on the mirrors.
8.433 is in the tree
emerging ati-drivers-8.433 from the tree works, but I have 2 problems: 1. I get `error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory' errors from just about any program (glxinfo, mplayer etc.) and re-emerging the packages doesn't help (mesa-progs, for example). Therefore I must revert to the old 8.40.4 driver and then re-emerge mesa-progs again to solve this. 2. Gamma cannot be changed, not from KDE and not with xgamma (even after re-emerging it, just-in-case). I could not find this anywhere, not on bugzilla, not in the forums and not in google. Perhaps it's related to the previous problem?
(In reply to comment #33) > emerging ati-drivers-8.433 from the tree works, but I have 2 problems: > 1. I get `error while loading shared libraries: libGL.so.1: cannot open shared > object file: No such file or directory' errors from just about any program > (glxinfo, mplayer etc.) and re-emerging the packages doesn't help (mesa-progs, > for example). Therefore I must revert to the old 8.40.4 driver and then > re-emerge mesa-progs again to solve this. See bug 199633.
(In reply to comment #33) > 2. Gamma cannot be changed, not from KDE and not with xgamma (even after > re-emerging it, just-in-case). I could not find this anywhere, not on bugzilla, > not in the forums and not in google. Perhaps it's related to the previous > problem? I don't think it's related. For me, quake3 plays with no gamma, and last fglrx version with working gamma was 8.40.4. The other annoying thing is VSYNC: - ok with 8.40.4 - almost ok (tearing in first 5% of screen) with 8.42.3 - sucks (tearing in middle of screen) with later release.
(Apologies for bug spam) As far as this bug goes, it's done. If you have issues with the driver that may or may not be UPSTREAM, please open new bugs.
