You are not logged in.
Vi0L0, could you rename catalyst-utils and lib32-catalyst-utils packages in your catalyst-234hd repo, please? Because packages with same names now is in community repo. Yesterday i tried do:
pacman -Syu
and got error:
aticonfig --initial aticonfig: device not found (or something like this)
because these packages are updated from 12.6 to 12.8 version, which is unsupported my ATI HD 4870.
This should not happen if you correctly place [catalyst-hd234k] repo above [community] in pacman.conf. It is the same mechansim that allows legacy xorg repository to override the official version in extra...
Offline
thankyou, snack, i'll try to do it evening
Offline
thankyou, snack, i'll try to do it evening
Remember to upgrade with pacman -Syuu after placing the repos in the correct order in pacman.conf (the double u parameter will force the downgrade to 12.6, otherwise pacman will stick with the most recent version).
Offline
@snack, thank, yestarday i installed 12.6 versions of these packages from pacman cache by
pacman -U /var/cache/pacman/...
and now everything working well again
Offline
As I announced before, I have edited the Wiki page. It took me two days, but finally it's completely up-to-date again and all the double information etc. has been removed.
Could you please look it all over and see if I missed a spot, or made some grammatical error? Note that I still have to do the Troubleshooting section, but everything else is done now.
https://wiki.archlinux.org/index.php/ATI_Catalyst
EDIT: Also, I have four points noted that have to be double-checked:
1. The Xorg example - is it still needed? It doesn't have explanation for some entries so it might confuse users.
2. Installing from AMD - I have only done this a long time ago and never on Arch; can anyone verify if the old method still works? Should we perhaps remove this, as it's unrecommended anyway?
3. How many of the backported Xorg repos should we list? I don't think there's people using a driver older than 6 months...
4. I'm also note sure about the last NOTE in the Catalyst-daemon paragraph. I have never used any of these tools, so I need other people to confirm and check this for me.
EDIT2: I have now also fixed the Troubleshooting section. I removed some parts about old versions of Catalyst (10.6 to 10.8, I believe) and fixed references to the other paragraphs.
Last edited by Unia (2012-10-05 13:31:19)
If you can't sit by a cozy fire with your code in hand enjoying its simplicity and clarity, it needs more work. --Carlos Torres
Offline
Perhaps a bit off-topic, but this somewhat goes with the #3 point in Unia's post:
At some point in time a change in udev required either manual intervention (by creating a symlink to a library) or building xorg-server against the newer version of udev for xorg-server to function properly. Have the packages in [xorg110] and below been rebuilt?
TL;DR: Will packages installed from [xorg110] and below work out of the box on current up-to-date systems?
Offline
@Unia - You're trying to rejuvenate the Catalyst wiki page. Maybe this will help:
A week ago, when I decided to give the Catalyst driver a chance, I read again it's whole page in the wiki. When I stripped out the old, the irrelevant and the AUR-packages-related stuff - this is what's left:
Catalyst Configuration:
Xorg configuration via /etc/X11/xorg.conf:
aticonfig --initial
# the generated xorg.conf will override everything in /etc/X11/xorg.conf.d/
add the default and the maximum display resolution in xorg.conf:
Section "Screen"
SubSection "Display"
Modes "1280x1024" "1280x1024"
Module loading:
cp /usr/lib/modprobe.d/catalyst.conf /etc/modprobe.d/catalyst.conf
make sure radeon is not loaded anywhere in /etc/modules-load.d/
create /etc/modules-load.d/fglrx.conf with fglrx entry
sudo systemctl enable atieventsd.service
Disable mode setting:
add 'nomodeset' and 'vga=0' to GRUB_CMDLINE_LINUX in /etc/default/grub
sudo grub-mkconfig -o /boot/grub/grub.cfg
Reboot:
sudo systemctl reboot
Check operation:
--- check if the module is loaded
lsmod | grep fglrx
--- check that fglrx is up and running
fglrxinfo
--- verify direct rendering
glxinfo | grep direct
--- run a GL demo
fgl_glxgears
--- ADM Control Center
amdcccle
Troubleshooting:
--- check the /var/log/Xorg.0.log for errors, warnings and clues
less /var/log/Xorg.0.log
--- try to ignore the system ACPI hardware calls
aticonfig --acpi-services=off
--- to debug a not-working direct rendering
LIBGL_DEBUG=verbose glxinfo > /dev/null
--- if experiencing temporary hangs
add 'nopat' to GRUB_CMDLINE_LINUX in /etc/default/grub
sudo grub-mkconfig -o /boot/grub/grub.cfg
--- if there are laggs or freezes when watching flash videos using the Adobe's flashplugin
make /etc/adobe/mms.cfg look like this
#EnableLinuxHWVideoDecode=1
OverrideGPUValidation=true
--- if window movement in GNOME3 is laggy or slow
add 'export CLUTTER_VBLANK=none' in /etc/bash.bashrc
Basically that's the all information a user needs. Maybe some lines need more detailed explanation and possibly a couple of warnings here and there for the more inexperienced.
Offline
Basically that's the all information a user needs. Maybe some lines need more detailed explanation and possibly a couple of warnings here and there for the more inexperienced.
It's not - we also have to inform users there's different methods to go about installing Catalyst. Also, a little background information won't hurt either and lastly, you have to inform users about holding back Xorg versions.
Do you think the Wiki page is still too complicated? Personally I don't think so, it's nicely balanced between "talks" and "commands".
EDIT:
add the default and the maximum display resolution in xorg.conf:
Section "Screen"
SubSection "Display"
Modes "1280x1024" "1280x1024"
Actually, that's not necessary.
Module loading:
cp /usr/lib/modprobe.d/catalyst.conf /etc/modprobe.d/catalyst.conf
Not necessary either. The /usr/lib/modprobe.d/ directory is for packages to install their files. /etc/modprobe.d/ is for system admins. Both directories get read, it's just that the /etc/ one has priority.
sudo systemctl enable atieventsd.service
Good catch, I didn't mention this in the Wiki. I don't use it though and I don't notice any problems. What exactly does this atievents daemon do? I might have to add it.
EDIT2: Forgot to add it, thanks for your comments Perhaps we can improve the article together!
Last edited by Unia (2012-10-06 16:27:12)
If you can't sit by a cozy fire with your code in hand enjoying its simplicity and clarity, it needs more work. --Carlos Torres
Offline
Okay guys, I just updated to the new kernel 3.5.5 and wanted to give a word of advice. If you are using the catalyst-dkms and using systemd, you have to manually enable the dkms service using systemctl enable dkms.service, otherwise the fglrx module will not rebuild and you will be stuck at the log in screen. Make sure to do this and reboot before updating to the latest kernel. The package maintainer for the community package needs to make this happen automatically or it needs to be stated in the wiki, otherwise there will be a lot of confused users when they update to a new kernel.
Offline
Okay guys, I just updated to the new kernel 3.5.5 and wanted to give a word of advice. If you are using the catalyst-dkms and using systemd, you have to manually enable the dkms service using systemctl enable dkms.service, otherwise the fglrx module will not rebuild and you will be stuck at the log in screen. Make sure to do this and reboot before updating to the latest kernel. The package maintainer for the community package needs to make this happen automatically or it needs to be stated in the wiki, otherwise there will be a lot of confused users when they update to a new kernel.
Good one. I'll test and add it to the Wiki.
EDIT: Tested and confirmed. Information added to the Wiki. Do users from the unofficial [Catalyst] repo also need to perform specific actions?
EDIT2: I can't seem to get DKMS to run. I did enable the service file, but it doesn't run. Now I'm stuck on kernel 3.5.5 with the fallback driver. What to do?
EDIT3: Oke, got catalyst to rebuild by reinstalling it. But still, why didn't DKMS do it on boot?
Last edited by Unia (2012-10-06 22:41:47)
If you can't sit by a cozy fire with your code in hand enjoying its simplicity and clarity, it needs more work. --Carlos Torres
Offline
EDIT: Tested and confirmed. Information added to the Wiki. Do users from the unofficial [Catalyst] repo also need to perform specific actions?
Hello, I'm using catalyst-hd234k repository and catalyst-hook on a pure systemd setup. Just wanted to mention that catalyst-hook automatically rebuilt the FGLRX module during new Linux kernel 3.5.5 installation process and there weren't any need to perform specific actions.
Offline
Unia wrote:EDIT: Tested and confirmed. Information added to the Wiki. Do users from the unofficial [Catalyst] repo also need to perform specific actions?
Hello, I'm using catalyst-hd234k repository and catalyst-hook on a pure systemd setup. Just wanted to mention that catalyst-hook automatically rebuilt the FGLRX module during new Linux kernel 3.5.5 installation process and there weren't any need to perform specific actions.
As far as I know, that's only the case if one's using the vanilla kernel because upon installing catalyst-hook, (only) 'linux-headers' is added to the 'SyncFirst' line in pacman.conf. I had to manually add 'linux-lts-headers' for automatic re-compilation (of the fglrx module) to work when updating the lts kernel.
Last edited by andy_v (2012-10-07 03:53:07)
Offline
What exactly does this atievents daemon do? I might have to add it.
According to its manpage it handles ACPI events.
Offline
Unia wrote:EDIT: Tested and confirmed. Information added to the Wiki. Do users from the unofficial [Catalyst] repo also need to perform specific actions?
Hello, I'm using catalyst-hd234k repository and catalyst-hook on a pure systemd setup. Just wanted to mention that catalyst-hook automatically rebuilt the FGLRX module during new Linux kernel 3.5.5 installation process and there weren't any need to perform specific actions.
I'm running the same repo and fglrx isn't loaded (by checking lsmod) so when I try to modprobe it returns
sudo modprobe fglrx
ERROR: could not insert 'fglrx': Exec format error
So apparently the kernel module hasn't been rebuilt. I'm running a vanilla kernel and I've never had to manually rebuild it, so what gives? I would try to manually rebuild it using catalyst-generator (haven't used that in over a year) but it conflicts with catalyst.
Well I fixed it by installing linux-headers and catalyst-hook, then it built fglrx and I could run modprobe from there. I've been able to simply use catalyst, catalyst-utils for ages, not sure changed. If anyone could shed some light on the subject I would appreciate it.
Oh well, more time wasted fixing things on Arch that have worked for quite some time. For some reason I find myself doing that quite a bit lately......
Last edited by DarksideEE7 (2012-10-07 07:30:43)
Offline
sudo modprobe fglrx
ERROR: could not insert 'fglrx': Exec format erro
I had the same error yesterday, fixed it by installing catalyst-hook
Offline
I think the Catalyst-DKMS package is not doing what it should. Lordheavy, can you shed some light on this? (also, an echo telling users to enable the dkms.service if using systemd would be handy in the .install file)
Last edited by Unia (2012-10-07 10:23:10)
If you can't sit by a cozy fire with your code in hand enjoying its simplicity and clarity, it needs more work. --Carlos Torres
Offline
Unia wrote:EDIT: Tested and confirmed. Information added to the Wiki. Do users from the unofficial [Catalyst] repo also need to perform specific actions?
Hello, I'm using catalyst-hd234k repository and catalyst-hook on a pure systemd setup. Just wanted to mention that catalyst-hook automatically rebuilt the FGLRX module during new Linux kernel 3.5.5 installation process and there weren't any need to perform specific actions.
Thanks. I was actually refering to the regular catalyst and catalyst-utils packages, without the use of catalyst-hook, catalyst-daemon and the like. Always good to get confirmation though.
siavashserver wrote:Unia wrote:EDIT: Tested and confirmed. Information added to the Wiki. Do users from the unofficial [Catalyst] repo also need to perform specific actions?
Hello, I'm using catalyst-hd234k repository and catalyst-hook on a pure systemd setup. Just wanted to mention that catalyst-hook automatically rebuilt the FGLRX module during new Linux kernel 3.5.5 installation process and there weren't any need to perform specific actions.
As far as I know, that's only the case if one's using the vanilla kernel because upon installing catalyst-hook, (only) 'linux-headers' is added to the 'SyncFirst' line in pacman.conf. I had to manually add 'linux-lts-headers' for automatic re-compilation (of the fglrx module) to work when updating the lts kernel.
That's correct, it's stated in the Wiki. It doesn't say however, that you can use another kernel-headers, so I'll edit that part.
Unia wrote:What exactly does this atievents daemon do? I might have to add it.
According to its manpage it handles ACPI events.
Oh, thanks. Never thought of looking for a manpage But still, I don't have it enabled and Catalyst does know when I close my lid etc, so is it really necessary to enable this?
If you can't sit by a cozy fire with your code in hand enjoying its simplicity and clarity, it needs more work. --Carlos Torres
Offline
Oh, thanks. Never thought of looking for a manpage But still, I don't have it enabled and Catalyst does know when I close my lid etc, so is it really necessary to enable this?
I think it is needed for power management.
Offline
Unia wrote:Oh, thanks. Never thought of looking for a manpage But still, I don't have it enabled and Catalyst does know when I close my lid etc, so is it really necessary to enable this?
I think it is needed for power management.
Gonna look into it!
If you can't sit by a cozy fire with your code in hand enjoying its simplicity and clarity, it needs more work. --Carlos Torres
Offline
spirtbrat wrote:Unia wrote:Oh, thanks. Never thought of looking for a manpage But still, I don't have it enabled and Catalyst does know when I close my lid etc, so is it really necessary to enable this?
I think it is needed for power management.
Gonna look into it!
Probably offtopic, but atieventsd.service and /usr/lib/modprobe.d/catalyst.conf are missing from legacy 12.6 drivers.
Offline
^ Yes, those files are supplied when using Catalyst from [community], Vi0L0's repositories do not contain these files.
If you can't sit by a cozy fire with your code in hand enjoying its simplicity and clarity, it needs more work. --Carlos Torres
Offline
Great job lordheavy and Unia for working on both fglrx and wiki! Cleanup was really needed and i'm sure we all here appreciate you work! Nice!
I must to admit that i forgot about atieventsd completelly, i was testing it only when i became catalyst's maintainer (3 years ago) but it was useless on my hd4850.
IIRC then it wasn't working well also on laptops, kinda buggy often caused cpu to work on 100%. So i just forgot about it...
Today situation could be different - maybe it will work better on laptops? - i cannot test it though, but anyway i have a question:
@lordheavy:
can i borrow your atieventsd.service?
Probably offtopic, but atieventsd.service and /usr/lib/modprobe.d/catalyst.conf are missing from legacy 12.6 drivers.
Not offtop at all
/usr/lib/modules-load.d/catalyst.conf is in the repo for some time (like month...), but not with all packages, soon i will propagate it.
sudo modprobe fglrx
ERROR: could not insert 'fglrx': Exec format error
i have updated catalyst and catalyst-lts to work with new kernels (3.5.5 and -44)
I think the Catalyst-DKMS package is not doing what it should. Lordheavy, can you shed some light on this? (also, an echo telling users to enable the dkms.service if using systemd would be handy in the .install file)
There isn't too much info about dkms on arch wiki.
Important question is: "When fglrx will be rebuilt?". If i will reboot my pc after installing kernel will fglrx module be loaded?
When im looking at systemd it's like a stream, like a river - hard to stop, is it possible for dkms to stop this river and kindly build fglrx before starting X, or dkms will build module sooner - ie before reboot, while shutdown? Or is there a risk that X won't start or will start in vesa?
BTW: Some users asked for it so i've put also amdstream into the repo. Mike where r u?
Oh! and i can that there's xorg-server 1.13 in [testing], can testers tell if catalyst-test@AUR is working for them? (and on what gpu?)
Edit:
3. How many of the backported Xorg repos should we list? I don't think there's people using a driver older than 6 months...
4. I'm also note sure about the last NOTE in the Catalyst-daemon paragraph. I have never used any of these tools, so I need other people to confirm and check this for me.
Once again: awesome work on wiki!
ad3. we should remove all except 111 and 112 (... done)
ad4. last NOTE is true. for now please leave daemon as is, i will try to find some time and work once again on it's systemd service and if i will fail i will remove this package.
Edit2:
the one and only true about AMD's catalyst release schedule:
http://phoronix.com/forums/showthread.p … post260589
Last edited by Vi0L0 (2012-10-07 16:18:16)
Offline
Thanks Vi0L0! Are you going to look into the atievents? You're probably going to get more information than me, anyway
If you can't sit by a cozy fire with your code in hand enjoying its simplicity and clarity, it needs more work. --Carlos Torres
Offline
I think removing /etc/ati/amdpcsdb manually as mentioned in ATI Catalyst - Configuring X is a little tedious. I suggest adding a few more lines into catalyst_build_module's remove_module() function will make the life easier :
## /usr/bin/catalyst_build_module
remove_module(){
# Some magic
# Some more magic
# Hope this works :P
if [ -f "/etc/ati/amdpcsdb" ]; then
rm "/etc/ati/amdpcsdb" &>/dev/null
fi
}
Thanks everybody for great job on providing drivers and maintaining Wiki page!
Offline
About atieventsd. Just saw that it put lots of these in the syslog:
Oct 07 19:16:41 sterminal atieventsd[288]: /etc/ati/authatieventsd.sh: line 30: pidof: command not found
Oct 07 19:16:41 sterminal atieventsd[288]: /etc/ati/authatieventsd.sh: line 69: return: -1: invalid option
Oct 07 19:16:41 sterminal atieventsd[288]: return: usage: return [n]
Oct 07 19:16:42 sterminal atieventsd[288]: /etc/ati/authatieventsd.sh: line 30: pidof: command not found
Oct 07 19:16:42 sterminal atieventsd[288]: /etc/ati/authatieventsd.sh: line 69: return: -1: invalid option
Oct 07 19:16:42 sterminal atieventsd[288]: return: usage: return [n]
authatieventsd.sh is atieventsd's X authorization script. It "provides a distro-neutral way for the daemon to gain access to the necessary X server display in order to send it commands". This script is messed up and smells old. Definitely not working with GDM.
It can be changed and the new version invoked with '--xauthscript=SCRIPT' put in the atieventsd.service file.
authatieventsd.sh cannot possibly find the X authorization file the way it is written, when running GDM.
You can identify the file with something like:
dirname $(xauth info | awk '/Authority file/{print $3}')
if ran as the current user. But it will not work, as authatieventsd.sh is invoked with root privileges.
Offline