Se você também é do tipo ávido por experimentar todas as últimas novidades que vivem aparecendo em nossos adorados sistemas GNU/Linux, certamente já passou por algumas inevitáveis dores de cabeça em que inexplicavelmente alguma coisa pára de funcionar.

Recentemente fui vítima disso após fazer o upgrade de meu Slackware 12.2 para a versão current e verificar que meu teclado insistia em funcionar com o layout errado (US), mesmo com a clara regra no xorg.conf especificando um teclado br/abnt2. Após a tradicional análise dos logs e uma boa pesquisa, descobri o porquê, aprendi mais um pouquinho e resolvi escrever este artigo, pois suponho que muita gente ainda vá esbarrar no mesmo problema, que no fundo nada mais é que o resultado da evolução natural do nosso querido sistema.

O servidor X originalmente foi feito para funcionar em diversas plataformas Unix numa época em que não se tinha qualquer padrão garantido entre elas. Por causa disso acabava por duplicar grande parte da funcionalidade que o próprio sistema operacional já disponibilizava, incluindo a abstração de dispositivos de entrada como teclado e mouse. Felizmente hoje temos uma base de sistemas livres GNU/Linux que fornece um ambiente muito mais padronizado, permitindo que o servidor X tire proveito efetivo das funcionalidades já oferecidas pelo sistema operacional.

No caso específico dos dispositivos de entrada, já há algum tempo o kernel do Linux oferece um driver para acesso genérico a dispositivos de I/O: o evdev. Este driver cuida dos detalhes específicos de funcionamento dos dispositivos de entrada e apresenta ao espaço de usuário uma interface para os mesmos. Porém, restava o problema de como o X deveria perguntar ao sistema que dispositivos estariam presentes e como eles deveriam ser tratados de forma específica (por exemplo, qual seria a função de cada botão de um mouse não padrão, ou o mapa de teclado a ser utilizado).

Atualmente isso é tratado por meio do HAL (hardware abstraction layer). O HAL possui um daemon que fica monitorando a criação ou remoção de dispositivos pelo UDEV - sistema de gerenciamento dinâmico de dispositivos, que cria ou deleta entradas no diretório /dev representando os dispositivos conectados ao sistema - e os aplicativos podem então pedir informações sobre os dispositivos existentes ao HAL por meio do protocolo DBUS, que oferece uma forma padronizada de comunicação entre processos.

Enfim, o que ocorre a partir do Xorg 1.5 é que, ao invés de utilizar drivers próprios para tratar os dispositivos de entrada (xkb, mouse etc), o servidor X passou a utilizar o módulo evdev do kernel, obtendo durante sua inicialização a informação de que dispositivos estariam presentes e com que configuração deveria utilizá-los por meio de uma chamada DBUS ao HAL.

Nas seções seguintes pretendo mostrar como identificar se o problema está acontecendo no seu sistema e como reconfigurá-lo para que tudo volte a funcionar como deveria.