[LUG.ro] Haciendo funcionar la placa de Sonido Intel HDA en una Laptop

[Guillermo Ibañez]

Hola amigos, espero que éste sea una adelanto de un mail mayor que 
pienso mandar cuando termine de configurar mi laptop TOSHIBA Satellite 
P100 bajo linux.

La razón por la que adelanto esta parte referente al sonido es porque en 
una sola semana vi 2 laptops de otra marca pero problemas similares para 
la placa Intel.

No voy hacer aquí el paso a paso, dado que existen una infinidad de 
páginas donde lo detallan con mucha claridad.  Me voy a limitar a dar 
una introducción al problema de las DSDT, tirar algunos lineamientos 
generales y referenciarlos a las páginas adecuadas.

Si tienen una placa Intel HDA y una Laptop, probablemente vean los 
módulos alsa haciendo "lsmod" pero no tendrán sonido.

Lo primero que hay que tener en cuenta es que esa placa no funciona con 
las librerias de Alsa-1.0.13, que son las que están en la mayoría de las 
distribuciones.  Para que la placa funcione correctamente necesita de 
unos codecs que se encuentran recién en la versión 1.0.14 de alsa.  Por 
lo tanto, les recomiendo que antes que nada, verifiquen que tienen la 
1.0.14 o superior, y en caso contrario bajar la última versión de la 
página oficial de alsa:

http://www.alsa-project.org

Si aún así no funciona, la razón puede ser tu DSDT:

Lo segundo a tener en cuenta, y para nada menos importante, es que el 
problema de la placa Intel HDA con las Laptops es en realidad una 
consecuencia de un problema mayor asocido con las ACPI.  Las ACPI es una 
interfaz normalizada definida por TOSHIBA, Microsoft, Intel, HP, y 
Phoenix (Advanced Configuration & Power Interface http://www.acpi.info 
).  La idea es que una serie de rutinas ayudan al SO a configurar el 
Hardware.  Es la misma que maneja el control de Encendido en las 
Desktops, pero en las Laptops, es responsable de la configuración de la 
mayor parte del Hardware de las mismas.

Uno de los componente vitales en la ACPI es un programa llamado DSDT, 
que básicamente es un programita en "aml" (ACPI Machine Language) y éste 
es el corazón del problema.

Este programa se escribe en un leguaje llamado "asl" (ACPI Source 
Language) y existen 2 compiladores que se encargan de traducir el 
DSDT.asl al DSDT.aml.  Uno es de Intel y el otro de Microsoft.

Uno de los problemas que surgen es que el compilador de Microsoft no 
cumple con el estandar ACPI al 100% y falla al no dar determinados 
"Warnings" ni Errores.  Sin embargo eso no es muy grave si corres un 
Windows, dado que el Windows no se preocupa justamente por esos errores, 
pero si corres un LINUX, que cumple estrictamente con el estandar ACPI, 
muchos de los componentes podrían ser no reconocidos por culpa de fallas 
en el DSDT no detectadas en la compilación.

El otro de los problemas, es que en el DSDT, para algunos hardware, y 
creo que es el caso de la Intel HDA, está escrito EXPLICITAMENTE que no 
se active el hardware salvo que se esté ejecutando Windows, e incluso 
algunos windows determinados (XP, vista, etc).

La mejor solución a estos problemas es la de corregir el DSDT, pero no 
es siempre fácil y posiblemente no sea necesario.  Por eso antes 
recomiendo dos pruebas básicas que pueden funcionar como soluciones 
parciales o totales.

Antes que nada recuerden que si no tienen el Alsa 1.0.14, ninguna pruba 
funcionará- Instálenlo!

La primera prueba es un parche pero muy util para saber si el problema 
está en la DSDT.  Consiste en pedirle al kernel que nó ejecute la DSDT y 
que en su lugar trate de activar el Hard a mano.

Para esto hay que pasar al kernel (en el LILO o en el GRUB) el 
parámetro: acpi=off

Si prueban y tienen sonido, es porque sin duda es la DSDT.  Eso sí, 
perderán el manejo del encendido de la PC y probablemente pierdan otros 
Hards, incluso el video. Si les sirve es una solución temporal.

La otra prueba, a mí no me funcionó.  Probablemente porque tenía una 
combinación  de los dos problemas descriptos arriba de las DSDT (el 
compilador MS y la restricción de Intel para otros OS no Windows).  
Consiste en pedirle al kernel que le mienta a la DSDT cuando le pregunte 
su nombre.

Para esto se agrega al GRUB o LILO el parámetro de kernel: 
acpi_os_name="Windows"
(o "Windows XP" o "Windows 2000" o "Microsoft Windows" o "Windows 
2006",.... hagan varias pruebas).

Una de las cosas interesantes es que se puede detectar si su DSDT fue 
compilado por el compilador Intel o Microsoft, viendo los mensajes del 
Log de arranque de Linux.  Si descubren que su DSDT fue compilado con un 
compilador de Intel, entonces estimo que usar el parámetro acpi_os_name, 
será suficiente para tener sonido y DSDT sin necesidad de correcciones 
del mismo (GRAN VENTAJA).

Sin embargo, parte del proceso para corregir la DSDT consiste en 
desensamblar el DSDT.aml a un DSDT.asl, lo que permite averiguar que 
string  específico espera la DSDT para el parámetro acpi_os_name.

Pasamos al ogro:

El proceso para corregir la DSDT es el siguiente:

    1) Averiguar si tu DSDT fue compilado por Microsoft
    2) Bajar e instalar el compilador y descompilador de Intel
    3) Obtener el DSDT.aml de /proc/acpi/dsdt, con un simple cp de dicho 
archivo a un directorio de trabajo (yo lo copié al directorio del 
compilador de Intel)
    4) Descompilarlo para obtener el fuente.
    5) Recompilar el fuente para detectar los errores
    6) Tratar de corregir los errores (y crackear la parte donde 
pregunta el nombre del SO)
    7) Agregar el nuevo DSDT en el Initrd para que el kernel lo cargue 
en lugar del original al booteo (el original sigue en la PC, el kernel 
simplemente carga el nuestro en lugar del original, con lo que no hay 
peligro de dañar el DSDT original por error).  Este último punto puede 
requerir (dependiendo de la distribución de linux que tengas) que 
instales un parche que permite al kernel cargar el nuevo DSDT desde el 
Initrd.


Los puntos 1,2,3,4 y 5 y casi toda la introducción está muy bien 
detallada en la siguiente página:


http://gentoo-wiki.com/HOWTO_Fix_Common_ACPI_Problems   (la biblia del 
asunto)


Por otro lado, en la página:

http://www.linuxquestions.org/questions/susenovell-60/howto-fix-acpi-ich7-family-conexant-driver-on-toshiba-p100105-series-531575/#post2642299

Se dan otros ejemplos para corregir la DSDT (paso 5), justo los de mi 
Laptop (que suerte!) y al final muestra como crackear la DSDT para que 
no discrimine por SO (paso 6).


Finalmente, el paso 7, necesita como ya les dije de un parche en el Kernel.

Para saber si tienen el parche, intenten configurar el kernel con "make 
menuconfig" o su preferido, y fíjensen si está la opción:

    Power Managment Options-->
        ACPI Support-->
            Read DSDT from Initrd [*]

(por supuesto que se necesita tener la opción Initrd activada)

Si no lo tienen, pueden bajar el parche adecuado de:

http://gaugusch.at/kernel.shtml

Si no tenian el parche o si la opción no estaba activada, hay que 
recompilar el kernel.

Luego hay que grabar el DSDT.aml corregido en /etc/InitrdTools (o algo 
así) y ejecutar:

mkinitrd con las opciones necesarias.

por ejemplo, en mi caso:

mkinitrd -k -o /boot/initrd-2.6.18-conDSDT 2.6.18

-o es el nombre de la imagen, el -k es para que preserve los temporales 
y uno pueda revisar el contenido de la imagen creada (y revisar que el 
DSDT colocado en el initrd sea el correcto), y finalmente la última 
opción es la versión, que le dice de donde sacar los módulos 
(/lib/modules/2.6.18) para generar el initrd.

En mi caso, tengo Debian y me costó un poco indicarle de donde sacar los 
módulos, asique finalmente opté por compilarlos como partes del kernel 
(no como módulos) a los drivers de SATA-scsi y ext3, de tal modo que en 
el initrd no se necesite nada más que el DSDT, sin módulos.  Funcionó 
perfectamente.

Ahora tengo sonido con ACPI! Suerte a quién le corresponda!

PD: No lo especifiqué pero hay que generar una nueva entrada en el GRUB 
o LILO que apunte al nuevo kernel y nuevo initrd.img, siempre 
resguardando una copia y una entrada en el GRUB/LILO de los antiguos por 
las dudas algo falle.