Eu tenho jogado com essas coisas ultimamente, e descobri algumas coisas sobre o driver fglrx no Ubuntu que eu achei que valeria a pena compartilhar no contexto de uma questão mais ampla.
O daemon atieventsd é um daemon instalado quando um instala os drivers fglrx proprietários da AMD para uma GPU discreta da ATI. A idéia, no meu entender, é monitorar vários eventos de acpi , como o fechamento de uma tampa de laptop ou uma conexão / desconexão de CA, presumivelmente para informar a GPU por motivos de economia de energia. Veja a página de manual para mais informações.
No meu sistema, Ubuntu 13.10 , e com os drivers mais recentes do Catalyst, 13.12, o daemon se instala em /etc/alternatives/x86_64-linux-gnu_atieventsd com um link simbólico para aquele em /usr/bin/atieventsd .
Problema número 1:
O script Sys-V-init, /etc/init.d/atieventsd acha que o link simbólico está em outro lugar, ou seja, /usr/sbin/atieventsd (ou seja, sbin não está onde está, bin )
Então, para lançar com êxito o atieventsd na inicialização, tive que fazer a alteração:
DAEMONPATH=/usr/bin/atieventsd
também é conveniente incluir as opções de depuração e o segundo log adicional por enquanto:
DAEMONOPTS="--debug --logfile=/var/log/atieventsd.log"
Em seguida, remova / regenere os níveis de execução:
cd /etc/init.d
mv atieventsd atieventsd.temp
update-rc.d atieventsd remove
mv atieventsd.temp atieventsd
update-rc.d atieventsd defaults
Isso deve pelo menos permitir que o daemon inicie / pare corretamente. Você pode testar com service atieventsd start .
Problema número 2:
Em cada inicialização, o daemon tenta iniciar um script, /etc/ati/authatieventsd.sh (por padrão), cuja finalidade é conceder o acesso de autorização atieventsd daemon à exibição do servidor X, para que ele possa enviar vários comandos.
Este script é chamado por atieventd like (veja ps aux | grep atieventsd após iniciar o serviço ou a inicialização)
/etc/ati/authatieventsd.sh grant :0 /tmp/atieventsdGWt098
Aqui, o argumento um ( ) é a ação: grant / revoke
, o argumento dois ( ) é o número de exibição X (por exemplo, :0 ), e o argumento três ( ) é o arquivo que deseja a autoridade. Veja o xauth man page para mais informações.
O problema é que, se você olhar o script /etc/ati/authatieventsd.sh , verá que ele não suporta lightdm , você precisa adicionar o trecho de código dentro da função GetServerAuthFile() :
#Check lightdm
LIGHTDM_AUTH_FILE=/var/run/lightdm/root/
if [ -e $LIGHTDM_AUTH_FILE ]; then
SERVER_AUTH_FILE=$LIGHTDM_AUTH_FILE
DISP_SEARCH_STRING="unix"
return 0
fi
para permitir encontrar o arquivo de autenticação correto do servidor. Salve isso e você deve
veja um arquivo no diretório /tmp do formulário atieventsdGWt098 , a próxima vez que o atieventd for parado / iniciar (ou a próxima reinicialização), e se você fizer isso
xauth -f /tmp/atievntX.Dh1AJV list
você deve receber algo como
yourHostname/unix:0 MIT-MAGIC-COOKIE-1 98deg034234kkn34234mmm3242
Mostrando que o daemon realmente recebeu autoridade.
Você também pode olhar para o /var/log/atieventsd.log log, e você deve ver que tudo está funcionando corretamente, e o daemon está respondendo a eventos como desconectar a AC e fechar a tampa. Por exemplo:
<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
As perguntas mais amplas
Isso é atieventsd realmente necessário no driver moderno? O poder é gerenciado de alguma forma diferente? O daemon foi bem sucedido e não foi por acaso que esta coisa foi quebrada? Foi realmente isso quebrado de propósito?