fglrx и сломанный демон atieventsd (+ может улучшить время автономной работы для владельцев карт AMD)

В последнее время я играл с этими вещами и обнаружил пару вещей о драйвере fglrx в Ubuntu, который, как мне показалось, стоит поделиться в контексте более широкого вопроса.

Демон atieventsd - это демон, устанавливаемый при установке проприетарных драйверов fglrx от AMD для дискретного графического процессора ATI. Насколько я понимаю, идея состоит в том, чтобы отслеживать различные события acpi, такие как закрытие крышки ноутбука или подключение / отключение переменного тока, предположительно, чтобы дать знать графическому процессору по причинам энергосбережения. Для получения дополнительной информации см. man-страницу .

В моей системе, Ubuntu 13.10, и с последними драйверами из Catalyst, 13.12, демон устанавливается в /etc/alternatives/x86_64-linux-gnu_atieventsd с символической ссылкой на /usr/bin/atieventsd.

Задача № 1:

Сценарий Sys-V-init, /etc/init.d/atieventsd считает, что символическая ссылка находится где-то еще, а именно /usr/sbin/atieventsd (то есть sbin не там, где это действительно так, bin)

Итак, чтобы успешно запустить atieventsd при запуске, мне нужно было внести изменения:

 DAEMONPATH=/usr/bin/atieventsd

также удобно, пока там добавлена ​​отладка опции и дополнительный второй журнал на данный момент:

DAEMONOPTS="--debug --logfile=/var/log/atieventsd.log"

Затем удалите / регенерируйте уровни выполнения:

cd /etc/init.d
mv atieventsd atieventsd.temp
update-rc.d atieventsd remove
mv atieventsd.temp atieventsd
update-rc.d atieventsd defaults

Теперь это должно, по крайней мере, позволить демону корректно запускаться / останавливаться. Вы можете проверить с service atieventsd start.

Задача № 2:

При каждом запуске демон пытается запустить скрипт /etc/ati/authatieventsd.sh (по умолчанию), целью которого является предоставление авторизации atieventsd daemon доступа к дисплей X-сервера, поэтому он может отправлять ему различные команды.

Этот сценарий вызывается как atieventd подобно (см. ps aux | grep atieventsd после запуска службы или загрузки)

 /etc/ati/authatieventsd.sh grant :0 /tmp/atieventsdGWt098

Здесь аргумент один ($1) - это действие: grant / revoke , второй аргумент ($2) - это номер дисплея X (например, :0), а третий аргумент ($3) - файл, требующий авторизации. См. Справочную страницу xauth для получения дополнительной информации.

Проблема в том, что если вы посмотрите на скрипт /etc/ati/authatieventsd.sh, вы увидите, что он не поддерживает lightdm, вам нужно добавить кусок кода внутри функции GetServerAuthFile():

#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

, чтобы он мог найти правильный файл аутентификации сервера. Сохраните это, и вы должны увидеть файл в каталоге /tmp вида atieventsdGWt098, в следующий раз, когда atieventd остановится / начнется (или следующая перезагрузка), и если вы сделаете

xauth -f /tmp/atievntX.Dh1AJV list

вы должны получить что-то вроде

yourHostname/unix:0  MIT-MAGIC-COOKIE-1  98deg034234kkn34234mmm3242

Показывающее, что демон действительно получил полномочия.

Вы также можете просмотреть журнал /var/log/atieventsd.log, и вы должны увидеть, что все теперь работает правильно, и демон реагирует на такие события, как отключение переменного тока и закрытие крышки. Например:

<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

Более широкие вопросы

Является ли это atieventsd действительно необходимым в современном драйвере? Управляется ли власть как-то иначе? Был ли демон успешным, и не случайно эта штука сломалась? Действительно ли это было сломано специально?