Instalando controladores propietarios de ATI radeon 9250 en MDV 2007

Siguiendo las instrucciones de la sección, si tuvieramos un controlador patentado de ATI instalado previamente con el instalador de ATI nos dirigiremos a la carpeta /usr/share/fglrx y ejecutaremos como root "sh ./fglrx-uninstall.sh". Si lo hubieramos instalado con un paquete rpm, simplemente usariamos el comando "rpm -e" o "urpme".
Del resto de las notas de la versión del controlador se puede mencionar que ATI proporciona un formulario para recabar comentarios de usuarios.

Por lo demás pasaríamos ya al documento "notas de la versión del instalador".

De las tres primeras notas que aparecen, la primera recomienda crear una ubicación centralizada para las descargas del software de ATI, la segunda recomienda desinstalar cualquier versión previa del controlador (ya se ha visto) y la tercera informa que el comando "fglrxconfig" ya no se proporciona en el software, ahora hay que usar "aticonfig".
Seguimos leyendo que hay paquetes específicos para distribuciones, ya sean directamente soportados por ATI o empaquetados por terceeros, incluso el propio instalador permitiría la creación de paquetes específicos.
Pasamos a los requerimientos mínimos del sistema, que ya hemos visto antes. Pero prestamos atención a la nota que dice que si el kernel 2.6.11 o posterior se ha compilado con soporte para AGP, el frontend AGP hace falta para cargar el módulo del núcleo "fglrx". Para saber si nuestro núcleo tiene configurado AGP y si está como módulo hacemos "grep CONFIG_AGP /usr/src/linux/arch/i386/defconfig", cambiando la carpeta "i386" por la que se corresponda con nuestra arquitectura (p.e. "x86_64".
En mi caso devuelve:
CONFIG_AGP=m
CONFIG_AGP_ALI=m
CONFIG_AGP_ATI=m
CONFIG_AGP_AMD=M=m
CONFIG_AGP_AMD64=m
CONFIG_AGP_INTEL=m
CONFIG_AGP_NVIDIA=m
CONFIG_AGP_SIS=m
CONFIG_AGP_SWORKS=m
CONFIG_AGP_VIA=m
CONFIG_AGP_EFFICEON=m
por lo que deduzco que tengo soporte para AGP, siempre como módulos externos al kernel.
Para comprobar si está cargado el módulo agpgart ejecutamos "lsmod|grep agpgart" o simplemente "lsmod|more" y si muestra el módulo en la lista es porque está cargado. En mi caso no lo está.
Leemos los requisitos recomendados, ya mencionados antes. ¿Tenemos instaladas las fuentes de nuestro núcleo o las cabeceras? Sí.
¿Tenemos habilitado el soporte para ISSE (Internet Streaming Single-Instruction, Multiple-Data Extensions; an
extension of the IA-32 instruction set in Pentium III processors)? Dice que viene por defecto en los núcleos posteriores al 2.4 y claro con procesadores superiores a un Pentium III. Bueno pues yo tengo un kernel alternativo que me parece que está compilado para i386. En fin si tengo problemas más tarde ya me plantearé si recompilar el kernel o usar el kernel original de MDV2007. EL paquete rpm lo tenemos instalado sobradamente. Sobre QT versión 2.x.x, tengo varios paquetes (librerías, etc...) qt3-3.3.6 y qt4-4.1.4, supongo que valdrán...
Llega el momento de la instalación en sí y llega la primera duda:
¿Necesito ejecutar el instalador ati-driver-installer-8.28.8.run y a continuación instalar el fglrx_6_8_0-8.28.8-1.i386.rpm?
Seguramente los dos archivos contengan lo mismo o parecido y el primero esté pensado para sistemas que no manejen rpm. Pero comprobar los archivos que llevan cada uno no es difícil. Pero ya que nos ponemos averigüemos que contiene el paquete de plf ati-8.28.8-3plf2007.0.i586.rpm que va ligado al paquete dkms-ati-8.28.8-3plf2007.0.i586.rpm.
Tras explorar un poco los contenidos, parece que son métodos alternativos para la instalación. Por tanto vamos a usar los paquetes de plf que nos dará un sistema más limpio y ordenado.
Antes de empezar, si no lo habíamos hecho ya, ejecutamos XFdrake para elegir una tarjeta gráfica estándar, por ejemplo la "ati" del grupo "Xorg" (Hay dos grandes grupos: Vendor y Xorg) e indicar que no lance las X al iniciar el sistema. Con esto iniciamos en modo consola, accediendo como superusuario.

Una vez elegido el método de instalación, paquetes de plf, procedemos con la instalación usando "urpmi". Para ello hemos de tener fuentes de software plf. Si no las tenemos se añaden ejecutando como root lo siguiente (para x86):
urpmi.addmedia plf-free ftp://ftp.free.fr/pub/Distributions_Linux/plf/mandriva/2007.0/free/release/binary/i586/ with hdlist.cz
urpmi.addmedia plf-nonfree ftp://ftp.free.fr/pub/Distributions_Linux/plf/mandriva/2007.0/non-free/release/binary/i586/ with hdlist.cz

Entonces ejecutamos:
"urpmi ati"
para resolver las dependencias se instalarán los paquetes
dkms-ati-8.28.8-3plf2007.0.i586.rpm
ati-8.28.8-3plf2007.0.i586.rpm
seguimos adelante sin contemplaciones, al final la información del paquete nos dice que ejecutemos XFdrake para elegir como tárjeta gráfica "fglrx" (que la elige directamente XFdrake) y respondamos a todo que sí.
Alternativamente se puede editar el archivo "xorg.conf" y luego ejecutar "update-alternatives --config gl_conf".
Tras la instalación seguimos la alternativa de usar XFdrake para actualizar la configuración de las X.
ADVERTENCIA: hasta que no estés seguro de que la configuración de las X funciona correctamente no marques la casilla "Activación automática del interfaz gráfico (Xorg) al arrancar".
Tras elegir la tarjeta fglrx probamos la configuración sin salir de XFdrake. Por desgracia cuando tendría que mostrarse el interfaz gráfico, simplemente se interrumpe la señal de la tarjeta gráfica hacia el monitor, vamos que no funciona.
Comprobaciones:
Reiniciamos la máquina y probamos a lanzar las X con el comando startx, que nos dará una información en pantalla y en el archivo de registro: "/var/log/Xorg.0.log" o variantes.
Pues ocurre lo mismo que antes: no funciona. Además para volver a la consola tengo que pulsar "Ctrl+Alt+Bkspc".
El mensaje en consola es un extracto del log anterior mostrando sólo los mensajes de advertencia (1) y error (3):
(WW) fglrx: No matching Device section for instance (BusID PCI:1:0:1) found
(EE) fglrx(0): [agp] unable to acquire AGP, error "xf86_ENODEV"
(EE) fglrx(0): cannot init AGP
(EE) AIGLX: Screen 0 is not DRI capable

Empezaremos con los errores, que parece que deben ser lo más crítico.
Para saber lo que significa el primer error vemos que en el paquete "ati" que instalamos hay un archivo que lo explica. Se trata de "/usr/share/doc/ati-8.28.2/articles/xf86_enodev.html".
De su lectura se traduce que necesitamos cargar el módulo AGP propio del controlador de nuestra placa base (ademas del agpgart que ya está cargado). Para averiguar qué chipset lleva el puerto AGP ejecutamos "lspci" y leyendo con detenimiento encuentro, en mi caso, que se trata de un Intel. Si vemos el mensaje anterior, cuando verificamos que el kernel no llevaba ningún controlador AGP internamente, hemos sacado una lista de los módulos AGP con "grep CONFIG_AGP /usr/src/linux/arch/i386/defconfig":
CONFIG_AGP=m
CONFIG_AGP_ALI=m
CONFIG_AGP_ATI=m
CONFIG_AGP_AMD=M=m
CONFIG_AGP_AMD64=m
CONFIG_AGP_INTEL=m
CONFIG_AGP_NVIDIA=m
CONFIG_AGP_SIS=m
CONFIG_AGP_SWORKS=m
CONFIG_AGP_VIA=m
CONFIG_AGP_EFFICEON=m
Estos módulos están en "/lib/modules/'uname -r'/kernel/drivers/char/agp".
Por tanto para mi caso debo cargar el módulo agp de intel. Ejecuto:
"modprobe intel-agp" y voilà cargado el controlador agp de la placa. Lo comprobamos con un "lsmod|grep agp" y ahí aparece:
intel_agp 29084 1
agpgart 38092 2 intel_agp,fglrx

Para ver si el error ha desaparecido ejecutamos de nuevo startx y vuelve a fallar el inicio de las X con los siguientes mensajes:
(WW) fglrx: No matching Device section for instance (BusID PCI:1:0:1) found
(EE) AIGLX error: dlsym for --driCreateNewScreen_20050727 failed (/usr/lib/dri/atiogl_a_dri.so: undefined symbol --driCreateNewScreen_20050727)
(EE) AIGLX: reverting to software rendering

Vemos que el error de AGP ya está resuelto, pero nos convendrá que el módulo intel-agp se cargue al iniciar el ordenador, por eso añadimos la línea:
intel-agp
al archivo "/etc/modprobe.preload".
Los dos siguientes errores:
(EE) AIGLX error: dlsym...
(EE) AIGLX: reverting to software rendering
los dejaré para después porque posiblemente, tampoco sean la causa de que no arranquen las X ya que se traduce: "revirtiendo al renderizado por software", vamos que no consigue que renderice la tarjeta gráfica y devuelve esa facultad al software (mesa supongo).
La advertencia que aparece es fácil resolverla/comprenderla. Nos remitimos a las preguntas frecuentes del wiki de X.Org. Existe una sección dónde se explican los mensajes de advertencia.
Encontramos el significado del mensaje de advertencia que me aparece y la causa de que me aparezca:
(WW) fglrx: No matching Device section for instance (BusID PCI:1:0:1) found
Significa que el controlador es capaz de manejar el dispositivo "PCI:1:0:1" pero "Xserver" no encuentra una sección "device" apropiada para él en el archivo de configuración (/etc/X11/xorg.conf).
La causa de que me aparezca la explica a continuación: algunos dispositivos incluyen múltiples identificadores para la misma ranura (la AGP en este caso). Las Radeon duales por ejemplo muestran el identificador PCI:1:0:0 y PCI:1:0:1. El segundo dispositivo es virtual y sólo existe para dar compatibilidad con algunos sistemas operativos. Se puede ignorar este mensaje de error sin riesgo.
Compruebo con "lspci"
01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01)
01:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (Secondary) (rev 01)
que efectivamente el dispositivo "PCI:1:0:1" es el secundario y la sección "device" de xorg.conf maneja el dispositivo primario.
Si no fuera el caso, Xserver al no encontrar ninguna sección "device" válida para otro dispositivo (gráfica) devolvería un error: (EE) No devices detected y no iniciaría las X. Esto se solucionaría incluyendo la línea "BusID "PCI:1:0:1"" en la sección device de xorg.conf que se ajusta a nuestra tarjeta gráfica. Sin embargo si yo incluyo la línea "BusID "PCI:1:0:1"" el mensaje de adevertencia ahora me mostraría que no encuentra el dispositivo primario BusID "PCI:1:0:0".
Para descartar que los errores de AIGLX sean lo que provoca que no me arranquen las X hacemos cambiaremos el archivo "/etc/X11/xorg.conf"
1º Las líneas dentro de la sección "Module"
Load "glx" # 3D layer
Load "dri" # direct rendering
las marcamos como comentario:
# Load "glx" # 3D layer
# Load "dri" # direct rendering
2º Dentro de la sección "Device" cambiamos
# === disable/enable XAA/DRI ===
Option "no_accel" "no"
Option "no_dri" "no"
por
# === disable/enable XAA/DRI ===
Option "no_accel" "yes"
Option "no_dri" "yes"
Ahora volvemos a lanzar las X con "startx".
Sin embargo persiste el problema: no arrancan las X ni así. O quizás sí arrancan pero no consiguen que la tarjeta gráfica se comunique con mi monitor. Lo digo porque la pantalla se queda en negro mostrando el mensaje (del propio monitor) de que no le llega señal gráfica, y para volver a la consola es necesario pulsar "Ctrl+Alt+Bkspc".

Pues bien, este elocuente título lo dice todo.
No sé cuando y dónde leí algo acerca de las limitaciones de la conexión digital entre la tarjeta gráfica y el monitor. Por lo visto, he aquí otra ( quan el mal vé d'Almansa...): siguiendo el método ensayo-error probé a usar un cable HD15 (el de toda la vida) para conectar el monitor y por fin me arrancan las X. No me ha dado por volver a probar el cable digital para confirmar el fallo. Lo dejo para un futuro...
Por tanto ahora trataré de recopilar los consejos que inundan nuestro foro y otros para solucionar el problema de la aceleración 3D, ya que mi "dri" no funciona todavía.
Las advertencias y errores que registra Xserver al arrancar son las siguientes:

[root@Turandot jonatan]# cat /var/log/Xorg.0.log |grep WW
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)
(WW) fglrx: No matching Device section for instance (BusID PCI:1:0:1) found
(WW) fglrx(0): board is an unknown third party board, chipset is supported
(WW) fglrx(0): MonitorLayout is no longer supported.
(WW) fglrx(0): Option "IgnoreEDID" is not used
(WW) fglrx(0): Option "NoTV" is not used
[root@Turandot jonatan]# cat /var/log/Xorg.0.log |grep EE
Current Operating System: Linux Turandot 2.6.17.13-mm-desktop-3mdvsmp #1 SMP PREEMPT Tue Sep 19 22:42:42 EDT 2006 i686
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(II) Loading extension MIT-SCREEN-SAVER
(EE) AIGLX error: dlsym for __driCreateNewScreen_20050727 failed (/usr/lib/dri/atiogl_a_dri.so: undefined symbol: __driCreateNewScreen_20050727)
(EE) AIGLX: reverting to software rendering

Como dice pacho en el foro... deshabilitamos "composite":

Section "Extensions"
    Option "Composite" "0"
EndSection

Section "dri"
   Mode 0666
EndSection

y reiniciamos la computadora (tocando madera)

Conectamos la tajeta gráfica radeon 9250 y el monitor usando el cable HD15 en lugar del DVI-D. A pesar de lo que dice /usr/share/doc/ati-8.28.8/articles/rv280dviblankdisplay.html sigue apareciondo una pantalla negra

Desinstalamos cualquier versión anterior del controlador que pudieramos tener instalada.

Instalamos las fuentes correspondientes al núcleo que ejecutamos en nuestro ordenador. Si tenemos más de un núcleo, el controlador sólo funcionará con aquél del que tangamos instaladas las fuentes.
No es necesario instalar las fuentes completas solo las cabeceras. Es decir, es suficiente instalar el paquete "kernel-source-stripped..." que es más pequeño

Instalamos el controlador de ati Version 8.28.8, que es el máximo que da servicio a la radeon 9250. Lo hacemos siguiendo el método que más nos convenga. El más fácil es añadir a urpmi las fuentes de plf y hacer una instalación por el método habitual.

Seguimos las instrucciones de "/usr/share/doc/ati-8.28.8/README.install.urpmi" para que Xserver utilice el controlador "fglrx".
You can reconfigure X either automatically:
1. Run XFdrake as root.
2. Go to the Graphics Card list.
3. Select the "Radeon (fglrx)" (it is usually already autoselected).
4. Answer any questions asked and then quit.

OR you can do it manually by editing /etc/X11/xorg.conf:
1. Change the Driver to "fglrx" in the Device section.
2. Run "update-alternatives --config gl_conf" and select ati.conf.

Para evitar el error
(EE) fglrx(0): [agp] unable to acquire AGP, error "xf86_ENODEV"
seguimos las instrucciones de /usr/share/doc/ati-8.28.8/articles/xf86_enodev.html
nos aseguramos de que el modulo agpgart se cargue correctamente; hacemos lo mismo con el módulo del AGP de nuestra placa base.
Para que el módulo intel_agp (o el de nuestra placa) se cargue a cada inicio del ordenador eitamos el fichero "/etc/modprobe.preload" le añadimos la línea 
intel-agp

Para evitar el error 
(EE) AIGLX error: dlsym for __driCreateNewScreen_20050727 failed (/usr/lib/dri/atiogl_a_dri.so: undefined symbol: __driCreateNewScreen_20050727)
 basta con editar xorg.conf y añadir dentro de la sección ServerLayout lo siguiente:
Section "ServerLayout"
    ...
    Option         "AIGLX" "false"
    ...
EndSection
Con esto deshabilitamos AIGLX y ya no nos dá ningún mensaje de error (EE), sólo advertencias (WW)

Más tarde pondré la salida de cat /var/log/Xorg.0.log|grep WW y mi xorg.conf. También se ha comentado en el foro la conveniencia de deshabilitar composite y añadir una sección "dri".
Pero creo que finalmente no es necesario. Intentaré averiguar si hay una forma de mejorar el rendimiento 3D pues fgl_glxgears me dá unos 150 FPS.

No dejéis de leer:
-La documentación que instala el controlador ati en "/usr/share/doc/ati-8.28.8/", hay muchas respuestas a problemas que han surgido.
-Las FAQ del controlador ATI para linux
-Las notas de la versión del controlador
-Las preguntas frecuentes del wiki de X.Org y su sección mensajes de advertencia
-El manual de xorg.conf

Agradecimientos a Pacho, Ximo Bernà, luismago y todos los que han escrito en el foro servicio técnico sobre el tema.