I've been playing about with these things lately, and discovered a couple of things about the fglrx driver on Ubuntu that I thought worth sharing in the context of a broader question.
The atieventsd daemon is a daemon installed when one installs the proprietary fglrx drivers from AMD for an ATI discrete GPU. The idea, as I understand it, is to monitor various acpi events, such as a laptop lid close, or an AC connect/disconnect, presumably to let the GPU know for reasons of power saving. See the man page for more info.
On my system, Ubuntu 13.10, and with the latest drivers from Catalyst, 13.12, the daemon installs itself at /etc/alternatives/x86_64-linux-gnu_atieventsd with a symlink to that at /usr/bin/atieventsd.
Problem number 1:
The Sys-V-init script, /etc/init.d/atieventsd thinks the symlink is elsewhere, namely /usr/sbin/atieventsd (i.e. sbin not where it actually is, bin)
So to launch successfully the atieventsd on startup I had to do make the change:
DAEMONPATH=/usr/bin/atieventsd
it's also convenient whilst there to add the debugging options, and the additional second log for now:
DAEMONOPTS="--debug --logfile=/var/log/atieventsd.log"
Then remove/regenerate the run levels:
cd /etc/init.d
mv atieventsd atieventsd.temp
update-rc.d atieventsd remove
mv atieventsd.temp atieventsd
update-rc.d atieventsd defaults
This should now at least allow the daemon to correctly start/stop. You can test with service atieventsd start.
Problem number 2:
On each startup the daemon attempts to launch a script, /etc/ati/authatieventsd.sh (by default) , whose purpose is to grant the atieventsd daemon authorization access to the X server display, so it can send it various commands.
This script is called by atieventd like (see ps aux | grep atieventsd after starting the service or booting)
/etc/ati/authatieventsd.sh grant :0 /tmp/atieventsdGWt098
Here argument one ($1) is the action: grant/revoke
, argument two ($2) is the X display number (e.g :0), and argument three ($3) is the file wanting the authority. See the xauth man page for some more background.
The problem is that if you look at the /etc/ati/authatieventsd.sh script you will see it does not support lightdm, you need to add the chunk of code inside the GetServerAuthFile() function:
#Check lightdm
LIGHTDM_AUTH_FILE=/var/run/lightdm/root/$1
if [ -e $LIGHTDM_AUTH_FILE ]; then
SERVER_AUTH_FILE=$LIGHTDM_AUTH_FILE
DISP_SEARCH_STRING="unix$1"
return 0
fi
to allow it find the correct server authentication file. Save this and you should
see a file in the /tmp directory of the form atieventsdGWt098, the next time the atieventd is stopped/start (or next reboot), and if you do
xauth -f /tmp/atievntX.Dh1AJV list
you should get something like
yourHostname/unix:0 MIT-MAGIC-COOKIE-1 98deg034234kkn34234mmm3242
Showing that the daemon has indeed been granted authority.
You can also look at the /var/log/atieventsd.log log, and you should see everything is now working correctly, and the daemon is responding to events such as unplugging the AC and lid closes. For example:
<Dbg>: ACPI event: ac_adapter AC 00000080 00000000
<Dbg>: ACPI event: processor CPU0 00000081 00000000
processor CPU1 00000081 00000000
processor CPU2 00000081 00000000
processor CPU3 00000081 00000000
The broader questions
Is this atieventsd actually necessary in the modern driver? Is power managed some different way? Has the daemon been succeeded and it was no accident that this thing came broken? Was it really this broken on purpose??
