2

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??

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.