Guía de instalación y archivo README del juego de controladores acelerados para Linux de NVIDIA Última actualización: $Date: 2004/07/24 $ Controlador más reciente: 1.0-6111 El juego de controladores acelerados para Linux de NVIDIA aporta a Linux x86 funcionalidad 2D acelerada, compatibilidad con OpenGL y alto rendimiento, todo ello mediante las unidades de procesamiento gráfico (GPU) de NVIDIA. Estos controladores proporcionan aceleración optimizada por hardware a las aplicaciones OpenGL por medio de un servidor de renderizado directo X Server y son compatibles con los chips de gráficos NVIDIA (consultar el APÉNDICE A para ver la lista completa de los chips soportados). También soportan TwinView, salida a televisión y pantallas planas digitales. Este archivo README contiene las instrucciones de instalación, configuración y uso del juego de controladores acelerados para Linux de NVIDIA. Está disponible en el sitio web de NVIDIA (www.nvidia.com) y se instala en /usr/share/doc/NVIDIA_GLX-1.0/. __________________________________________________________________________ ÍNDICE: (cap-01) CÓMO ELEGIR LOS PAQUETES DE NVIDIA ADECUADOS PARA CADA SISTEMA (cap-02) INSTALACIÓN DEL CONTROLADOR DE NVIDIA (cap-03) MODIFICACIÓN DEL ARCHIVO DE CONFIGURACIÓN DE X (cap-04) PREGUNTAS MÁS FRECUENTES (FAQ) (cap-05) CONTACTO (cap-06) OTROS RECURSOS (ap-a) APÉNDICE A: PROCESADORES GRÁFICOS DE NVIDIA SOPORTADOS (ap-b) APÉNDICE B: REQUISITOS MÍNIMOS DE SOFTWARE (ap-c) APÉNDICE C: COMPONENTES INSTALADOS (ap-d) APÉNDICE D: OPCIONES DEL ARCHIVO DE CONFIGURACIÓN DE X (ap-e) APÉNDICE E: CONFIGURACIÓN DE LA VARIABLE DE ENTORNO OPENGL (ap-f) APÉNDICE F: CONFIGURACIÓN DE AGP (ap-g) APÉNDICE G: PROBLEMAS ESPECÍFICOS DE ALI (ap-h) APÉNDICE H: PROBLEMAS ESPECÍFICOS DE TNT (ap-i) APÉNDICE I: CONFIGURACIÓN DE TWINVIEW (ap-j) APÉNDICE J: CONFIGURACIÓN DE LA SALIDA DE TV (ap-k) APÉNDICE K: CONFIGURACIÓN DE UN PORTÁTIL (ap-l) APÉNDICE L: MODOS DE PROGRAMACIÓN (ap-m) APÉNDICE M: FLIPPING Y UBB (ap-n) APÉNDICE N: PROBLEMAS CONOCIDOS (ap-o) APÉNDICE O: INTERFAZ PROC (ap-p) APÉNDICE P: SOPORTE DE XVMC (ap-q) APÉNDICE Q: SOPORTE DE GLX (ap-r) APÉNDICE R: CONFIGURACIÓN DE VARIAS PANTALLAS X EN UNA TARJETA (ap-s) APÉNDICE S: SOPORTE DE GESTIÓN DE LA ENERGÍA (ap-t) APÉNDICE T: NOMBRES DE DISPOSITIVOS DE VISUALIZACIÓN Con el fin de que este texto sea lo más conciso posible, se han omitido la mayoría de las advertencias y los problemas más frecuentes de las instrucciones de instalación. No obstante, podrá encontrar esta información en el apartado de preguntas más frecuentes (FAQ). Por lo tanto, se recomienda leer el archivo README entero antes de llevar a cabo los pasos que se describen. __________________________________________________________________________ (cap-01) CÓMO ELEGIR LOS PAQUETES DE NVIDIA ADECUADOS PARA CADA SISTEMA __________________________________________________________________________ NVIDIA dispone de un modelo de arquitectura de controladores unificada, lo que significa que un mismo juego de controladores se puede utilizar con todos los chips de gráficos de NVIDIA. En el Apéndice A encontrará una lista en la que figuran los chips de NVIDIA compatibles con los controladores actuales. La versión 1.0-4349 del controlador introdujo un nuevo mecanismo de empaquetamiento e instalación que simplifica extraordinariamente el proceso de instalación. Sólo hay que descargar un archivo, NVIDIA-Linux-x86-1.0-6111-pkg1.run, que contiene todo lo que contenían los antiguos paquetes NVIDIA_kernel y NVIDIA_GLX. La versión 1.0-6111 añade un sufijo de paquete ("-pkgnº") al archivo .run. Este sufijo se utiliza para diferenciar los paquetes que contienen el mismo controlador, pero diferentes interfaces del kernel precompiladas. En caso de confusión, basta descargar el archivo .run con el número de pkg más alto. __________________________________________________________________________ (cap-02) INSTALACIÓN DEL CONTROLADOR DE NVIDIA __________________________________________________________________________ ANTES DE EMPEZAR LA INSTALACIÓN DEL CONTROLADOR Antes de empezar la instalación, es necesario salir de X server. Además, es preciso configurar el nivel de ejecución predeterminado para poder arrancar una consola vga y no arrancar directamente en X (si no está seguro de cómo realizar esta operación, consulte la documentación que se adjunta con su distribución de Linux. Normalmente se realiza modificando el archivo /etc/inittab). De este modo, será más fácil solucionar los problemas que se puedan producir durante la instalación. Después de instalar el controlador, es preciso modificar el archivo de configuración de X para poder utilizarlo. Consulte la sección titulada MODIFICACIÓN DEL ARCHIVO DE CONFIGURACIÓN DE X. INTRODUCCIÓN AL NUEVO INSTALADOR DE CONTROLADORES DE NVIDIA Después de descargar el archivo NVIDIA-Linux-x86-1.0-6111-pkg1.run, comience la instalación saliendo de X server. Cambie al directorio que contiene el archivo descargado y ejecute: sh NVIDIA-Linux-x86-1.0-6111-pkg1.run El archivo .run se descomprime automáticamente. Nada más ejecutarlo extrae su contenido y ejecuta la utilidad `nvidia-installer`, que le va guiando a lo largo del proceso de instalación del controlador NVIDIA. El archivo .run acepta diversas opciones desde la línea de comandos. He aquí algunas de las más comunes: --info Presenta en pantalla información sobre el archivo .run y se cierra. --check Verifica la integridad del archivo y se cierra. --extract-only Extrae el contenido de ./NVIDIA-Linux-x86-1.0-6111.run, pero no ejecuta 'nvidia-installer'. --help Presenta información de uso de las opciones más comunes de la línea de comandos y se cierra. --advanced-options Presenta información de uso de las opciones comunes y avanzadas de la línea de comandos y se cierra. El procedimiento instala también la utilidad `nvidia-installer`, que puede utilizarse más adelante para desinstalar controladores, descargar automáticamente controladores actualizados, etc. INTERFACES DEL KERNEL El módulo kernel de NVIDIA tiene una interfaz que debe compilarse específicamente para la configuración y la versión del kernel que se esté ejecutando. NVIDIA proporciona el código fuente de esta interfaz, así como una versión precompilada para muchos de los kernels suministrados por algunas de las distribuciones más conocidas. Cuando se ejecuta el instalador, determina si dispone de una interfaz precompilada del kernel que se esté ejecutando. Si no la tiene, comprueba si existe alguna en el sitio FTP de NVIDIA (suponiendo que esté conectado a Internet) y la descarga. Si encuentra una interfaz precompilada que coincida con el kernel en uso, ésta se vinculará[1] con la parte binaria del módulo kernel de NVIDIA. Como resultado dispondrá de un módulo apropiado para la versión del kernel que esté utilizando. Si no localiza una interfaz adecuada, el propio programa de instalación se encarga de compilar la interfaz del kernel, pero primero comprueba si el sistema tiene instalados los encabezados (headers) correctos. Si el instalador tiene que compilar la interfaz del kernel, es preciso instalar el paquete de archivos fuente del kernel correspondiente. [1] NOTA: la instalación necesita que haya un generador de enlaces (linker) instalado. Este programa, normalmente '/usr/bin/ld', forma parte del paquete binutils. Asegúrese de tener este paquete instalado antes de instalar el controlador NVIDIA. FUNCIONES DE NVIDIA-INSTALLER o Desinstalación: durante la instalación del controlador se hace una copia de seguridad de cualquier archivo que resulte afectado y registra los nuevos archivos que se instalan en el sistema. Puede ejecutar: nvidia-installer --uninstall para desinstalar el controlador actual y, con ello, eliminar todos los archivos que se instalasen en el sistema y restaurar los archivos de la copia de seguridad. La instalación de nuevos controladores implica la desinstalación automática de otros controladores anteriores. o Actualización automática: si ejecuta: nvidia-installer --latest la utilidad se conecta al sitio FTP de NVIDIA e identifica la última versión del controlador, así como la dirección en la que puede descargarse el archivo correspondiente. Si ejecuta: nvidia-installer --update la utilidad se conecta al servidor FTP de NVIDIA, descarga la última versión del controlador y lo instala. o Varias interfaces de usuario: el instalador emplea una interfaz ncurses si puede encontrar la librería ncurses adecuada, de lo contrario recurre a la interfaz de la línea de comandos. Para desactivar el uso de la interfaz ncurses, utilice la opción '--ui=none'. o Interfaces del kernel actualizadas: el instalador puede descargar interfaces precompiladas del kernel desde el servidor FTP de NVIDIA (para kernels publicados después de la versión del controlador). PREGUNTAS MÁS FRECUENTES SOBRE NVIDIA-INSTALLER P: ¿Cómo descomprimo el contenido del archivo .run sin instalar el controlador? R: Ejecute: sh NVIDIA-Linux-x86-1.0-6111-pkg1.run --extract-only Con esto se crea el directorio NVIDIA-Linux-x86-1.0-6111-pkg1, donde se guarda el contenido descomprimido del archivo .run. P: ¿Cómo puedo ver el código fuente de la interfaz del kernel? R: Los archivos fuentes de esta interfaz se encuentran en el directorio usr/src/nv del archivo .run descomprimido. Para obtenerlos, ejecute: sh NVIDIA-Linux-x86-1.0-6111-pkg1.run --extract-only cd NVIDIA-Linux-x86-1.0-6111-pkg1/usr/src/nv/ P: Acabo de actualizar el kernel y ahora el módulo kernel de NVIDIA no se carga. ¿Cuál es el problema? R: La interfaz del módulo kernel de NVIDIA tiene que estar específicamente compilada para la configuración y versión del kernel que se esté utilizando. Si actualiza el kernel, la solución más fácil es volver a instalar el controlador. SOLUCIÓN MÁS COMPLEJA: puede instalar el módulo kernel de NVIDIA para un kernel que no se está ejecutando (por ejemplo, si acaba de compilar e instalar un nuevo kernel, pero no lo ha arrancada aún) con un comando como éste: sh NVIDIA-Linux-x86-1.0-6111-pkg1.run --kernel-name='NOMBRE_KERNEL' Donde 'NOMBRE_KERNEL' es lo que el comando `uname -r` indicaría si el kernel de destino se estuviese ejecutando. P: ¿Por qué NVIDIA ha dejado de suministrar archivos rpm? R: No todas las distribuciones de Linux utilizan rpm y NVIDIA quería una solución que funcionase con todas las distribuciones. Como se indica en la licencia de software de NVIDIA, invitamos a todas las distribuciones Linux a empaquetar y redistribuir el controlador Linux de NVIDIA con el formato que prefieran. P: nvidia-installer no funciona en mi sistema. ¿Cómo puedo instalar el controlador incluido en el archivo .run? R: Para instalar el controlador sin utilizar nvidia-installer, puede utilizar el archivo Makefile que se incluye en el archivo .run: sh ./NVIDIA-Linux-x86-1.0-6111-pkg1.run --extract-only cd NVIDIA-Linux-x86-1.0-6111-pkg1 make install Este método de instalación no está recomendado y sólo se sugiere como último recurso en caso de que nvidia-installer no funcione correctamente en el sistema. P: ¿nvidia-installer puede utilizar un servidor proxy? R: Sí, el soporte de FTP en nvidia-installer se basa en snarf y, por tanto, admite las variables de entorno FTP_PROXY, SNARF_PROXY y PROXY. P: ¿Qué significa el sufijo "pkgnº" en el archivo .run? R: El sufijo "pkgnº" se utiliza para diferenciar los archivos .run que contienen el mismo controlador pero diferentes juegos de interfaces de kernel precompiladas. Si se publica un nuevo kernel de una determinada distribución después de que se haya publicado el controlador NVIDIA, el controlador existente puede reempaquetarse para incorporar la interfaz precompilada de ese nuevo kernel (además de todas las interfaces que se incluían en el paquete anterior del controlador). Los archivos .run con el mismo número de versión pero distinto número de pkg sólo difieren en las interfaces del kernel precompiladas que contienen. Por lo demás, los archivos .run con el número más alto de pkg más alto contienen todo lo que incluían los archivos .run con menor número de .pkg. P: Ya he instalado el archivo NVIDIA-Linux-x86-1.0-6111-pkg1.run, pero veo que acaba de añadirse el archivo NVIDIA-Linux-x86-1.0-6111-pkg2.run a la página de descarga de controladores Linux de NVIDIA. ¿Tengo que descargar e instalar NVIDIA-Linux-x86-1.0-6111-pkg2.run? R: No es necesario. Los controladores incluidos en todos los archivos .run de la versión 1.0-6111 son idénticos. No necesita volverlo a instalar. P: ¿Pueño añadir mis propias interfaces precompiladas del kernel a un archivo .run? R: Sí, la opción "--add-this-kernel" del archivo .run descomprime el archivo .run, genera una interfaz precompilada del kernel que se esté ejecutando y vuelve a empaquetar el archivo .run añadiendo la terminación "-custom" al nombre del archivo. Esto puede ser útil, por ejemplo, cuando se administran varias máquinas Linux que ejecutan el mismo kernel. P: ¿Dónde puedo encontrar el código fuente de nvidia-installer? R: La utilidad nvidia-installer se publica en GPL. La última versión de su código fuente está disponible en: ftp://download.nvidia.com/XFree86/nvidia-installer/ RECONOCIMIENTOS La utilidad nvidia-installer está inspirada en la herramienta loki_update: (http://www.lokigames.com/development/loki_update.php3). El soporte de ftp y http de nvidia-installer se basa en snarf 7.0: (http://www.xach.com/snarf/). El archivo de descompresión automática ("archivo .run") se genera mediante makeself.sh: (http://www.megastep.org/makeself/) __________________________________________________________________________ (cap-03) MODIFICACIÓN DEL ARCHIVO DE CONFIGURACIÓN DE X __________________________________________________________________________ En abril de 2004 la X.org Foundation publicó una versión de X server basada en el servidor XFree86 y, en el futuro, muchas distribuciones de Linux utilizarán el servidor de la X.org en lugar de la versión XFree86. La diferencia entre ambos servidores X no debería afectar a los usuarios de NVIDIA Linux salvo en dos aspectos: 1) Aunque el archivo de configuración de X.org utiliza la misma sintaxis que el archivo XF86Config de XFree86, su nombre es /etc/X11/xorg.conf. Para evitar confusiones, este archivo README se referirá a estos archivos de configuración con el nombre genérico de "archivo de configuración de X". 2) Aunque la salida del archivo de registro (log) de X.org es prácticamente idéntica a la del archivo XFree86.0.log, su nombre es /var/log/Xorg.0.log. En este README nos referiremos a estos archivos con el nombre genérico de "archivo de registro de X". Cuando XFree86 4.0 salió al mercado, la sintaxis del archivo XF86Config era ligeramente diferente a la de la serie 3.x. Para que las versiones 3.x y 4.x de XFree86 pudieran coexistir en el mismo sistema, se tomó la decisión de que XFree86 4.x utilizara el archivo de configuración "/etc/X11/XF86Config-4", si éste existía, y que únicamente utilizaría el archivo "/etc/X11/XF86Config" en caso de que el anterior no existiera (en realidad, se trata de una simplificación del criterio de búsqueda; consulte el manual de ayuda en línea de XF86Config para obtener una descripción completa de la ruta de búsqueda). Compruebe qué archivo de configuración está utilizando x server. En caso de duda, busque una línea que empieza por "(==) Using config file:" en el archivo de registro de X ("/var/log/XFree86.0.log" o "/var/log/Xorg.0.log"). Si no dispone de un archivo de configuración de X ya en uso, existen varias formas de empezar: XFree86 incorpora un archivo de configuración de muestra, al igual que el paquete del controlador NVIDIA (en /usr/share/doc/NVIDIA_GLX-1.0/). Asimismo, puede utilizar un programa como 'xf86config'; algunas distribuciones disponen de una herramienta propia para generar el archivo de configuración de X. Si desea más información acerca de la sintaxis de este archivo, consulte el manual de ayuda en línea (`man XF86Config` o `man xorg.conf`). Si ya dispone de un archivo de configuración de X funcionando con otro controlador (como el controlador 'nv' o 'vesa'), tan sólo tendrá que encontrar la sección del dispositivo apropiada y reemplazar la línea: Driver "nv" (o Driver "vesa") por Driver "nvidia" En la sección del módulo, asegúrese de que figura: Load "glx" Además, deberá eliminar las siguientes líneas: Load "dri" Load "GLcore" si existen. Además hay numerosas opciones que se pueden añadir al archivo de configuración para ajustar con precisión el controlador de NVIDIA para X. En el Apéndice D encontrará una lista con todas estas opciones. Una vez configurado este archivo, puede reiniciar en X y empezar a utilizar las librerías OpenGL aceleradas. Después de reiniciar en X, debería poder ejecutar cualquier aplicación OpenGL, que automáticamente utilizará las nuevas librerías NVIDIA. Si surge algún problema, consulte el capítulo siguiente: "PREGUNTAS MÁS FRECUENTES". __________________________________________________________________________ (cap-04) PREGUNTAS MÁS FRECUENTES (FAQ) __________________________________________________________________________ P: ¿Qué debo hacer para diagnosticar problemas de visualización en pantalla? R: Una de las herramientas más útiles para diagnosticar los problemas es el archivo de registro de X en /var/log (el nombre del archivo es "/var/log/XFree86.<#>.log" o "/var/log/Xorg.<#>.log", donde "<#>" es el número del servidor -- por lo general 0). Las líneas que empiezan por "(II)" son información, mientras que las que empiezan por "(WW)" son advertencias y las que empiezan por "(EE)" son errores. Asegúrese de que el archivo de configuración (el archivo de configuración que está editando) es el correcto; busque la línea que comienza por: "(==) Using config file:". Compruebe también que está utilizando el controlador NVIDIA, y no el controlador 'nv' o 'vesa'; para ello, busque: "(II) LoadModule: "nvidia"". Las líneas del controlador deben empezar por: "(II) NVIDIA(0)". P: ¿Cómo puedo incrementar la cantidad de datos que se muestran en el archivo de registro de X? R: En principio, el controlador X de NVIDIA escribe relativamente pocos mensajes en stderr y el archivo de registro de X. Si necesita resolver algún problema, le será de gran ayuda activar la salida en modo explícito utilizando las opciones de línea de comando de X "-verbose" y "-logverbose", que se pueden utilizar para establecer el nivel de detalle de los mensajes de error de stderr y del archivo de registro respectivamente. El controlador X de NVIDIA escribirá más mensajes de error cuando el nivel de detalle sea igual o superior a 5 (el nivel de detalle predeterminado en X es 1 para stderr y 3 para el archivo de registro). Por tanto, para activar el modo de detalle de los mensajes que el controlador X de NVIDIA escribe en el archivo de registro y en stderr, inicie la sesión X introduciendo el siguiente comando: 'startx -- -verbose 5 -logverbose 5'. P: X server no puede iniciarse y el archivo de registro de X contiene el error: "(EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module!" R: Si el módulo kernel de NVIDIA no funciona adecuadamente, el resto de los elementos tampoco lo harán. Si en el archivo de registro de X aparece un mensaje del estilo "(EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module!" ((EE) NVIVIA (0): No se puede inicializar el módulo kernel de NVIDIA), es posible que haya algún problema relacionado con ese módulo. En primer lugar, si ha realizado la instalación mediante rpm, verifique que el archivo rpm era el específico del kernel que está utilizando. Compruebe también que el módulo está cargado ('/sbin/lsmod'); en caso negativo, intente cargarlo explícitamente con 'insmod' o 'modprobe' (no olvide salir de X server antes de instalar un nuevo módulo kernel). Si recibe errores relacionados con símbolos no resueltos, es probable que el módulo kernel se haya creado utilizando archivos de encabezado para una versión de kernel distinta de la que está utilizando. Puede controlar explícitamente qué archivos de encabezado se utilizarán al compilar el módulo kernel de NVIDIA mediante la opción --kernel-include-dir (consulte `sh NVIDIA-Linux-x86-1.0-6111-pkg1.run --advanced-options` para obtener más información). Tenga en cuenta que la convención sobre la ubicación de los archivos de encabezado del kernel se modificó coincidiendo aproximadamente con la versión 2.4.0 del kernel, al igual que la ubicación de los módulos kernel. Si el módulo kernel no se carga correctamente, es probable que modprobe/insmod estén tratando de cargar un módulo anterior (suponiendo que haya realizado una actualización). En estos casos, puede ser de ayuda cambiar al directorio que contiene el nuevo módulo kernel y ejecutar 'insmod .nvidia.o'. Otra posible causa es que falten los archivos de dispositivo /dev/nvidia*. Por último, el módulo kernel de NVIDIA puede mostrar mensajes de error relativos a algún problema; para visualizar estos mensajes compruebe el archivo /var/log/messages, o el archivo en el que syslog deba escribir los mensajes relativos al kernel. Estos mensajes se añaden al principio con "NVRM". P: X se inicia, pero las aplicaciones OpenGL se cierran inmediatamente. R: Si consigue iniciar X, pero OpenGL causa problemas, lo más probable es que el problema resida en otras librerías o que haya enlaces simbólicos obsoletos. Si desea más información, consulte el Apéndice C. A veces, lo único que hay que hacer es volver a ejecutar 'ldconfig'. También debería comprobar que las extensiones son las correctas; 'xdpyinfo' debería tener las extensiones "GLX", "NV-GLX" y "NVIDIA-GLX". Si no es así, lo más probable es que el módulo glx esté teniendo problemas para cargarse o que no se pueda cargar implícitamente GLcore. Compruebe el archivo de configuración de X y asegúrese de que está cargando glx (consulte el capítulo "Edición del archivo de configuración de X"). Si el archivo de configuración es el correcto, compruebe si el archivo de registro de X contiene advertencias o errores relativos a GLX. Verifique también que todos los enlaces simbólicos necesarios están en el lugar correspondiente (consulte el Apéndice C). P: Durante la instalación del módulo kernel de NVIDIA se genera un mensaje de error del tipo: #error Modules should never use kernel-headers system headers #error but headers from an appropriate kernel-source R: Tiene que instalar el código fuente del kernel Linux. En la mayoría de los casos, se puede resolver este problema instalando el paquete kernel-source que corresponda a su distribución. P: Las aplicaciones OpenGL se cierran con el siguiente mensaje de error: Error: Could not open /dev/nvidiactl because the permissions are too restrictive. Please see the FREQUENTLY ASKED QUESTIONS section of /usr/share/doc/NVIDIA_GLX-1.0/README for steps to correct. (Error: No se pudo abrir /dev/nvidiactl porque los permisos son demasiado restrictivos. Consulte el capítulo PREGUNTAS MÁS FRECUENTES en /usr/share/doc/NVIDIA_GLX-1.0/README para corregir el problema.) R: Es posible que un módulo de seguridad del sistema PAM esté cambiando los permisos en los archivos de dispositivo NVIDIA. Normalmente este sistema de seguridad funciona bien, pero a veces puede fallar. Para corregir este problema, es recomendable desactivar este sistema de seguridad. Cada distribución de Linux dispone de diferentes archivos para controlar esta cuestión; pregunte a su distribuidor la forma de desactivar esta función de seguridad. Por ejemplo, si su sistema cuenta con el archivo /etc/security/console.perms, tendrá que editar el archivo y eliminar la línea que empieza por "" (hemos recibido comunicaciones donde se indica que es preciso eliminar cualquier otra referencia a en console.perms, pero no ha sido verificado por NVIDIA). Si, por el contrario, su sistema tiene el archivo /etc/logindevperms, tendrá que abrir el archivo y eliminar la línea /dev/nvidiactl. Estos pasos evitarán que el sistema de seguridad PAM modifique los permisos en los archivos de dispositivo Nvidia. A continuación tendrá que restablecer los permisos en los archivos de dispositivo para que coincidan con sus permisos y propietario originales. Para ello, utilice los siguientes comandos: chmod 0666 /dev/nvidia* chown root /dev/nvidia* P: Las aplicaciones OpenGL fallan y aparece la siguiente advertencia: WARNING: Your system is running with a buggy dynamic loader. This may cause crashes in certain applications. If you experience crashes you can try setting the environment variable __GL_SINGLE_THREADED to 1. For more information please consult the FREQUENTLY ASKED QUESTIONS section in the file /usr/share/doc/NVIDIA_GLX-1.0/README. (ADVERTENCIA: Su sistema se está ejecutando con un cargador dinámico inestable. Esto puede hacer que fallen algunas aplicaciones. Si se producen fallos, pruebe a definir 1 en la variable de entorno __GL_SINGLE_THREADED. Para más información, consulte la sección PREGUNTAS MÁS FRECUENTES en el archivo /usr/share/doc/NVIDIA_GLX-1.0/README) R: Significa que el cargador dinámico de su sistema tiene un error que hará que las aplicaciones enlazadas con pthreads, y que ejecutan varias veces la función dlopen() libGL, fallen. Este error está presente en versiones anteriores del cargador dinámico. Entre las distribuciones que incluyen este cargador se encuentran RedHat Linux 6.2 y Mandrake Linux 7.1, aunque hay más. La versión 2.2 (y posteriores) del cargador funcionan correctamente. Si la aplicación que falla es de tipo monohilo (single threaded), podrá solucionar el problema configurando la variable de entorno __GL_SINGLE_THREADED con el valor 1. En el bash shell escriba: export __GL_SINGLE_THREADED=1 y en csh y sus derivados utilice: setenv __GL_SINGLE_THREADED 1 En las versiones anteriores del juego de controladores acelerados para Linux de NVIDIA se intentó resolver este problema, pero la solución hallada causaba problemas con otras aplicaciones, por lo que se eliminó después de la versión 1.0-1541. P: Cuando ejecuto Quake3, falla al cambiar los modos de vídeo. ¿Cuál es el problema? R: Es posible que se esté produciendo el problema descrito anteriormente. Consulte las indicaciones correspondientes al mensaje de "ADVERTENCIA" del apartado anterior. Como se explica en el caso anterior, el problema se resuelve configurando la variable de entorno __GL_SINGLE_THREADED con el valor 1 antes de ejecutar Quake3. P: El sistema funciona pero parece inestable. ¿Cuál es el problema? R: Puede que el problema esté relacionado con AGP. Consulte el Apéndice E para obtener más información. P: El módulo kernel no se carga dinámicamente cuando se inicia X; es necesario ejecutar antes 'modprobe nvidia'. ¿Cuál es el problema? R: Asegúrese de que aparece la línea "alias char-major-195 nvidia" en su archivo de configuración del módulo, que por lo general suele ser uno de estos:"/etc/conf.modules", "/etc/modules.conf" o "/etc/modutils/alias"; si desea más información, consulte la documentación adjunta a su distribución. P: No puedo crear el módulo kernel de NVIDIA, o puedo crearlo pero modprobe/insmod no puede cargarlo en el kernel. ¿Cuál es el problema? R: Por lo general, este tipo de problemas se deben a que se utilizan archivos de encabezado del kernel incorrectos (por ejemplo, archivos de encabezado para una versión del kernel diferente de la que se está ejecutando). Los archivos de encabezado del kernel se solían almacenar en "/usr/include/linux/", pero esta ubicación se ha dejando de utilizar para sustituirla por "/lib/modules/`uname -r`/build/include". La utilidad nvidia-installer debería poder determinar la ubicación en su sistema. No obstante, si surge algún problema puede hacer que el compilador utilice determinados archivos de encabezado utilizando la opción --kernel-include-dir. Evidentemente, para que esto funcione, es necesario tener instalados en el sistema los archivos de encabezado adecuados del kernel. Consulte la documentación que le entregaron con su distribución de Linux; algunas distribuciones no instalan de forma predeterminada los archivos de encabezado de kernel, o instalan encabezados que no coinciden con el kernel que se está utilizando. P: ¿Por qué son tan lentas las aplicaciones OpenGL? R: Probablemente la aplicación todavía utiliza una librería diferente de su sistema, en vez de la librería OpenGL proporcionada por NVIDIA. Si desea más detalles consulte el APÉNDICE C. P: Tengo problemas para ejecutar Quake2. R: Quake2 requiere una pequeña labor de configuración para poder ejecutarse. En primer lugar, la instalación crea en el directorio Quake2 un enlace simbólico llamado libGL.so que apunta a libMesaGL.so. Este enlace simbólico se debe eliminar o renombrar. A continuación, para ejecutar Quake2 en modo OpenGL, escriba: 'quake2 +set vid_ref glx +set gl_driver libGL.so'. Aunque, en principio, Quake2 no admite ningún tipo de modo de pantalla completa, puede ejecutar X server a la misma resolución a la que se esté ejecutando Quake2 para emular el modo de pantalla completa. P: Tengo problemas para ejecutar Heretic II. R: Heretic II también instala de forma predeterminada un enlace simbólico llamado libGL.so en el directorio de la aplicación. Puede eliminar o renombrar este enlace simbólico, ya que el sistema encontrará el libGL.so predeterminado(que nuestros controladores instalan en /usr/lib). Desde Heretic II se puede configurar el modo de renderizado para OpenGL en el menú de vídeo. Lokigames ofrece además un parche para Heretic II en la dirección: http://www.lokigames.com/products/heretic2/updates.php3 P: ¿Dónde puedo conseguir los encabezados gl.h o glx.h para poder compilar los programas OpenGL? R: La mayoría de los sistemas llevan estos encabezados preinstalados. No obstante, NVIDIA proporciona sus propios archivos gl.h y glx.h, que se instalan en /usr/share/doc/NVIDIA_GLX-1.0/include/GL/. Para usar estos archivos, cópielos manualmente en /usr/include/GL/ o indique al programa de instalación que los copie en /usr/include/GL/ pasando la opción '--opengl-headers' al archivo NVIDIA-Linux-x86-1.0-6111-pkg1.run durante la instalación. P: ¿Puedo recibir por correo electrónico información sobre las nuevas versiones del juego de controladores para Linux de NVIDIA? R: Por supuesto. Sólo tiene que rellenar el formulario de la página web: http://www.nvidia.com/view.asp?FO=driver_update P: Mi sistema se bloquea al cambiar de terminal virtual si está activado el módulo rivafb. R: No se pueden utilizar al mismo tiempo el módulo rivafb y el módulo kernel de NVIDIA. En general, no es muy buena idea utilizar dos controladores de software diferentes para un mismo elemento de hardware. P: Al compilar el módulo kernel de NVIDIA aparece el siguiente error: You appear to be compiling the NVIDIA kernel module with a compiler different from the one that was used to compile the running kernel. This may be perfectly fine, but there are cases where this can lead to unexpected behaviour and system crashes. If you know what you are doing and want to override this check, you can do so by setting IGNORE_CC_MISMATCH. In any other case, set the CC environment variable to the name of the compiler that was used to compile the kernel. (Parece que está compilando el módulo kernel de NVIDIA con un compilador diferente del que utilizó para compilar el kernel activo. En principio no tiene por qué haber ningún problema, pero a veces puede ocasionar un comportamiento inesperado y el fallo del sistema. Si sabe lo que está haciendo y quiere omitir esta comprobación, puede hacerlo ejecutando el comando IGNORE_CC_MISMATCH. En caso contrario, configure la variable de entorno cc con el nombre del compilador que utilizó para compilar el kernel.) R: Debe compilar el módulo kernel de NVIDIA con la misma versión de compilador que utilizó para compilar su kernel. Algunas estructuras de datos de kernel de Linux dependen de la versión de gcc utilizada para compilarlas, por ejemplo en include/linux/spinlock.h: ... * Most gcc versions have a nasty bug with empty initializers. */ #if (__GNUC__ > 2) typedef struct { } rwlock_t; #define RW_LOCK_UNLOCKED (rwlock_t) { } #else typedef struct { int gcc_is_buggy; } rwlock_t; #define RW_LOCK_UNLOCKED (rwlock_t) { 0 } #endif Si el kernel se compila con gcc 2.x, pero se utiliza gcc 3.x para compilar la interfaz del kernel de NVIDIA (o viceversa), se modificará el tamaño de rwlock_t y se producirán fallos, por ejemplo, en ioremap. Para averiguar qué versión de gcc utilizó para compilar el kernel, examine la salida de: cat /proc/version Para averiguar qué versión de gcc figura actualmente en su $PATH, examine la salida de: gcc -v P: X falla debido al error "Failed to allocate LUT context DMA" (No se pudo asignar LUT context DMA) R: Esta es una de las posibles consecuencias de compilar la interfaz del kernel de NVIDIA con una versión de gcc diferente de la que se utilizó para compilar el kernel de Linux (véase más arriba). P: ¿Cuál es la política de NVIDIA en relación con las series de kernels de desarrollo Linux? R: NVIDIA no soporta oficialmente las series de kernels de desarrollo. No obstante, todo el código fuente de los módulos kernel que interactúa con el kernel de Linux está disponible en el directorio usr/src/nv/ del archivo .run. NVIDIA anima a los miembros de la comunidad Linux a desarrollar parches para estos archivos fuente para el soporte de las series de desarrollo. Probablemente una búsqueda en google proporcionará varios parches de soporte. P: Recientemente actualicé varias librerías en el sistema con la utilidad de actualización de mi distribuidor de Linux y el controlador de gráficos NVIDIA ya no funciona. ¿Cuál es el problema? R: El posible que la utilidad de actualización haya instalado librerías que entran en conflicto con el controlador. Consulte el APÉNDICE C: COMPONENTES INSTALADOS, para comprobar esta posibilidad. P: `rpm --rebuild` devuelve el error "unknown option" (opción desconocida). R: Las últimas versiones de rpm ya no admiten la opción "--rebuild". Si tiene una de estas versiones, deberá utilizar en su lugar el comando `rpmbuild --rebuild`. El archivo `rpmbuild` ejecutable se incluye en el paquete rpm-build. P: Estoy utilizando gráficos internos nForce o nForce2 y veo mensajes como éste en el archivo de registro de X: Not using mode "1600x1200" (exceeds valid memory bandwidth usage) (No se está utilizando el modo "1600x1200" - supera el uso de ancho de banda de memoria válido) R: Los gráficos integrados tienen limitaciones de uso del ancho de banda que restringen en mayor medida la resolución y la tasa de refresco de los modos solicitados. Para evitar este problema, puede reducir la tasa de refresco máxima disminuyendo el valor superior de "VertRefresh" en la sección Monitor del archivo de configuración de X. Aunque no lo recomendamos, también puede desactivar la prueba de ancho de banda de memoria con la opción "NoBandWidthTest" del archivo de configuración. P: He compilado el módulo kernel de NVIDIA pero, cuando intento insertarlo, recibo un mensaje que indica que hay símbolos sin resolver. R. Los símbolos sin resolver suelen deberse a una discrepancia entre los archivos fuente del kernel y el kernel ejecutado. Estos archivos tienen que coincidir para que el módulo kernel de NVIDIA se compile correctamente. Compruebe si los archivos fuente del kernel son los adecuados para el kernel que se está ejecutando. P: ¿Cómo puedo saber si tengo instalados los archivos fuente del kernel? R: Si ejecuta una distribución que utiliza paquetes RPM (Red Hat, Mandrake, SuSE, etc), puede usar RPM para saberlo. Escriba lo siguiente en el indicador del shell: `rpm -qa | grep kernel` Observe el resultado. Debería ver un paquete que corresponde a su kernel (normalmente con un nombre similar a kernel-2.4.18-3) y un paquete fuente del kernel con la misma versión (normalmente con un nombre similar a kernel-source-2.4.18-3). Si ninguna de las líneas parece corresponder a un paquete fuente, seguramente necesita instalarlo. Si las versiones que aparecen en pantalla no coinciden (p. ej.: kernel-2.4.18-10 y kernel-source-2.4.18-3), necesitará actualizar el paquete kernel-source para que coincida con la versión instalada del kernel. Si tiene varios kernels instalados, tendrá que instalar el paquete kernel-source adecuado para el kernel que se esté ejecutando (o asegurarse de que los archivos fuente instalados se corresponden con el kernel en ejecución). Puede hacerlo examinando la salida del comando 'uname -r'. P: ¿Por qué no puedo cargar el módulo kernel de NVIDIA que compilé para el kernel Red Hat Linux 7.3 2.4.18-3bigmem? R: Los archivos de encabezado que Red Hat Linux distribuye para la versión Red Hat Linux 7.3 2.4.18-3bigmem están mal configurados. Es posible cargar el módulo precompilado de NVIDIA para este kernel, pero, para compilar los archivos de interfaz correspondientes, es preciso hacer lo siguiente: cd /lib/modules/`uname -r`/build/ make mrproper cp configs/kernel-2.4.18-i686-bigmem.config .config make oldconfig dep Nota: Red Hat Linux distribuye archivos de encabezado que se configuran simultáneamente para TODOS los kernels de una determinada versión de distribución. Un archivo de encabezado generado al arrancar el sistema establece unos cuantos parámetros que seleccionan la configuración correcta. Al recompilar los archivos de encabezado del kernel con los comandos anteriores se crearán las versiones adecuadas de estos archivos para la configuración Red Hat Linux 7.3 2.4.18-3bigmem exclusivamente, con lo que quedan inservibles para otras configuraciones. P: X tarda mucho en iniciarse (incluso varios minutos). ¿Qué puedo hacer? R: Hemos descubierto que la mayoría de los problemas de demora de startx están causados por datos incorrectos de la BIOS relacionados con los posibles dispositivos de visualización conectados o el puerto i2c que debería utilizarse para la detección. Puede resolver estos problemas con la opción "IgnoreDisplayDevices" del archivo de configuración de X (consulte la descripción en el APÉNDICE D: OPCIONES DEL ARCHIVO DE CONFIGURACIÓN DE X). P: ¿Por qué X utiliza tanta memoria? R: Al medir el uso de memoria de cualquier aplicación, es conveniente distinguir entre la memoria RAM (física) del sistema y las asignaciones virtuales de los recursos compartidos. Por ejemplo, la mayor parte de las librerías compartidas existen una vez en la memoria física, pero se asignan a varios procesos. Esta memoria sólo debería contabilizarse una vez cuando se calcula el uso total de memoria. Del mismo modo, la memoria de vídeo de una tarjeta gráfica o la memoria de registro (registry) de cualquier dispositivo puede asignarse a varios procesos. Estas asignaciones no consumen memoria RAM del sistema. Se trata de un tema ampliamente tratado en las listas de distribución de correo relativas a XFree86. Consulte, por ejemplo: http://marc.theaimsgroup.com/?l=xfree-xpert&m=96835767116567&w=2 La utilidad `pmap` descrita en el comentario anterior y disponible en: http://web.hexapodia.org/~adi/pmap.c sirve para distinguir los distintos tipos de mapas de memoria. Por ejemplo, aunque `top` puede indicar que X está utilizando varios cientos de MB de memoria, la última línea de pmap: mapped: 287020 KB writable/private: 9932 KB shared: 264656 KB revela que, en realidad, X está utilizando sólo unos 10 MB de RAM del sistema (el valor "writable/private"). Observe también que X debe asignar recursos en nombre de los clientes X (el administrador de ventanas, el navegador, etc.). El uso de memoria de X aumentará a medida que los clientes soliciten recursos tales como mapas de píxeles y disminuirá conforme se vayan cerrando aplicaciones X. P: ¡Las aplicaciones OpenGL provocan importantes pérdidas de memoria en el sistema! R: Si su kernel utiliza -rmap VM, el sistema puede estar sufriendo pérdidas de memoria a causa de una optimización de la gestión de memoria introducida en -rmap14a. -rmap VM ha sido adoptada por varias distribuciones conocidas y se sabe que la pérdida de memoria está presente en algunos de los kernels de esas distribuciones. Se ha corregido en -rmap15e. Si sospecha que su sistema está afectado por este problema, pruebe a actualizar el kernel o póngase en contacto con el proveedor de la distribución para obtener ayuda. P: Algunas aplicaciones OpenGL (como Quake3 Arena) se cierran cuando las abro en Red Hat Linux 9.0. R: Algunas versiones del paquete glibc de Red Hat que soportan TLS no manejan adecuadamente dlopen() para acceder a las librerías compartidas que utilizan algunos modelos de TLS. Este problema se produce, por ejemplo, cuando la función dlopen() de Quake3 Area trata de abrir la librería libGL de NVIDIA. Trate de obtener al menos la versión glibc-2.3.2-11.9, que está disponible como actualización de Red Hat. P: He instalado el controlador, pero la casilla Enable 3D Acceleration sigue sin poderse activar. ¿Cuál es el problema? R: La mayoría de los applets de configuración proporcionados por las distribuciones no detectan automáticamente el controlador acelerado de NVIDIA y, por tanto, no se actualizan cuando se instala ese controlador. Si lo ha instalado correctamente, el controlador debería funcionar sin problemas. P: ¿Dónde puedo encontrar los archivos tar? R: Ya no existen archivos tar como tales. El archivo .run es un archivo tar precedido por un script de shell. Puede ejecutar el archivo .run con la opción '--extract-only' para descomprimir el archivo tar. P: ¿Dónde puedo encontrar versiones anteriores del controlador? R: Visite ftp://download.nvidia.com/XFree86_40/. P: X no restaura la consola vga cuando se ejecuta con un televisor. Aparece este mensaje de error en el archivo de registro de X: Unable to initialize the X int10 module; the console may not be restored correctly on your TV. R: El controlador X de NVIDIA utiliza el módulo Int10 de X para guardar y restaurar el estado de la consola cuando se envía la salida a TV, así que no puede restaurar el estado correctamente si no utiliza el módulo Int10. Si ha compilado usted mismo X server, cerciórese de que ha incluido el módulo Int10. Si está utilizando una compilación de X server suministrada en una distribución de Linux y falta el módulo Int10, póngase en contacto con el distribuidor. P: Al cambiar la configuración en juegos como Quake 3 Arena o Wolfstein Enemy Territory, el juego se bloquea y aparece este error: ...loading libGL.so.1: QGL_Init: dlopen libGL.so.1 failed: /usr/lib/tls/libGL.so.1: shared object cannot be dlopen()ed: static TLS memory too small R: Estos juegos cierran y vuelven a abrir el controlador NVIDIA OpenGL (mediante dlopen()/dlclose()) cuando se modifica la configuración. En algunas versiones de glibc (como la suministrada con Red Hat Linux 9), existe un error por el que se pierden entradas TLS estáticas. Este error de glibc hace que el controlador de OpenGL falle cuando se vuelve a cargar. El error ha sido corregido en versiones más recientes de glibc; consulte el error nº 89692 de Red Hat: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=89692 P: X se bloquea durante `startx` y el archivo de registro de X presenta este mensaje: (EE) NVIDIA(0): Failed to obtain a shared memory identifier. R: Los controladores NVIDIA para OpenGL y X necesitan utilizar memoria compartida para comunicarse. Es preciso tener activada la variable CONFIG_SYSVIPC en el kernel. P: Cuando trato de instalar el controlador, el programa de instalación indica que X se está ejecutando aunque ya he cerrado este entorno. ¿Cuál es el problema? R: El programa de instalación detecta la presencia de X server a causa de los archivos de bloqueo de X: /tmp/.X[n]-lock, donde [n] es el número de la pantalla X (el programa comprueba las pantallas 0-7 de X). Si ha salido del entorno X pero ha quedado abierto uno de estos archivos de bloqueo, necesitará borrarlo manualmente. NO BORRE este archivo si X se está ejecutando aún. P: Los tipos de letra muestran un tamaño incorrecto después de instalar el controlador de NVIDIA. R: El tamaño incorrecto de los tipos de letra generalmente se debe a que el monitor informa erróneamente sobre su tamaño físico y hace que las aplicaciones X presenten las letras de forma inadecuada. Puede comprobar qué tamaño físico de monitor detecta X ejecutando: xdpyinfo | grep dimensions El resultado del comando es el tamaño en píxeles y en milímetros. Si el dato en milímetros es drásticamente incorrecto, puede corregirlo agregando el campo DisplaySize a la sección monitor del archivo de configuración de X (consulte la ayuda del manual en línea sobre XF86Config o xorg.conf para obtener más información). Puede comprobar qué tamaño físico suministra el monitor ejecutando X en modo completo de registro completo: `startx -- -logverbose`. A continuación, busque en el archivo de registro de X una línea similar a la siguiente: (II) NVIDIA(0): Max H-Image Size [cm]: horiz.: 36 vert.: 27 (los números serán distintos). El controlador de NVIDIA utiliza estos valores para calcular los PPP. P: Quiero utilizar Valgrind con aplicaciones OpenGL pero mi distribución utiliza ELF TLS y Valgrind aún no puede manejar la librería ELF TLS OpenGL de NVIDIA. R: Puede definir la variable de entorno LD_ASSUME_KERNEL con un valor inferior a "2.3.99" (por ejemplo: `export LD_ASSUME_KERNEL 2.3.98`). Las librerías OpenGL de NVIDIA contienen una nota OS ABI ELF que indica la mínima versión del kernel necesaria para utilizar la librería. Las librerías ELF TLS OpenGL tienen la versión 2.3.99 de OS ABI (el primer kernel Linux que contenía el soporte de LDT necesario para ELF TLS), mientras que las librerías OpenGL normales contienen un valor OS ABI de 2.2.5. El cargador run-time no cargará las librerías que tengan un OS ABI superior al de la versión actual del kernel. Puede utilizar la variable de entorno LD_ASSUME_KERNEL para sustituir la versión del kernel que el cargador utilizará en esta prueba. Al definir LD_ASSUME_KERNEL con cualquier versión del kernel inferior a la 2.3.99, puede forzar al cargador a utilizar las librerías OpenGL normales en lugar de las librerías ELF TLS OpenGL. Si, por alguna razón, necesita suprimir la nota de OS ABI de las librerías OpenGL de NVIDIA, puede hacerlo pasando al archivo .run la opción "--no-abi-note" durante la instalación. __________________________________________________________________________ (cap-05) CONTACTO __________________________________________________________________________ Existe un foro Web dedicado a los controladores Linux de NVIDIA. Puede acceder a él entrando en www.nvnews.net y haciendo clic en los vínculos "Forum" y "Linux Discussion Area". Esta es la mejor herramienta para buscar ayuda; los usuarios pueden plantear preguntas, contestar a las preguntas de otros usuarios y realizar búsquedas en los archivos de mensajes anteriores. Y si todo esto falla, pueden ponerse en contacto con NVIDIA en la dirección: linux-bugs@nvidia.com. Le rogamos, no obstante, que antes de enviar un mensaje a esta dirección consulte el capítulo PREGUNTAS MÁS FRECUENTES de este archivo README y consulte sus dudas en el foro nvnews.net. Al enviar mensajes a linux-bugs@nvidia.com, incluya el archivo nvidia-bug-report.log que genera el script nvidia-bug-report.sh (instalado como parte del del controlador). __________________________________________________________________________ (cap-06) OTROS RECURSOS __________________________________________________________________________ Linux OpenGL ABI http://oss.sgi.com/projects/ogl-sample/ABI/ NVIDIA Linux HowTo http://www.tldp.org/HOWTO/XFree86-Video-Timings-HOWTO/index.html OpenGL www.opengl.org The XFree86 Project www.xfree86.org #nvidia (irc.freenode.net) __________________________________________________________________________ (ap-a) APÉNDICE A: PROCESADORES GRÁFICOS DE NVIDIA SOPORTADOS __________________________________________________________________________ NOMBRE DEL CHIP DE NVIDIA ID DEL DISPOSITIVO PCI RIVA TNT 0x0020 RIVA TNT2/TNT2 Pro 0x0028 RIVA TNT2 Ultra 0x0029 Vanta/Vanta LT 0x002C RIVA TNT2 Model 64/Model 64 Pro 0x002D Aladdin TNT2 0x00A0 GeForce 256 0x0100 GeForce DDR 0x0101 Quadro 0x0103 GeForce2 MX/MX 400 0x0110 GeForce2 MX 100/200 0x0111 GeForce2 Go 0x0112 Quadro2 MXR/EX/Go 0x0113 GeForce2 GTS/GeForce2 Pro 0x0150 GeForce2 Ti 0x0151 GeForce2 Ultra 0x0152 Quadro2 Pro 0x0153 GeForce4 MX 460 0x0170 GeForce4 MX 440 0x0171 GeForce4 MX 420 0x0172 GeForce4 MX 440-SE 0x0173 GeForce4 440 Go 0x0174 GeForce4 420 Go 0x0175 GeForce4 420 Go 32M 0x0176 GeForce4 460 Go 0x0177 Quadro4 550 XGL 0x0178 GeForce4 440 Go 64M 0x0179 Quadro NVS 0x017A Quadro4 500 GoGL 0x017C GeForce4 410 Go 16M 0x017D GeForce4 MX 440 with AGP8X 0x0181 GeForce4 MX 440SE with AGP8X 0x0182 GeForce4 MX 420 with AGP8X 0x0183 GeForce4 MX 4000 0x0185 Quadro4 580 XGL 0x0188 Quadro NVS with AGP8X 0x018A Quadro4 380 XGL 0x018B GeForce2 Integrated GPU 0x01A0 GeForce4 MX Integrated GPU 0x01F0 GeForce3 0x0200 GeForce3 Ti 200 0x0201 GeForce3 Ti 500 0x0202 Quadro DCC 0x0203 GeForce4 Ti 4600 0x0250 GeForce4 Ti 4400 0x0251 GeForce4 Ti 4200 0x0253 Quadro4 900 XGL 0x0258 Quadro4 750 XGL 0x0259 Quadro4 700 XGL 0x025B GeForce4 Ti 4800 0x0280 GeForce4 Ti 4200 with AGP8X 0x0281 GeForce4 Ti 4800 SE 0x0282 GeForce4 4200 Go 0x0286 Quadro4 980 XGL 0x0288 Quadro4 780 XGL 0x0289 Quadro4 700 GoGL 0x028C GeForce FX 5800 Ultra 0x0301 GeForce FX 5800 0x0302 Quadro FX 2000 0x0308 Quadro FX 1000 0x0309 GeForce FX 5600 Ultra 0x0311 GeForce FX 5600 0x0312 GeForce FX 5600XT 0x0314 GeForce FX Go5600 0x031A GeForce FX Go5650 0x031B Quadro FX Go700 0x031C GeForce FX 5200 0x0320 GeForce FX 5200 Ultra 0x0321 GeForce FX 5200 0x0322 GeForce FX 5200LE 0x0323 GeForce FX Go5200 0x0324 GeForce FX Go5250 0x0325 GeForce FX 5500 0x0326 GeForce FX 5100 0x0327 GeForce FX Go5200 32M/64M 0x0328 Quadro NVS 280 PCI 0x032A Quadro FX 500/600 PCI 0x032B GeForce FX Go53xx 0x032C GeForce FX Go5100 0x032D GeForce FX 5900 Ultra 0x0330 GeForce FX 5900 0x0331 GeForce FX 5900XT 0x0332 GeForce FX 5950 Ultra 0x0333 GeForce FX 5900ZT 0x0334 Quadro FX 3000 0x0338 Quadro FX 700 0x033F GeForce FX 5700 Ultra 0x0341 GeForce FX 5700 0x0342 GeForce FX 5700LE 0x0343 GeForce FX 5700VE 0x0344 GeForce FX Go5700 0x0347 GeForce FX Go5700 0x0348 Quadro FX Go1000 0x034C Quadro FX 1100 0x034E GeForce 6800 Ultra 0x0040 GeForce 6800 0x0041 GeForce 6800 GT 0x0045 Quadro FX 4000 0x004E GeForce 6800/GeForce 6800 Ultra 0x00F0 Quadro FX 3400 0x00F8 GeForce 6800 Ultra 0x00F9 GeForce PCX 5750 0x00FA GeForce PCX 5900 0x00FB Quadro FX 330/GeForce PCX 5300 0x00FC Quadro NVS 280 PCI-E/Quadro FX 330 0x00FD Quadro FX 1300 0x00FE GeForce PCX 4300 0x00FF __________________________________________________________________________ (ap-b) APÉNDICE B: REQUISITOS MÍNIMOS DE SOFTWARE __________________________________________________________________________ o linux kernel 2.2.12 # cat /proc/version o XFree86 4.0.1 # XFree86 -version, or Xorg 6.7 # Xorg -version o Kernel modutils 2.1.121 # insmod -V Para generar el módulo kernel de NVIDIA: o binutils 2.9.5 # size --version o GNU make 3.77 # make --version o gcc 2.91.66 # gcc --version o glibc 2.0 # /lib/libc.so.6 Si lo genera a partir de archivos rpm: o spec-helper rpm # rpm -qi spec-helper Se admiten todas las versiones oficiales de kernel estable a partir de la 2.2.12; no se admiten las "versiones preliminares" como "2.4.3-pre2", ni las de desarrollo como 2.3.x o 2.5.x. El kernel de linux se puede descargar en www.kernel.org o en uno de sus servidores espejo. Los paquetes binutils se pueden encontrar en www.gnu.org o en uno de sus servidores espejo. Si está utilizando XFree86, pero no cuenta con el archivo /var/log/XFree86.0.log, es probable que tenga una versión 3.x de XFree86 y debe actualizarla. Si va a configurar XFree86 4.x por primera vez, probablemente le resulte más fácil empezar con uno de los controladores de código fuente abierto que incluye XFree86 (ya sea 'nv', 'vga' o 'vesa'). Es más sencillo pasar al controlador de nvidia cuando XFree86 funciona correctamente con el controlador de código fuente abierto. Tenga en cuenta que es posible que las últimas GPU de NVIDIA no funcionen con las antiguas versiones del controlador "nv" incluidas en XFree86. Por ejemplo, el controlador "nv" de la versión 4.0.1 de XFree86 no reconocía las familias de GPU GeForce2 y Quadro2 MXR. No obstante, este fallo se corrigió en la versión 4.0.2 de XFree86 (XFree86 está disponible en www.xfree86.org). También puede conseguir estos paquetes de software en su distribuidor Linux habitual. __________________________________________________________________________ (ap-c) APÉNDICE C: COMPONENTES INSTALADOS __________________________________________________________________________ El juego de controladores acelerados para Linux de NVIDIA constan de los siguientes componentes (el archivo que aparece entre paréntesis es el nombre completo del componente una vez instalado; "x.y.z" indica la versión actual -- en estos casos, durante la instalación se crean los enlaces simbólicos apropiados): o Un controlador X (/usr/X11R6/lib/modules/drivers/nvidia_drv.o); X server necesita este controlador para poder utilizar el hardware de NVIDIA. El controlador nvidia_drv.o es binario y compatible con XFree86 4.0.1 y versiones posteriores, así como con la versión de X server publicada por Xorg. o Un módulo de extensión GLX para X (/usr/X11R6/lib/modules/extensions/libglx.so.x.y.z); X server utiliza este módulo para proporcionar soporte glx al servidor. o Una librería OpenGL (/usr/lib/libGL.so.x.y.z); esta librería proporciona a la API puntos de entrada para todas las llamadas a funciones OpenGL y GLX. Está vinculada a tiempo de ejecución por aplicaciones OpenGL. o Una librería básica OpenGL (/usr/lib/libGLcore.so.x.y.z); libGL y libglx utilizan implícitamente esta librería. Contiene la función básica de aceleración 3D. No se debe cargar explícitamente en el archivo de configuración de X, ya que libglx se encarga de ello. o Dos librerías XvMC (compensación de movimiento de X-Video): una librería estática y otra compartida (/usr/X11R6/lib/libXvMCNVIDIA.a, /usr/X11R6/lib/libXvMCNVIDIA.so.x.y.z). Consulte el (ap-p) APÉNDICE P: SOPORTE DE XVMC para obtener más información. o Un módulo kernel (/lib/modules/`uname -r`/video/nvidia.o, o bien /lib/modules/`uname -r`/kernel/drivers/video/nvidia.o). Este módulo kernel proporciona acceso de bajo nivel al hardware de NVIDIA a todos los componentes anteriormente citados. Por lo general, se carga en el kernel cuando se inicia X server, y es utilizado por el controlador X y OpenGL. nvidia.o consta de dos elementos: el núcleo sólo binario, y una interfaz del kernel que es necesario compilar en función de la versión del kernel. Tenga en cuenta que el kernel de linux no tiene una interfaz binaria asociada como X server, por lo que es importante que la interfaz del kernel coincida con la versión del kernel que esté utilizando. Para ello, puede realizar usted mismo la compilación o utilizar los binarios precompilados que se suministran en algunas de las distribuciones más comunes de linux. o Archivos de encabezado OpenGL y GLX (/usr/share/doc/NVIDIA_GLX-1.0/include/GL/gl.h y /usr/share/doc/NVIDIA_GLX-1.0/include/GL/glx.h). Estos archivos también se pueden instalar en /usr/include/GL/ pasando la opción "--opengl-headers" al archivo .run durante la instalación. o Las librerías nvidia-tls (/usr/lib/libnvidia-tls.so.x.y.z y /usr/lib/tls/libnvidia-tls.so.x.y.z). Estos archivos proporcionan soporte de almacenamiento local de subprocesos para las librerías OpenGL de NVIDIA (libGL, libGLcore y libglx). Cada librería nvidia-tls proporciona soporte para un modelo de almacenamiento específico (como ELF TLS); el más apropiado para su sistema se carga en tiempo de ejecución. o La aplicación nvidia-installer (/usr/bin/nvidia-installer) es la herramienta de NVIDIA para instalar y actualizar los controladores NVIDIA. Consulte (cap-02) INSTALACIÓN DEL CONTROLADOR NVIDIA para obtener una descripción más completa. Es muy probable que se produzcan problemas si las aplicaciones utilizan la versión incorrecta de una librería. Esto puede suceder si todavía hay librerías libGL anteriores o enlaces simbólicos obsoletos. Si cree que puede haber algo incorrecto en su instalación, compruebe que los siguientes archivos están instalados (son todos los archivos del juego de controladores acelerados para Linux de NVIDIA y sus enlaces simbólicos): /usr/X11R6/lib/modules/drivers/nvidia_drv.o /usr/X11R6/lib/modules/extensions/libglx.so.x.y.z /usr/X11R6/lib/modules/extensions/libglx.so -> libglx.so.x.y.z /usr/lib/libGL.so.x.y.z /usr/lib/libGL.so.x -> libGL.so.x.y.z /usr/lib/libGL.so -> libGL.so.x /usr/lib/libGLcore.so.x.y.z /usr/lib/libGLcore.so.x -> libGLcore.so.x.y.z /lib/modules/`uname -r`/video/nvidia.o, o /lib/modules/`uname -r`/kernel/drivers/video/nvidia.o La instalación también se crea los siguientes archivos /dev: crw-rw-rw- 1 root root 195, 0 Feb 15 17:21 nvidia0 crw-rw-rw- 1 root root 195, 1 Feb 15 17:21 nvidia1 crw-rw-rw- 1 root root 195, 2 Feb 15 17:21 nvidia2 crw-rw-rw- 1 root root 195, 3 Feb 15 17:21 nvidia3 crw-rw-rw- 1 root root 195, 255 Feb 15 17:21 nvidiactl Si hay otras librerías cuyo "soname" entre en conflicto con las librerías de NVIDIA, es posible que ldconfig cree enlaces simbólicos incorrectos. Es recomendable que elimine manualmente o renombre las librerías que producen conflictos(asegúrese de asignarles un nombre que no afecte a ldconfig; anteponiendo "XXX" al nombre de la librería se suele resolver el problema), vuelva a ejecutar 'ldconfig' y compruebe si se han creado los enlaces simbólicos correctos. Algunas librerías que suelen dar lugar a conflictos son "/usr/X11R6/lib/libGL.so*" y "/usr/X11R6/lib/libGLcore.so*". Una vez comprobadas las librerías, verifique que la aplicación está utilizando las librerías adecuadas. Por ejemplo, para comprobar que la aplicación /usr/X11R6/bin/gears está utilizando las librerías NVIDIA, tendrá que hacer lo siguiente: $ ldd /usr/X11R6/bin/gears libglut.so.3 => /usr/lib/libglut.so.3 (0x40014000) libGLU.so.1 => /usr/lib/libGLU.so.1 (0x40046000) libGL.so.1 => /usr/lib/libGL.so.1 (0x40062000) libc.so.6 => /lib/libc.so.6 (0x4009f000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4018d000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40196000) libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x401ac000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x401c0000) libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x401cd000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x401d6000) libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0x402ab000) libm.so.6 => /lib/libm.so.6 (0x4048d000) libdl.so.2 => /lib/libdl.so.2 (0x404a9000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x404ac000) Anote los archivos utilizados por libGL y libGLcore; en caso de que no sean las librerías de NVIDIA, tendrá que eliminar las librerías que están causando problemas o ajustar la ruta de búsqueda ld. Si alguno de estos archivos le resulta extraño, consulte el manual de ayuda en línea de "ldconfig" y "ldd". __________________________________________________________________________ (ap-d) APÉNDICE D: OPCIONES DEL ARCHIVO DE CONFIGURACIÓN DE X __________________________________________________________________________ El controlador X de NVIDIA admite las siguientes opciones, que deben especificarse en las secciones Screen o Device del archivo de configuración de X: Opción "NvAGP" "entero" Esta opción sirve para configurar el soporte AGP. El argumento "entero" puede ser uno de los siguientes: 0 : desactivar agp 1 : utilizar el soporte AGP interno de NVIDIA, si es posible 2 : utilizar AGPGART, si es posible 3 : utilizar cualquier soporte agp (probar con AGPGART y luego con AGP de NVIDIA) Tenga en cuenta que el soporte AGP interno de NVIDIA no puede funcionar si AGPGART está compilado estáticamente en el kernel o si ha sido generado como módulo. Por el contrario, tiene que cargarse en el kernel (algunas distribuciones cargan AGPGART en el kernel al iniciar el equipo). Valor predeterminado: 3 (el valor predeterminado era 1 hasta la versión 1.0-1251). Opción "NoLogo" "booleano" Para desactivar la aparición del logotipo de NVIDIA en la pantalla de bienvenida al iniciar X. Valor predeterminado: logotipo activo. Opción "RenderAccel" "booleano" Activa o desactiva la aceleración por hardware de la extensión RENDER. ESTA OPCIÓN ES EXPERIMENTAL. PUEDE ACTIVARLA BAJO SU PROPIA RESPONSABILIDAD. No existe ninguna prueba que certifique el funcionamiento de la extensión RENDER, por lo que NVIDIA no puede verificar el correcto funcionamiento de su aceleracion. Valor predeterminado: la aceleración está desactivada. Opción "NoRenderExtension" "booleano" Desactiva la extensión RENDER. Aparte de recompilar X server, XFree86 no parece tener otra forma de desactivarla. Afortunadamente, podemos controlar esta función desde el controlador, así que exportamos esta opción. Resulta útil con profundidad 8, donde RENDER normalmente se apropiaría de la mayor parte del mapa de colores predeterminado. Valor predeterminado: se proporciona RENDER siempre que es posible. Opción "UBB" "booleano" Activa o desactiva el Unified Back Buffer en cualquier GPU Quadro. En el Apéndice M encontrará una descripción de este búfer. Esta opción no afecta a los chipset que no pertenecen a la gama Quadro. Valor predeterminado: activado en los chipset Quadro. Opción "NoFlip" "booleano" Activa o desactiva la opción de Flipping de OpenGL. Si precisa más información, consulte el Apéndice M. Valor predeterminado: OpenGL realizará el intercambio mediante flipping siempre que sea posible. Opción "DigitalVibrance" "entero" Activa la función Digital Vibrance Control. Los valores válidos se sitúan entre 0 y 255. Esta función no está disponible en productos anteriores a GeForce2. Valor predeterminado: 0. Opción "Dac8Bit" "booleano" La mayoría de los productos Quadro utilizan de forma predeterminada una tabla de búsqueda de colores de 10 bits (Lookup Table o LUT). Cuando esta opción se configura con TRUE, estos procesadores utilizan una LUT de 8 bits. Valor predeterminado: utilizar LUT de 10 bits cuando esté disponible. Opción "Overlay" "booleano" Activa la superposición de objetos (overlays) RGB en las estaciones de trabajo. Sólo puede utilizarse en los procesadores Quadro4 y Quadro FX (Quadro4 NVS está excluido) con profundidad 24. Esta opción hace que el servidor detecte la propiedad SERVER_OVERLAY_VISUALS de la ventana raíz y GLX informe de la existencia de superposiciones de 16 bits (uno o dos búfers y búfer Z). La clave de transparencia es el píxel 0x0000 (hex). No existe soporte de corrección gamma en el plano de superposición. Esta función precisa XFree86 versión 4.1.0 o una versión posterior (o X server de Xorg). Los procesadores Quadro basados en NV17/18 (p. ej. 500/550 XGL) tienen restricciones adicionales, lo que significa que no se admiten superposiciones en modo TwinView ni con escritorios virtuales mayores de 2046 x 2047 en cualquier dimensión (p. ej. no funcionará en modos 2048 x 1536). Los modelos Quadro 7xx/9xx y Quadro FX ofrecerán overlays en estos modos (TwinView o escritorios virtuales mayores de 2046 x 2047), pero se hará a través de emulación con un considerable perjuicio para el rendimiento. Valor predeterminado: desactivada. Opción "CIOverlay" "booleano" Activa la superposición de elementos visuales (overlay) en modo de índice de colores (Color Index) con restricciones similares a las que presenta la opción "Overlay" anterior. El servidor ofrece los objetos gráficos con y sin clave de transparencia. Se trata de elementos visuales PseudoColor con profundidad 8. La activación de la superposición de objetos en modo Color Index en servidores X anteriores a XFree86 4.3 desactiva automáticamente la extensión RENDER a causa de algunos errores de software de dicha extensión en servidores X previos a la citada versión. Valor predeterminado: desactivada. Opción "TransparentIndex" "entero" Cuando están activadas las superposiciones (overlays) en modo de índice de colores, esta opción permite elegir cuál será el valor de transparencia que se utilizará para los elementos visuales que incluyan píxeles transparentes. Puede ser cualquier valor situado entre 0 y 255 (Nota: algunas aplicaciones como Maya de Alias/Wavefront necesitan que el valor sea 0 para funcionar correctamente). Valor predeterminado: 0. Opción "OverlayDefaultVisual" "booleano" Cuando se utilizan superposiciones (overlays), esta opción configura el elemento visual predeterminado como elemento de superposición, con lo que sitúa la ventana raíz en la superposición. No es una opción recomendada para overlays en modo RGB. Valor predeterminado: desactivada. Opción "SWCursor" "booleano" Activa o desactiva el modo de renderizado por software del cursor X. Valor predeterminado: desactivado. Opción "HWCursor" "booleano" Activa o desactiva el modo de renderizado por hardware del cursor X. Valor predeterminado: activado. Opción "CursorShadow" "booleano" Activa o desactiva el uso de una sombra con el cursor acelerado por hardware; se trata de una sombra de color negro translúcido con la misma forma que el cursor, situada a una determinada distancia del cursor real. Esta opción sólo está disponible en la GeForce2 o versiones superiores del hardware (lo que significa todas excepto TNT/TNT2, GeForce 256, GeForce DDR y Quadro). Valor predeterminado: cursor sin sombra. Opción "CursorShadowAlpha" "entero" Define el valor alfa que se debe utilizar para la sombra del cursor; sólo se puede aplicar si la opción CursorShadow está activada. Este valor debe estar comprendido en el rango [0, 255], donde 0 es completamente transparente y 255 es totalmente opaco. Valor predeterminado: 64. Opción "CursorShadowXOffset" "entero" Indica el desplazamiento hacia la derecha, calculado en píxeles, de la sombra con respecto a la imagen del cursor real; sólo se puede aplicar si la opción CursorShadow está activada. Este valor debe estar comprendido en el rango [0, 32]. Valor predeterminado: 4. Opción "CursorShadowYOffset" "entero" Indica el desplazamiento hacia abajo, calculado en píxeles, de la sombra con respecto a la imagen del cursor real; sólo se puede aplicar si la opción CursorShadow está activada. Este valor debe estar comprendido en el rango [0, 32]. Valor predeterminado: 2. Opción "ConnectedMonitor" "cadena" Permite omitir lo que el módulo kernel de NVIDIA detecta como conectado a la tarjeta de vídeo. Esto puede resultar útil, por ejemplo, si utiliza un conmutador KVM (teclado, vídeo, ratón) y está desconectado cuando se inicia X. En este caso, el módulo kernel de NVIDIA no puede detectar qué dispositivos de visualización están conectados y el controlador X de NVIDIA supone que hay un único monitor CRT. Los valores válidos para esta opción son "CRT" (tubo de rayos catódicos), "DFP" (pantalla digital plana) o "TV" (televisión); si se utiliza TwinView, esta opción puede estar formada por una lista de dispositivos de visualización separados por comas, como por ejemplo "CRT, CRT" o "CRT, DFP". NOTA: el controlador considera cualquier dispositivo enchufado a un conector VGA de 15 patillas como un monitor CRT (tubo de rayos catódicos). "DFP" sólo debe utilizarse para hacer referencia a pantallas planas conectadas mediante un puerto DVI. Valor predeterminado: el valor de la cadena es NULL. Opción "UseEdidFreqs" "booleano" Esta opción hace que X server utilice los rangos HorizSync y VertRefresh que aparecen en los datos EDID del dispositivo de visualización, si los hay. La información de intervalo proporcionada por los datos EDID anulará los rangos HorizSync y VertRefresh especificados en la sección "Monitor". Si el dispositivo de pantalla no proporciona los datos EDID, o estos datos no especifican ningún rango hsync o vrefresh, X server utilizará como valores predeterminados los rangos HorizSync y VertRefresh especificados en la sección "Monitor". Opción "IgnoreEDID" "booleano" Desactiva la obtención de datos EDID (datos extendidos de identificación de la pantalla) de su monitor. Los modos solicitados se comparan con los valores obtenidos de los datos EDID de su monitor (en caso de que los haya) durante la validación del modo. Algunos monitores proporcionan datos incorrectos acerca de sus capacidades. Si se ignoran los valores que ofrece el monitor puede resultar más sencillo validar un determinado modo. Por otra parte, puede ser peligroso ni no se sabe lo que se está haciendo. Valor predeterminado: utilizar los datos EDID. Opción "NoDDC" "booleano" Igual que la opción "IgnoreEDID". Opción "FlatPanelProperties" "cadena" Solicita las propiedades de cualquier pantalla plana en forma de una lista de equivalencias propiedad=valor separadas por comas. Las dos propiedades disponibles en este momento son 'Scaling' y 'Dithering'. Los valores admitidos para 'Scaling' son: 'default' (el controlador utiliza la escala que esté seleccionada en ese momento), 'native' (utiliza el escalador de la pantalla plana, si lo tiene), 'scaled' (utiliza el escalador de NVIDIA, si es posible), 'centered' (centra la imagen, si es posible) y 'aspect-scaled' (utiliza el escalador de NVIDIA pero mantiene la relación de aspecto adecuada). Los valores admitidos para 'Dithering' son: 'default' (el controlador decide cuándo aplicar tramado), 'enabled' (el controlador trata de aplicar tramado siempre que es posible) y 'disabled' (nunca aplica tramado). Si no se especifica alguna propiedad, su valor se establece como 'default'. Un ejemplo de cadena de propiedades podría ser: "Scaling = centered, Dithering = enabled" Opción "UseInt10Module" "booleano" Permite utilizar el módulo Int10 de X para realizar un reinicio suave de todas las tarjetas secundarias, en vez de hacer que pasen por el módulo kernel de NVIDIA. Valor predeterminado: desactivada (las tarjetas pasan por el módulo kernel de NVIDIA). Opción "TwinView" "booleano" Activa o desactiva TwinView. Si desea más detalles consulte el APÉNDICE I. Valor predeterminado: desactivada. Opción "TwinViewOrientation" "cadena" Controla la relación entre dos dispositivos de visualización cuando se está utilizando TwinView. Existen los siguientes valores: "RightOf" (a la derecha) "LeftOf" (a la izquierda) "Above" (arriba) "Below" (abajo) "Clone" (clónico). Si desea más detalles consulte el APÉNDICE I. Valor predeterminado: el valor de la cadena es NULL. Opción "SecondMonitorHorizSync" "rango(s)" Esta opción es como la entrada HorizSync de la sección "Monitor", pero para el segundo monitor cuando se utiliza TwinView. Si desea más detalles consulte el APÉNDICE I. Valor predeterminado: ninguno. Opción "SecondMonitorVertRefresh" "rango(s)" Esta opción es como la entrada VertRefresh de la sección "Monitor", pero para el segundo monitor cuando se utiliza TwinView. Si desea más detalles consulte el APÉNDICE I. Valor predeterminado: ninguno. Opción "MetaModes" "cadena" Esta opción describe la combinación de modos que se pueden utilizar en cada monitor cuando está activa la función TwinView. Si desea más detalles consulte el APÉNDICE I. Valor predeterminado: el valor de la cadena es NULL. Opción "NoTwinViewXineramaInfo" "booleano" Cuando está activado el modo TwinView, el controlador X de NVIDIA normalmente proporciona un extensión Xinerama que los clientes X (como son los administradores de ventanas) pueden utilizar para detectar la configuración que tiene TwinView. Esto confunde a algunos administradores de ventanas, así que esta opción se incluye para desactivar este comportamiento. Valor predeterminado: suministrar la información de Xinerama en TwinView. Opción "TVStandard" "cadena" Consulte el (ap-j) APÉNDICE J: CONFIGURACIÓN DE LA SALIDA A TV. Opción "TVOutFormat" "cadena" Consulte el (ap-j) APÉNDICE J: CONFIGURACIÓN DE LA SALIDA A TV. Opción "TVOverScan" "Valor decimal situado entre 0.0 y 1.0" Los valores admitidos se sitúan entre 0.0 y 1.0. Consulte el (ap-j) APÉNDICE J: CONFIGURACIÓN DE LA SALIDA A TV. Opción "Stereo" "entero" Activa la visualización de imágenes estereoscópicas a través de un cuatro búfers en los procesadores Quadro. El entero indica el tipo de gafas de visión estereoscópica utilizado: 1 - Gafas DDC. La señal de sincronización se envía a las gafas a través de la señal DDC transmitida al monitor. Normalmente implican la conexión de un cable entre el monitor y la tarjeta de vídeo. 2 - Gafas "Blueline". Suelen implicar la conexión de un cable entre el monitor y la tarjeta de vídeo. Las gafas saben a qué ojo deben enviar la imagen basándose en la longitud de una línea azul visible en la parte inferior de la pantalla. Cuando se activa esta opción, las dimensiones de la ventana raíz son un píxel más cortas en el eje Y de lo requerido. Este modo no funciona con ventanas raíz más grandes que la ventana raíz visible (desktop panning). 3 - Soporte de gafas estereoscópicas en la placa. Normalmente esta función sólo se encuentra en tarjetas de uso profesional. Las gafas se conectan a través de un puerto DIN a la parte posterior de la tarjeta de vídeo. 4 - Imagen estereoscópica en modo clonación de TwinView (también conocida como visión pasiva). En las tarjetas de vídeo que incluyen la función TwinView, el ojo izquierdo recibe la primera imagen y el derecho la segunda. Esto se utiliza normalmente en combinación con unos proyectores especiales para generar 2 imágenes polarizadas que se ven con gafas polarizadas. Para utilizar este modo, es preciso configurar TwinView en modo clonación con la misma resolución, el mismo desplazamiento panorámico y similares dominios de panoramización en cada monitor. El modo estereoscópico sólo está disponible en las tarjetas Quadro. Las opciones de Stereo 1, 2 y 3 (también conocidas como visión "activa") pueden utilizarse con TwinView si todos los modos dentro de cada MetaMode tienen idénticos valores de tiempo. Consulte el (ap-l) APÉNDICE L: MODOS DE PROGRAMACIÓN para conocer la forma de comprobar si los modos incluidos en los MetaMode son idénticos. Este requisito no es necesario para la opción 4 de Stereo (visión "pasiva"). El funcionamiento de la visión estereoscópica puede resultar algo "tosco" en el procesador Quadro (NV10) original y el cambio de izquierda a derecha puede ser errático. Estamos tratando de resolver el problema en futuras versiones. Valor predeterminado: visión estereoscópica desactivada. Las opciones 1, 2 y 3 (visión "activa") de visión estereoscópica no pueden utilizarse con pantallas planas digitales. Opción "AllowDFPStereo" "boolean" El controlador de NVIDIA X realiza automáticamente una comprobación que desactiva la visión estéreo activa (opciones 1, 2 y 3) si la pantalla de X está controlando una pantalla plana digital (DFP). La opción "AllowDFPStereo" desactiva esta comprobación. Opción "NoBandWidthTest" "booleano" Como parte del modo de validación, el controlador X comprueba si un determinado modo se ajusta a las restricciones de ancho de banda de la memoria del hardware. Esta opción desactiva esta prueba. Valor predeterminado: realizar la prueba de ancho de banda. Opción "IgnoreDisplayDevices" "cadena" Esta opción indica al módulo kernel de NVISIA que no tenga en cuenta las clases de dispositivos de visualización indicadas cuando compruebe qué dispositivos están conectados. Puede especificar una lista que contenga cualquiera de los dispositivos, "CRT", "DFP" y "TV", separados por comas. Por ejemplo: La opción "IgnoreDisplayDevices" "DFP, TV" impedirá que el controlador NVIDIA trate de detectar si hay pantallas planas o televisores conectados. Normalmente esta opción no es necesaria, pero algunas BIOS del sistema de vídeo contienen información incorrecta sobre los dispositivos de visualización que pueden conectarse o el puerto i2c que debería utilizarse para la detección. Estos errores pueden provocar retrasos en el arranque de X. Si experimenta tales retrasos, puede evitarlos indicando al controlador NVIDIA que no tenga en cuenta los dispositivos que usted sabe que no están conectados. NOTA: el controlador considera cualquier dispositivo enchufado a un conector VGA de 15 patillas como un monitor CRT (tubo de rayos catódicos). "DFP" sólo debe utilizarse para hacer referencia a pantallas planas conectadas mediante un puerto DVI. Opción "MultisampleCompatibility" "booleano" Activa o desactiva el uso de un buffer frontal y otro posterior para operaciones de multimuestreo. Esto consume más memoria, pero es indispensable para corregir la salida cuando se renderiza en ambos buffers al realizar antialiasing en pantalla completa (FSAA). Es un opción necesaria para el correcto funcionamiento de SoftImage XSI. Valor predeterminado: un solo buffer de muestras compartido por los buffers frontal y posterior. Opción "NoPowerConnectorCheck" "booleano" El controlador X de NVIDIA interrumpirá la inicialización de X server si detecta que una GPU que necesita alimentación externa no tiene ningún conector introducido. Esta opción puede utilizarse para sortear esta prueba. Valor predeterminado: realizar la prueba de la conexión de alimentación. Opción "XvmcUsesTextures" "booleano" Obliga a XvMC a usar el motor 3D para las peticiones XvMCPutSurface en lugar de la superposición (overlay) de vídeo. Valor predeterminado: utilizar la superposición de vídeo si está disponible. __________________________________________________________________________ (ap-e) APÉNDICE E: CONFIGURACIÓN DE LA VARIABLE DE ENTORNO OPENGL __________________________________________________________________________ ANTIALIASING EN PANTALLA COMPLETA (FSAA) El antialiasing o antidistorsión es una técnica utilizada para suavizar los bordes de los objetos que aparecen en una escena y reducir el efecto "dentado" que se observa en ocasiones. La función de antialiasing se incluye en todo el hardware de NVIDIA a partir de GeForce. Si se establece la variable de entorno adecuada, se podrá activar la función de antialiasing en cualquier aplicación OpenGL en estas GPU. Hay disponibles varios métodos de antidistorsión y se pueden seleccionar definiendo adecuadamente la variable de entorno __GL_FSAA_MODE. Tenga en cuenta que el hecho de aumentar el número de muestras tomadas cuando la función de antidistorsión en pantalla completa está activada puede disminuir el rendimiento. En las tablas siguientes se describen los valores disponibles para __GL_FSAA_MODE y su efecto en las distintas GPU NVIDIA. __GL_FSAA_MODE GeForce, GeForce2, Quadro y Quadro2 Pro ----------------------------------------------------------------------- 0 FSAA desactivado 1 FSAA desactivado 2 FSAA desactivado 3 Supermuestreo 1,5 x 1,5 4 Supermuestreo 2 x 2 5 FSAA desactivado 6 FSAA desactivado 7 FSAA desactivado __GL_FSAA_MODE GeForce4 MX, GeForce4 4xx Go, Quadro4 380,550,580 XGL y Quadro4 NVS ----------------------------------------------------------------------- 0 FSAA desactivado 1 Multimuestreo bilineal 2x 2 Multimuestreo Quincunx 2x 3 FSAA desactivado 4 Supermuestreo 2 x 2 5 FSAA desactivado 6 FSAA desactivado 7 FSAA desactivado __GL_FSAA_MODE GeForce3, Quadro DCC, GeForce4 Ti, GeForce4 4200 Go y Quadro4 700,750,780,900,980 XGL ----------------------------------------------------------------------- 0 FSAA desactivado 1 Multimuestreo bilineal 2x 2 Multimuestreo Quincunx 2x 3 FSAA desactivado 4 Multimuestreo bilineal 4x 5 Multimuestreo gaussiano 4x 6 Multimuestreo bilineal 2x por supermuestreo 4x 7 FSAA desactivado __GL_FSAA_MODE GeForce FX, Quadro FX ----------------------------------------------------------------------- 0 FSAA desactivado 1 Multimuestreo bilineal 2x 2 Multimuestreo Quincunx 2x 3 FSAA desactivado 4 Multimuestreo bilineal 4x 5 Multimuestreo gaussiano 4x 6 Multimuestreo bilineal 2x por supermuestreo 4x 7 Multimuestreo bilineal 4x por supermuestreo 4x FILTRADO ANISOTRÓPICO DE TEXTURAS El filtrado anisotrópico de texturas automático puede activarse configurando la variable de entorno __GL_DEFAULT_LOG_ANISO. Los valores disponibles son: Descripción de __GL_DEFAULT_LOG_ANISO en GeForce/GeForce2/GeForce4 MX ----------------------------------------------------------------------- 0 Sin filtrado anisotrópico 1 Filtrado anisotrópico automático activado Descripción de __GL_DEFAULT_LOG_ANISO en GeForce3/GeForce4 Ti/GeForce FX ------------------------------------------------------------------------ 0 Sin filtrado anisotrópico 1 Filtrado bajo 2 Filtrado medio 3 Máximo filtrado SINCRONIZACIÓN DEL BLANQUEO VERTICAL (VBLANK) Al establecer la variable de entorno __GL_SYNC_TO_VBLANK en un valor distinto de cero, glXSwapBuffers se sincroniza a la velocidad de actualización vertical de su monitor (se realiza un cambio únicamente durante el periodo de blanqueo vertical). Si se utiliza __GL_SYNC_TO_VBLANK con TwinView, OpenGL sólo puede sincronizarse con una de las pantallas, lo cual puede provocar defectos de visualización en la pantalla no sincronizada. Mediante la variable de entorno __GL_SYNC_DISPLAY_DEVICE es posible especificar el dispositivo de visualización con el que debe sincronizarse OpenGL. Para hacerlo, es preciso configurar la variable con el nombre del dispositivo, por ejemplo, "CRT-1". Busque la línea "Connected display device(s):" en el archivo de registro de X para conocer la lista de dispositivos de visualización existentes y sus nombres. DESACTIVACIÓN DE FUNCIONES ESPECÍFICAS DE LA CPU Si la variable de entorno __GL_FORCE_GENERIC_CPU se configura con un valor distinto de cero, se inhibirá el uso de funciones específicas de la CPU como MMX, SSE o 3DNOW!. El uso de esta opción puede provocar una disminución del rendimiento, aunque puede ser útil en combinación con determinado software como el depurador de memoria Valgrind. __________________________________________________________________________ (ap-f) APÉNDICE F: CONFIGURACIÓN DE AGP __________________________________________________________________________ Existen varias opciones para configurar el uso de AGP del módulo kernel de NVIDIA: puede elegir entre utilizar el módulo AGP de NVIDIA (NVAGP), o el módulo AGP que incluye el kernel linux (AGPGART). Esto se puede controlar mediante la opción "NvAGP" del archivo de configuración de X: La opción "NvAgp" "0" ... deshabilita el soporte AGP La opción "NvAgp" "1" ... utiliza NVAGP, si es posible La opción "NvAgp" "2" ... utiliza AGPGART, si es posible La opción "NvAGP" "3" ... prueba con AGPGART y si falla, lo intenta con NVAGP El valor predeterminado es 3 (anteriormente era 1, hasta que apareció la versión 1.0-1251). Lo más conveniente es que utilice el módulo AGP que mejor funcione con su conjunto de chips AGP. Si tiene problemas de estabilidad, es conveniente que desactive el puerto AGP y compruebe si de este modo se resuelven los problemas. Después puede probar con cualquiera de los módulos AGP. Puede comprobar el estado de AGP en cualquier momento mediante la interfaz /proc filesystem (consulte el APÉNDICE O: INTERFAZ PROC). Para utilizar el módulo Linux AGPGART, tendrá que estar compilado con el kernel, ya sea por vínculo estático o generado como módulo. El soporte AGP de NVIDIA no se puede utilizar si AGPGART está cargado en el kernel. Conviene compilar AGPGART como un módulo y asegurarse de que no se carga al intentar utilizar el soporte AGP de NVIDIA. Tenga en cuenta que, por lo general, una vez cambiados los controladores AGP, es necesario reiniciar el equipo para que dichos cambios tengan efecto. Los controladores AGP de NVIDIA son compatibles con los chipsets AGP que se indican a continuación; para todos los demás chipsets, se recomienda utilizar el módulo AGPGART. o Intel 440LX o Intel 440BX o Intel 440GX o Intel 815 ("Solano") o Intel 820 ("Camino") o Intel 830 o Intel 840 ("Carmel") o Intel 845 ("Brookdale") o Intel 845G o Intel 850 ("Tehama") o Intel 855 ("Odem") o Intel 860 ("Colusa") o Intel 865G ("Springdale") o Intel 875P ("Canterwood") o Intel E7205 ("Granite Bay") o Intel E7505 ("Placer") o AMD 751 ("Irongate") o AMD 761 ("IGD4") o AMD 762 ("IGD4 MP") o AMD 8151 ("Lokar") o VIA 8371 o VIA 82C694X o VIA KT133 o VIA KT266 o VIA KT400 o VIA P4M266 o VIA P4M266A o VIA P4X400 o RCC CNB20LE o RCC 6585HE o Micron SAMDDR ("Samurai") o Micron SCIDDR ("Scimitar") o NVIDIA nForce o NVIDIA nForce2 o NVIDIA nForce3 o ALi 1621 o ALi 1631 o ALi 1647 o ALi 1651 o ALi 1671 o SiS 630 o SiS 633 o SiS 635 o SiS 645 o SiS 646 o SiS 648 o SiS 648FX o SiS 650 o SiS 655FX o SiS 730 o SiS 733 o SiS 735 o SiS 745 o ATI RS200M Si AGP presenta problemas de estabilidad, debe tener en cuenta lo siguiente: o Soporte de la extensión de tamaño de página (Page Size Extension) en procesadores Athlon Algunos kernels de Linux presentan un problema de conflicto en los atributos de caché debido a una función avanzada de lectura especulativa de la memoria y almacenamiento de los datos en caché (advanced speculative caching). Esta función está incorporada en la nueva familia de procesadores AMD Athlon (AMD Athlon XP, AMD Athlong 4, AMD Athlon MP y modelos 6 superiores de AMD Duron) y el error del kernel se manifiesta cuando se utilizan con intensidad gráficos 3D acelerados con una tarjeta gráfica AGP. Las distribuciones de Linux basadas en el kernel 2.4.19 y versiones posteriores *deberían* incorporar la corrección de este problema, pero los kernels anteriores precisan la intervención del usuario para desactivar una pequeña parte de la función de lectura-escritura especulativa (normalmente a través de un parche del kernel) y especificar una opción de arranque que aplique la corrección completa. El controlador de NVIDIA desactiva automáticamente esa pequeña parte de la función para los procesadores AMD implicados sin necesidad de aplicar ningún parche al kernel. Puede utilizarse incluso en kernels que ya incorporan la corrección del error. Además, para kernels antiguos, el usuario debe especificar la opción de arranque de la corrección desactivando expresamente páginas de 4 MB. Esto se puede realizar escribiendo lo siguiente en la línea de comandos de arranque: mem=nopentium O añadiendo la línea siguiente a etc/lilo.conf: append = "mem=nopentium" o Configuración de la fuerza de la señal de control de AGP en la BIOS (placas base con chips Via) Muchas placas base con chips Via permiten ajustar la fuerza de la señal de control de AGP en la BIOS del sistema. La configuracion de esta opción afecta considerablemente a la estabilidad del sistema y los valores hexadecimales situados entre 0xEA y 0xEE son los que parecen funcionar mejor con el hardware de NVIDIA. La configuración de cualquiera de las dos mitades del byte como 0xF suele generar serios problemas de estabilidad. Si decide realizar cambios en esta opción, recuerde que los hace bajo su propia responsabilidad y que, si los valores son inadecuados, es posible que el sistema no pueda arrancar hasta que vuelva a definir un valor aceptable (con una tarjeta gráfica PCI o restableciendo los valores predeterminados de la BIOS). o Versión de la BIOS del sistema Cerciórese de tener la última versión de la BIOS del sistema suministrada por el fabricante de la placa. o Velocidad de AGP Puede que le interese reducir la velocidad de AGP si detecta problemas de bloqueo con el valor que está utilizando. Puede hacerlo descomprimiendo el archivo .run como sigue: sh NVIDIA-Linux-x86-1.0-6111-pkg1.run --extract-only cd NVIDIA-Linux-x86-1.0-6111-pkg1/usr/src/nv/ A continuación, haga los cambios siguientes en el archivo os-registry.c: - static int NVreg_ReqAGPRate = 7; + static int NVreg_ReqAGPRate = 4; /* fuerza el modo 4x */ o + static int NVreg_ReqAGPRate = 2; /* fuerza el modo 2x */ o + static int NVreg_ReqAGPRate = 1; /* fuerza el modo 1x */ Active el parámetro "ReqAGPRate": - { NULL, "ReqAGPRate", &NVreg_ReqAGPRate, 0 }, + { NULL, "ReqAGPRate", &NVreg_ReqAGPRate, 1 }, Por último recompile y cargue el nuevo módulo kernel. En las placas base Athlon con chipset VIA KX133 o 694X, como por ejemplo la placa base ASUS K7V, los controladores de NVIDIA seleccionan el modo AGP 2x de forma predeterminada para paliar la falta de fuerza en una de las señales. Se puede establecer el modo AGP 4x configurando la variable NVreg_EnableVia4x con el valor 1. Tenga en cuenta que esto puede hacer que el sistema se vuelva inestable. En los chipsets ALi1541 y ALi1647, los controladores de NVIDIA deshabilitan el puerto AGP para solucionar los problemas de temporización y los de integridad de la señal. Se puede establecer el modo AGP en estos chipsets configurando la variable NVreg_EnableALiAGP con el valor 1. Tenga en cuenta que esto puede hacer que el sistema se vuelva inestable. Versiones antiguas de SBIOS de la placa base A7V8X-X KT400 de ASUS configura el chipset de forma incorrecta cuando se instala una tarjeta gráfica AGP 2.x. Si X se bloquea en el sistema ASUS KT400 cuando están activados los controladores AGPGART o NvAGP de Linux en una tarjeta gráfica que no es AGP 8x, compruebe si tiene la última versión de SBIOS instalada. __________________________________________________________________________ (ap-g) APÉNDICE G: PROBLEMAS ESPECÍFICOS DE ALI __________________________________________________________________________ Las siguientes pistas pueden ser de gran ayuda para estabilizar los sistemas ALI problemáticos: o Desactive el MODO AGP TURBO en la BIOS. o Cuando utilice una placa base P5A, actualice a la versión BIOS Revision 1002 BETA 2. o Cuando utilice 1007, 1007A o 1009 ajuste el tiempo de recuperación de entrada a 4 ciclos. o El puerto AGP se desactiva de forma predeterminada en algunos chipset ALi (ALi1541, ALi1647) para solucionar los problemas graves de estabilidad del sistema con estos chipsets. Consulte los comentarios que aparecen en el archivo os-registry.c sobre NVreg_EnableALiAGP para activar el puerto AGP de todas formas. __________________________________________________________________________ (ap-h) APÉNDICE H: PROBLEMAS ESPECÍFICOS DE TNT __________________________________________________________________________ En principio, es posible resolver la mayoría de los problemas relacionados con las tarjetas SGRAM/SDRAM TNT. Sin embargo, existe la remota posibilidad de que su tarjeta de vídeo tenga instalada una BIOS incorrecta y que este controlador siga dando fallos. Si tiene problemas con este controlador, siga las siguientes instrucciones: o Observe su monitor al iniciar el sistema. La primera pantalla, muy breve, identificará el tipo de memoria de vídeo de su tarjeta, que será SGRAM o SDRAM. o Elimine el archivo "os-registry.c" de las fuentes del módulo kernel. Busque la variable "NVreg_VideoMemoryTypeOverride". Defina el valor de la variable según el tipo de memoria que tenga (numéricamente, observe la línea situada justo encima). o Como no se suele utilizar esta variable, cambie el "#if 0", que se encuentra unas 10 líneas por encima de la variable, por "#if 1". o Vuelva a generar y a instalar el nuevo controlador (utilizando el comando "make") __________________________________________________________________________ (ap-i) APÉNDICE I: CONFIGURACIÓN DE TWINVIEW __________________________________________________________________________ Únicamente admiten la función TwinView las GPU de NVIDIA con soporte para la función de doble monitor, como por ejemplo GeForce2 MX, GeForce2 Go, Quadro2 MXR, Quadro2 Go y cualquiera de las GPU GeForce4, Quadro4, GeForce FX o Quadro FX. Consulte a su fabricante de tarjetas de vídeo si su tarjeta admite la función TwinView. TwinView es un modo de funcionamiento en el que dos dispositivos de visualización (pantallas digitales planas, monitores CRT y televisiones) pueden visualizar el contenido de una única pantalla X en cualquier configuración arbitraria. Este método, que permite utilizar varios monitores a la vez, ofrece una serie de ventajas con respecto a otras técnicas (tales como Xinerama): o Se utiliza una única pantalla X. El controlador oculta a X server toda la información relativa al uso de varios dispositivos de visualización; para X, sólo se está utilizando un monitor. o Ambos dispositivos comparten el mismo búfer de fotogramas. De este modo, todas las funciones presentes en una única pantalla (por ejemplo, aceleración OpenGL) están disponibles en TwinView. o No se necesita ningún dato de control adicional para emular un único escritorio. Si quiere utilizar cada monitor como una pantalla X independiente, consulte el (ap-r) APÉNDICE R: CONFIGURACIÓN DE VARIAS PANTALLAS X EN UNA TARJETA. OPCIONES DE TWINVIEW EN EL ARCHIVO DE CONFIGURACIÓN DE X Para activar TwinView es necesario especificar las siguientes opciones en la sección "Device" del archivo de configuración de X: Option "TwinView" Option "MetaModes" "" También es preciso especificar: Option "SecondMonitorHorizSync" "" Option "SecondMonitorVertRefresh" "" o bien: Option "HorizSync" "" Option "VertRefresh" "" También se pueden utilizar las siguientes opciones, aunque no son necesarias: Option "TwinViewOrientation" "" Option "ConnectedMonitor" "" A continuación, le ofrecemos una descripción detallada de cada opción: o TwinView Esta opción es necesaria para activar TwinView; sin ella, no se pueden activar las demás opciones relacionadas con TwinView. o SecondMonitorHorizSync, SecondMonitorVertRefresh Con estas opciones se pueden especificar las restricciones del segundo monitor. Los valores dados deberían ajustarse a las mismas convenciones que las entradas "HorizSync" y "VertRefresh" de la sección "Monitor". Tal y como figura en el manual de ayuda en línea de XF86Config: los rangos pueden consistir en una lista en la que figuran los distintos valores y/o rangos de valores separados por comas, en la que cada rango viene dado por dos valores diferentes separados por un guión. La opción HorizSync está expresada en kHz, y la opción VertRefresh viene expresada en Hz. Si confía en los datos EDID de su dispositivo de visualización puede utilizar la opción "UseEdidFreqs" en lugar de estas opciones (en el APÉNDICE D encontrará una descripción de la opción "UseEdidFreqs"). o HorizSync, VertRefresh A veces no está claro qué dispositivo de visualización es el "primero" y cuál es el "segundo". Por este motivo, se facilita el uso de estas opciones en lugar de la versión de SecondMonitor. Con ellas, es posible especificar una lista de rangos de frecuencias separados por punto y coma y precedidos (cada uno de ellos) de un nombre de dispositivo de visualización. Por ejemplo: Option "HorizSync" "CRT-0: 50-110, DFP-0: 40-70" Option "VertRefresh" "CRT-0: 60-120, DFP-0: 60" Consulte el Apéndice NOMBRES DE DISPOSITIVOS DE VISUALIZACIÓN para obtener más información. o MetaModes Un único MetaMode indica el modo que se debería utilizar en cada dispositivo de visualización en un momento dado. Varios MetaModes indican las combinaciones de modos y la secuencia en que se deberían utilizar. Cuando el controlador de NVIDIA indica a X los modos disponibles, en realidad lo único que se está comunicando a X es el cuadro delimitador mínimo del Metamode, mientras que el modo "per display device" (por dispositivo de visualización) se mantiene de forma interna en el controlador de NVIDIA. En la sintaxis MetaMode, los modos están separados por comas, y los MetaModes múltiples aparecen separados por punto y coma. Por ejemplo: ", ; , " Donde es el nombre del modo que se debe utilizar en el dispositivo de pantalla 0 simultáneamente con que es el modo utilizado en el dispositivo de pantalla 1. Un cambio de modo hará que pase a utilizarse en el dispositivo de pantalla 0 y que se utilice en el dispositivo de pantalla 1. He aquí una entrada real de MetaMode del archivo de configuración de X de ejemplo: Option "MetaModes" "1280x1024,1280x1024; 1024x768,1024x768" Si quiere que un determinado MetaMode no esté activado en uno de los dispositivos de visualización, puede utilizar el modo "NULL", o simplemente omitir por completo el nombre del modo: "1600x1200, NULL; NULL, 1024x768" o "1600x1200; , 1024x768" Opcionalmente, los nombres de los modos pueden ir seguidos de información sobre el desplazamiento para controlar la posición de los dispositivos de visualización dentro del espacio de pantalla virtual; por ejemplo: "1600x1200 +0+0, 1024x768 +1600+0; ..." Las descripciones sobre desplazamiento siguen las pautas utilizadas en la opción de la línea de comando "-geometry" de X; por ejemplo, tanto los desplazamientos negativos como los positivos son válidos, aunque los desplazamientos negativos sólo están permitidos cuando el archivo de configuración de X indica explícitamente un tamaño de pantalla virtual. Cuando no se indica ningún desplazamiento para un determinado MetaMode, se calculan los desplazamientos siguiendo el valor de la opción TwinViewOrientation (véase más abajo). Tenga en cuenta que si se determinan desplazamientos para cualquiera de los modos de un MetaMode, estos desplazamientos serán válidos para todos los modos de dicho MetaMode; en tal caso, se asumirá que el valor de los desplazamientos es +0+0 cuando no se han especificado. Asimismo, el tamaño de la pantalla virtual se calculará a partir del cuadro delimitador de todos los cuadros delimitadores del MetaMode. Se descartarán los MetaModes que tengan un cuadro delimitador mayor que el tamaño de pantalla virtual especificado. Una cadena MetaMode se puede modificar con una especificación de "Panning Domain"; por ejemplo: "1024x768 @1600x1200, 800x600 @1600x1200" Un panning domain (dominio de panoramización) es el área del dispositivo de visualización que se panoramiza para seguir al ratón. Con TwinView, la panoramización tiene lugar en dos niveles: en primer lugar, el área de visualización de uno de los dispositivos de pantalla se incrementará hasta alcanzar su dominio de panoramización, siempre que dicha área quede dentro del cuadro delimitador del MetaMode. Cuando el ratón salga del cuadro delimitador del MetaMode, el MetaMode completo (es decir, todos los dispositivos de visualización) se incrementarán para seguir al ratón dentro de la pantalla virtual. Tenga en cuenta que, de forma predeterminada, los dominios de panoramización de cada dispositivo de visualización se sitúan en la posición del área de visualización de los dispositivos de visualización; de este modo, las áreas de visualización quedan "bloqueadas" de forma predeterminada y sólo realizan el segundo tipo de panoramización. La principal ventaja de los dominios de panoramización es que eliminan las zonas muertas: partes de la pantalla virtual que son inaccesibles debido a que los dispositivos de visualización tienen resoluciones diferentes. Por ejemplo: "1600x1200, 1024x768" genera una zona inaccesible por debajo de 1024x768. Sin embargo, si se especifica un dominio de panoramización para el segundo dispositivo de pantalla: "1600x1200, 1024x768 @1024x1200" se obtiene acceso a esa zona muerta, lo que le permite ampliar la perspectiva de la vista de 1024x768 por encima y por debajo dentro del dominio de panoramización de 1024x1200. Los desplazamientos se pueden utilizar junto con los dominios de panoramización para posicionar estos dominios en el área de pantalla virtual (hay que tener en cuenta que el desplazamiento describe el dominio de panoramización y que sólo afecta al área de visualización comprendida en el rango de visualización). El siguiente ejemplo describe dos modos, cada uno de ellos con un ancho de panoramización de 1900 píxeles; además, la segunda pantalla está situada por debajo de la primera: "1600x1200 @1900x1200 +0+0, 1024x768 @1900x768 +0+1200" Dado que muchas veces no está claro qué modo de MetaMode se utilizará en cada dispositivo de visualización, es posible anteponer las descripciones del modo dentro de cada MetaMode indicando el nombre de dispositivo de visualización. Por ejemplo: "CRT-0: 1600x1200, DFP-0: 1024x768" Si no se especifica ninguna cadena MetaMode, el controlador X utiliza los modos listados en la subsección "Display" correspondiente, para que los modos de cada pantalla coincidan. o TwinViewOrientation Esta opción controla la posición del segundo dispositivo de visualización en relación con el primero dentro de la pantalla X virtual, cuando los desplazamientos no aparecen explícitamente indicados en los MetaModes. Los posibles valores son: "RightOf" (a la derecha) (valor predeterminado) "LeftOf" (a la izquierda) "Above" (arriba) "Below" (abajo) "Clone" (clónico) Si se elige la opción "Clone", se asignará a cada dispositivo el valor de desplazamiento 0,0. Dado que muchas veces no está claro qué dispositivo es el "primero" y cuál es el "segundo", la opción TwinViewOrientation puede resultar confusa. Es posible aclarar el valor de TwinViewOrientation utilizando nombres de dispositivos de visualización para indicar qué dispositivo está ubicado con determinada posición con respecto a otro dispositivo. Por ejemplo: "CRT-0 LeftOf DFP-0" o ConnectedMonitor Con esta opción es posible modificar qué elementos detecta el módulo kernel de NVIDIA como conectados a la tarjeta de vídeo. Esto puede resultar útil, por ejemplo, si alguno de los dispositivos de visualización no admite la detección mediante los protocolos DDC (Canal de Visualización de Datos). Los valores admitidos son una lista de dispositivos de visualización separados por coma. Por ejemplo: "CRT-0, CRT-1" "CRT" "CRT-1, DFP-0" ADVERTENCIA: Esta opción determina los dispositivos que detecta el módulo kernel de NVIDIA y se necesita raras veces. Realmente sólo es útil si no se detecta un determinado dispositivo de visualización porque no proporciona información DDC o porque está al otro lado de un conmutador de KVM (Teclado-Vídeo-Ratón). En la mayoría de los casos es mejor no especificarla. Al igual que en todas las entradas del archivo de configuración de X, no se tienen en cuenta los espacios y no se hace distinción entre mayúsculas y minúsculas. PREGUNTAS MÁS FRECUENTES (FAQ) ACERCA DE TWINVIEW: P: No se visualiza nada en el segundo monitor; ¿cuál puede ser el problema? R: Los monitores que no admiten la detección de monitor mediante los protocolos DDC (la mayoría de los monitores antiguos no la admiten) no pueden ser detectados por la tarjeta NVIDIA. Por lo tanto, es necesario indicar explícitamente al controlador X de NVIDIA los elementos que se han conectado, utilizando la opción "ConnectedMonitor"; por ejemplo: Option "ConnectedMonitor" "CRT, CRT" P: ¿Podrá el administrador de ventanas situarlas del modo adecuado (por ejemplo, evitando que las ventanas queden situadas entre ambos dispositivos de visualización o en zonas inaccesibles del escritorio virtual)? R: Sí. El controlador X de NVIDIA proporciona una extensión Xinerama que los clientes X (como son los administradores de ventanas) pueden usar para averiguar la configuración actual de TwinView. Tenga en cuenta que el protocolo Xinerama no proporciona ningún modo de comunicar a los clientes cuándo tiene lugar un cambio de configuración. Por lo tanto si cambia a un MetaMode diferente, el administrador de ventanas seguirá creyendo que tiene la configuración previa. Sin embargo, al utilizar la extensión Xinerama, junto con la extensión XF86VidMode para obtener los eventos de cambio de modo, los administradores de ventanas podrán determinar la configuración de TwinView en cualquier momento. Lamentablemente, los datos suministrados por XineramaQueryScreens() parecen confundir a algunos administradores de ventanas. Para resolver el problema, puede desactivar la comunicación de la distribución de pantalla de TwinView con la opción "NoTwinViewXineramaInfo" del archivo de configuración de X (consulte el Apéndice D para ampliar la información). Tenga presente que el controlador NVIDIA no proporciona la extensión Xinerama si se está utilizando la propia extensión Xinerama de X server. La especificación expresa de Xinerama en el archivo de configuración de X o en la línea de comandos de X server impedirá que se instale la extensión Xinerama de NVIDIA, por tanto, asegúrese de que el archivo de registro de de X server no contenga: (++) Xinerama: enabled si quiere que el controlador NVIDIA proporcione la extensión Xinerama mientras utiliza la función TwinView. Otra solución es utilizar dominios de panoramización para eliminar las zonas inaccesibles de la pantalla virtual (consulte la descripción de MetaMode ofrecida anteriormente). Una tercera solución es utilizar dos pantallas X independientes en lugar de TwinView. Consulte el (ap-r) APÉNDICE R: CONFIGURACIÓN DE VARIAS PANTALLAS X EN UNA TARJETA. P: ¿Por qué no puedo disponer de una resolución de 1600x1200 en el segundo dispositivo de visualización cuando utilizo una GeForce2 MX? R: Porque, en GeForce2 MX, el segundo dispositivo de visualización ha sido diseñado para ser una pantalla plana digital y, por lo tanto, el reloj de píxel del segundo dispositivo es sólo de 150 MHz. Esto limita la resolución del segundo dispositivo de pantalla a cerca de 1280x1024 (si desea más información sobre cómo limitan las frecuencias del reloj de píxel los modos programables, consulte XFree86 Video Timings HOWTO). Esta limitación no está presente en los procesadores GeForce4 y GeForce FX, donde la frecuencia de reloj para el procesamiento de píxeles es igual en ambos monitores. P: ¿Funciona la característica de superposición de vídeo en los dos dispositivos de pantalla? R: La superposición de vídeo por hardware sólo funciona en el primer dispositivo de visualización. La solución consiste en utilizar la opción blitted video en lugar de TwinView. P: ¿Cómo se determinan las dimensiones de la pantalla virtual en TwinView? R: Después de validar los modos solicitados, y de calcular los valores de desplazamiento para cada área de visualización de los MetaMode, el controlador de NVIDIA calcula el cuadro delimitador del dominio de panoramización para cada MetaMode. A continuación se calcula el alto y el ancho del cuadro delimitador. Como resultado, es posible que la anchura virtual y la altura virtual procedan de MetaModes diferentes. Por ejemplo, en la siguiente cadena MetaMode: "1600x1200,NULL; 1024x768+0+0, 1024x768+0+768" el tamaño de la pantalla virtual resultante será de 1600 x 1536. P: ¿Se pueden ejecutar juegos en pantalla completa en ambos dispositivos de visualización? R: Sí. Aunque la configuración puede variar de un juego a otro, la idea básica es que MetaMode presente X en un modo cuya resolución sea el cuadro delimitador del área de visualización correspondiente a dicho MetaMode. Los siguientes ejemplos: Option "MetaModes" "1024x768,1024x768; 800x600,800x600" Option "TwinViewOrientation" "RightOf" producen dos modos: uno cuya resolución es 2048x768, y otro cuya resolución es 1600x600. Determinados juegos como Quake 3 Arena utilizan la extensión VidMode para descubrir las resoluciones de los modos disponibles. Para configurar Quake 3 Arena para que utilice la cadena MetaMode anterior, añada lo siguiente al archivo q3config.cfg: seta r_customaspect "1" seta r_customheight "600" seta r_customwidth "1600" seta r_fullscreen "1" seta r_mode "-1" Tenga en cuenta que, dada la configuración anterior, no existe ningún modo con una resolución de 800x600 (recuerde que el MetaMode "800x600, 800x600" tiene una resolución de 1600x600"); de este modo, si cambia Quake 3 Arena para utilizar una resolución de 800x600, se visualizará en la esquina inferior izquierda de la pantalla, y el resto de la pantalla aparecerá en gris. Para poder disponer también del modo single head, la cadena MetaMode debería ser algo como: "800x600,800x600; 1024x768,NULL; 800x600,NULL; 640x480,NULL" Este documento no puede ofrecer información más precisa sobre la configuración de juegos concretos, pero los ejemplos anteriores, junto con los numerosos recursos en línea existentes deberían indicarle la dirección correcta. __________________________________________________________________________ (ap-j) APÉNDICE J: CONFIGURACIÓN DE LA SALIDA DE TV __________________________________________________________________________ Las tarjetas de vídeo basadas en GPU de NVIDIA que cuentan con un conector de salida de TV (S-Video) se pueden emplear para utilizar un televisor como dispositivo de visualización, como si se tratara de un monitor CRT o una pantalla plana digital. El televisor se puede utilizar sólo o (con la tarjeta de vídeo adecuada) junto con otro dispositivo de visualización en una configuración TwinView. Si el único dispositivo de visualización conectado a la tarjeta de vídeo es un televisor, el sistema lo utilizará como monitor principal al iniciar el equipo (es decir la consola aparecerá en el televisor como si fuera un monitor CRT). Para utilizar el televisor con X, es necesario prestar especial atención a algunos parámetros del archivo de configuración de X: o Los valores VertRefresh y HorizSync de la sección "Monitor"; asegúrese de que estos valores sean adecuados para su televisor. Por lo general, estos valores suelen ser: HorizSync 30-50 VertRefresh 60 o Los modos de la sección "Screen"; los modos válidos para el codificador de TV se indican en un archivo de registro de X detallado (generado con `startx -- -logverbose 5`) cuando se ejecuta X con un televisor. Algunos modos pueden estar limitados a ciertos estándares de TV. Si es éste el caso, aparecerá indicado así en el archivo de registro de X. Generalmente se admiten como mínimo los modos 800x600 y 640x480. o Es necesario añadir la opción "TVStandard" a la sección "Screen"; los valores válidos son los siguientes: "PAL-B" : utilizado en Bélgica, Dinamarca, Finlandia, Alemania, Guinea, Hong Kong, India, Indonesia, Italia, Malasia, Países Bajos, Noruega, Portugal, Singapur, España, Suecia y Suiza "PAL-D" : utilizado en China y Corea del Norte "PAL-G" : utilizado en Dinamarca, Finlandia, Alemania, Italia, Malasia, Países Bajos, Noruega, Portugal, España, Suecia y Suiza "PAL-H" : utilizado en Bélgica "PAL-I" : utilizado en Hong Kong y Reino Unido "PAL-I" : utilizado en Guinea "PAL-M" : utilizado en Brasil "PAL-N" : utilizado en Francia, Paraguay y Uruguay "PAL-I" : utilizado en Argentina "NTSC-J" : utilizado en Japón "NTSC-M" : utilizado en Canadá, Chile, Colombia, Costa Rica, Ecuador, Haití, Honduras, México, Panamá, Puerto Rico, Corea del Sur, Taiwán, Estados Unidos y Venezuela "HD480i" : Entrelazado, 480 líneas "HD480p" : Progresiva, 480 líneas "HD720p" : Progresiva, 720 líneas "HD1080i": Entrelazado, 1080 líneas "HD1080p": Progresiva, 1080 líneas "HD576i" : Entrelazado, 576 líneas "HD576p" : Progresiva, 576 líneas La línea del archivo de configuración de X debería ser parecida a la siguiente: Option "TVStandard" "NTSC-M" Si no se especifica un estándar de televisión o se especifica un valor inválido, se utilizará como estándar predeterminado "NTSC-M". Nota: si su país no aparece en la lista anterior, seleccione el país más cercano al suyo. o La opción "ConnectedMonitor" se puede utilizar para indicar a X que utilice el televisor como pantalla. Esto sólo será necesario si su tarjeta de vídeo no detecta el televisor o si utiliza un monitor CRT (o una pantalla plana digital) como monitor principal, pero quiere redirigir a X para utilizar el televisor. La línea del archivo de configuración debería ser: Option "ConnectedMonitor" "TV" o La opción "TVOutFormat" se puede utilizar para forzar la salida SVIDEO o COMPOSITE. Sin esta opción, el controlador detecta de forma automática el formato de salida. Desafortunadamente, esta operación no siempre se realiza correctamente. El formato de salida se puede forzar con las siguientes opciones: Option "TVOutFormat" "SVIDEO" o Option "TVOutFormat" "COMPOSITE" o La opción "TVOverScan" se utiliza para activar la corrección de la imagen para salida a TV (Overscan) allí donde sea posible usar esta función. Los valores admitidos pueden estar entre 1.0 (efectúa la máxima corrección: hace la imagen tan grande como sea posible) y 0.0 (desactiva la corrección: hace la imagen tan pequeña como sea posible). Esta función está desactivada (0.0) de forma predeterminada. Actualmente la opción Overscan sólo está disponible en todas las GPU a partir de GeForce4 con codificadores de TV NVIDIA o Conexant. Si la consola es un televisor, es posible que el controlador X de NVIDIA no la restaure correctamente con versiones de XFree86 anteriores a la 4.3. Esto es debido a incompatibilidades binarias entre los módulos int10. Si se utiliza un televisor como consola, recomendamos actualizar a XFree86 4.3 o posterior. __________________________________________________________________________ (ap-k) APÉNDICE K: CONFIGURACIÓN DE UN PORTÁTIL __________________________________________________________________________ INSTALACIÓN Y CONFIGURACIÓN La instalación y configuración del juego de controladores NVIDIA para Linux en un portátil es la misma que para cualquier equipo fijo, salvo por algunas pequeñas diferencias que se indican a continuación. A partir de la versión 1.0-2802, la información sobre la pantalla del portátil que se utiliza al inicializar la visualización se genera a partir de los datos almacenados en la BIOS del sistema de vídeo. Esto se puede desactivar configurando la opción "SoftEDIDs" del kernel con el valor 0. Si "SoftEDIDs" se desactiva, los datos se obtendrán de una tabla codificada en el sistema y se basarán en el valor de la opción "Mobile" del kernel. La opción "Mobile" puede configurarse con cualquiera de los valores siguientes: 0xFFFFFFFF : deja que el módolo kernel detecte automáticamente el valor 1 : portátiles Dell 2 : portátiles Toshiba no fabricados por Compal 3 : otros portátiles 4 : portátiles Toshiba fabricados por Compal 5 : portátiles Gateway De nuevo, la opción "Mobile" sólo es necesaria si la opción SoftEDIDs está desactivada. Cuando se utiliza, suele ser más seguro dejar que el módulo kernel detecte automáticamente el valor adecuado (es la configuración predeterminada). Si necesita modificar alguna de estas opciones, puede hacerlo mediante uno de estos procedimientos: o Modificando os-registry.c en el directorio usr/src/nv/ del archivo .run. o Configurando el valor en la línea de comandos de modprobe (p. ej.: `modprobe nvidia NVreg_SoftEDIDs=0 NVreg_Mobile=3`) o Añadiendo una línea "options" al archivo de configuración del módulo, normalmente /etc/modules.conf (p. ej.: "options nvidia NVreg_Mobile=5") FUNCIONES ADICIONALES TWINVIEW Todos los procesadores NVIDIA para portátiles incorporan TwinView. La función TwinView se configura en un portátil de la misma forma que en un equipo de sobremesa (consulte el APÉNDICE I); tenga en cuenta que en una configuración de TwinView donde se utiliza la pantalla plana interna del portátil y un CRT externo, este último es el monitor principal (especifique HorizSync y VertRefresh en la sección de monitor del archivo de configuración de X) y la pantalla plana es el secundario (especifique HorizSync y VertRefresh a través de las opciones SecondMonitorHorizSync y SecondMonitorVertRefresh). También puede utilizar la opción UseEdidFreqs para obtener los valores HorizSync y VertRefresh del EDID de cada monitor y no preocuparse por definirlas en el archivo de configuración de X (sólo en caso de que confíe en los informes EDID generados sobre el monitor. Consulte la descripción de la opción UseEdidFreqs incluida en el APÉNDICE D para obtener más detalles). CAMBIO DE MONITORES CON TECLA RÁPIDA Además de la función TwinView, los portátiles con procesadores NVIDIA para portátiles admiten un evento de tecla rápida para cambio de monitores LCD/CRT, con lo que puede cambiar entre cada uno de los monitores conectados y cada posible combinación de los mismos (tenga en cuenta que sólo pueden estar activos 2 monitores al mismo tiempo). La función TwinView configurada en el archivo de configuración de X y la función de tecla rápida son mutuamente excluyentes, es decir, si activa TwinView en el archivo de configuración, el controlador X de NVIDIA no tendrá en cuenta los eventos de tecla rápida de LCD/CRT. Otro aspecto importante de la función de tecla rápida es que el usuario puede conectarse de forma dinámica y eliminar monitores a/desde el portátil y utilizar la tecla rápida sin necesidad de reiniciar X. Con todo esto, surge la duda sobre cómo validar y determinar los modos que se deben programar en cada dispositivo de visualización. En primer lugar, es bastante práctico utilizar la opción UseEdidFreqs para recuperar de los EDID del monitor los valores de sincronización horizontal y actualización vertical de cada uno de ellos; de lo contrario, la semántica del contenido de la sección del monitor varía constantemente con cada evento de tecla rápida. Cuando se inicia X, o cuando se detecta un cambio en la lista de monitores conectados, se crea una nueva lista de secuencias de tecla rápida que contiene los monitores que se utilizarán con cada evento de tecla rápida. Cuando se produce uno de estos eventos, se elige el siguiente estado de tecla rápida de la secuencia. Cada modo solicitado en el archivo de configuración de X se valida con cada requisito del monitor, y los modos resultantes son los disponibles para ese monitor. Si hay varios monitores activos a la vez, los modos de cada uno se cotejan; si no se puede encontrar un ajuste exacto (misma resolución), se localiza el ajuste más aproximado y el monitor con la resolución más pequeña se adapta a la resolución del otro monitor. Cuando se realiza una conexión VT fuera de X, la consola VGA siempre se restablecerá en el monitor en el que estaba cuando se inició X. De igual forma, cuando se devuelve la conexión VT a X, se utilizará la misma configuración del monitor que cuando se realizó la conexión fuera de X, independientemente de si la actividad de tecla rápida LCD/CRT ocurrió durante este último momento. MODOS NO ESTÁNDAR EN PANTALLAS LCD Algunos usuarios han encontrado dificultades a la hora de programar un modo 1.400x1.050 (la resolución original de algunas pantallas LCD de portátil). En la versión 4.0.3, XFree86 añadió varios modos 1.400x1.050 a la base de datos de modos predeterminados, pero si se utiliza una versión anterior de XFree86, se puede emplear esta línea de modos: # -- 1400x1050 -- # 1400x1050 @ 60Hz, 65.8 kHz hsync Modeline "1400x1050" 129 1400 1464 1656 1960 1050 1051 1054 1100 +HSync +VSync PROBLEMAS COMUNES EN LOS PORTÁTILES o El cambio LCD/CRT con tecla rápida actualmente no funciona en los portátiles Toshiba, con la excepción de los Toshiba Satellite Serie 3000. o La función TwinView no está disponible actualmente en portátiles Toshiba de la serie Satellite 2800. o La superposición de vídeo sólo funciona en el primer monitor en el que se ha iniciado X. Por ejemplo, si inicia X en la pantalla LCD interna, ejecuta una aplicación de vídeo que utiliza la superposición (emplea el adaptador "Video Overlay" anunciado a través de la extensión XV) y, a continuación, utiliza la tecla rápida para añadir un segundo monitor, el vídeo no aparecerá en este segundo monitor. Para solucionar esto, puede configurar la aplicación de vídeo para utilizar el adaptador "Video Blitter" anunciado a través de la extensión XV (siempre disponible) o cambiar con la tecla rápida al monitor en el que va a utilizar la superposición de vídeo *antes* de iniciar X. __________________________________________________________________________ (ap-l) APÉNDICE L: MODOS DE PROGRAMACIÓN __________________________________________________________________________ El juego de controladores acelerados para Linux de NVIDIA es compatible con todos los modos VGA y VESA estándar, así como con la mayoría de las líneas de modos personalizadas; los modos doble-scan son compatibles con todo el hardware. Los modos de entrelazado se admiten en todas las GPU GeForce FX/Quadro FX y las GPU más recientes, así como en ciertos modelos de GPU antiguas. Si la GPU admite los modos de entrelazado, el archivo de registro de X lo indicará con el mensaje "Interlaced video modes are supported on this GPU". En general, su dispositivo de visualización (monitor/pantalla plana/televisión) presentará más requisitos sobre los modos que puede utilizar que la tarjeta de vídeo con tecnología NVIDIA GPU o el juego de controladores de NVIDIA para Linux. Para solicitar uno o varios modos estándar para utilizar en X, sencillamente puede añadir una línea de modos como: Modes "1600x1200" "1024x768" "640x480" en la subsección apropiada de pantalla del archivo de configuración de X (consulte el manual de ayuda en línea de XF86Config(5x) o xorg.conf (5x) para obtener más información). La siguiente documentación es interesante sobre todo si el usuario crea sus propias líneas de modos personalizadas, experimenta con xvidtune(1) o simplemente está interesado en aprender más. Tenga en cuenta que no se trata de una explicación ni una guía sobre el arte de elaborar líneas de modos personalizadas para X. Eso lo dejamos para documentos como XFree86 Video Timings HOWTO (que puede encontrar en www.tldp.org). PROFUNDIDAD, BITS POR PÍXEL Y PITCH Si bien no se trata de una cuestión grave cuando se programan modos, los bits empleados por píxel se convierten en un problema a la hora de considerar la máxima resolución programable; por esta razón, merece la pena aclarar la confusión existente en torno los términos "profundidad" y "bits por píxel". La profundidad se refiere a la cantidad de bits de datos almacenados por píxel. Las profundidades utilizadas son 8, 15, 16 y 24. Sin embargo, la mayor parte del hardware de vídeo almacena datos de píxel en tamaños de 8, 16 o 32 bits; esta es la cantidad de memoria asignada por píxel. Cuando se especifica una profundidad, X selecciona el tamaño de los bits por píxel (bpp) en el que se almacenan los datos. A continuación, se muestra una tabla de los bpp que se utilizan para cada profundidad: profundidad bpp ===== ===== 8 8 15 16 16 16 24 32 Por último, el "pitch" se refiere a la cantidad de bytes del búfer de fotogramas lineales existente entre los datos de un píxel y los datos del píxel situado inmediatamente debajo. Se puede decir que equivale a la resolución horizontal multiplicada por los bytes por píxel (bits por píxel dividido entre 8). En la práctica, el pitch puede ser algo más que el producto de esta multiplicación debido a algunas restricciones de alineación. RESOLUCIONES MÁXIMAS El juego de controladores acelerados para Linux de NVIDIA y las tarjetas de vídeo con tecnología NVIDIA GPU admiten resoluciones máximas de 2048x1536, aunque la resolución máxima que un sistema puede admitir está también limitada por la cantidad de memoria de vídeo (consulte el apartado FÓRMULAS PRÁCTICAS para obtener más detalles) y la resolución máxima admitida del dispositivo de visualización (monitor/pantalla plana/televisión). Además, tenga en cuenta que aunque el uso de la superposición de vídeo no limita la resolución máxima ni la velocidad de actualización, el ancho de banda de la memoria de vídeo empleado en un modo programado influye en la calidad de la superposición. FÓRMULAS PRÁCTICAS La resolución máxima es una función dependiente de la cantidad de memoria de vídeo y los bits por píxel que decida utilizar: HR * VR * (bpp/8) = memoria de vídeo utilizada Dicho de otro modo, la cantidad de memoria de vídeo utilizada es igual a la resolución horizontal (HR) multiplicada por la resolución vertical (VR) multiplicada por los bytes por píxel (bits por píxel dividido entre ocho). Desde el punto de vista técnico, la memoria de vídeo utilizada es en realidad el pitch multiplicado por la resolución vertical, y el pitch puede ser ligeramente mayor que (HR * (bpp/8)) para satisfacer el requisito del hardware de que el pitch sea múltiplo de algún valor. Tenga en cuenta que esto es sólo el uso de la memoria para el búfer de fotogramas; la memoria de vídeo se emplea también para otras cosas, como OpenGL o la memoria caché de pixmap. Otra relación importante es aquella entre la resolución, el reloj de píxel (también conocido como reloj de puntos) y la velocidad de actualización vertical: RR = PCLK / (HFL * VFL) Dicho de otro modo, la velocidad de actualización (RR) es igual al reloj de píxel (PCLK) dividido entre el número total de píxeles: la longitud de fotograma horizontal (HFL) multiplicada por la longitud de fotograma vertical (VFL). (Tenga en cuenta que se trata de las longitudes de fotograma, no sólo de las resoluciones visibles). Según se describe en XFree86 Video Timings HOWTO, la fórmula anterior es equivalente a esta otra: PCLK = RR * HFL * VFL Dado un reloj de píxel máximo, se puede ajustar RR, HFL y VFL según convenga, siempre que el resultado de los tres sea coherente. En el archivo de registro se genera un informe sobre el reloj de píxel cuando se ejecuta X en un lenguaje de registro elaborado: `startx -- -logverbose 5`. El archivo de registro de X debe contener varias líneas como: (--) NVIDIA(0): Display Device 0: maximum pixel clock at 8 bpp: 350 MHz (--) NVIDIA(0): Display Device 0: maximum pixel clock at 16 bpp: 350 MHz (--) NVIDIA(0): Display Device 0: maximum pixel clock at 32 bpp: 300 MHz lo que indica el reloj de píxel máximo en cada tamaño de bit por píxel. VALIDACIÓN DE MODOS Durante la fase PreInit de X server, el controlador X de NVIDIA valida todos los modos solicitados de la siguiente manera: o Toma la intersección de los rangos de HorizSync y VertRefresh proporcionados por el usuario en el archivo de configuración de X con los rangos generados por el monitor en el EDID (datos extendidos de identificación de la pantalla); esta acción se puede desactivar mediante la opción "IgnoreEDID", en cuyo caso el controlador X aceptará sin más los rangos de HorizSync y VertRefresh introducidos por el usuario. o Solicita la función del asistente xf86ValidateModes() para localizar modos con los nombres que el usuario ha especificado en el archivo de configuración de X, descartando modos con frecuencias de sincronización horizontal o velocidades de actualización vertical no válidas, relojes de píxel mayores que el reloj de píxel máximo para la tarjeta de vídeo o resoluciones superiores al tamaño de la pantalla virtual (si se ha especificado un tamaño de pantalla virtual en el archivo de configuración de X). Existen otras validaciones aplicables. Consulte xc/programs/Xserver/hw/xfree86/common/xf86Mode.c:xf86ValidateModes(). o Todos los modos devueltos de xf86ValidateModes() se examinan para asegurar que sus resoluciones no son superiores al modo de resolución mayor generado por el EDID del monitor (esto se puede desactivar con la opción "IgnoreEDID". Si se trata de una pantalla de televisión, se comprueba cada modo para verificar que tiene una resolución compatible con la codificación de TV (generalmente el codificador sólo admite resoluciones de 800x600 y 640x480). o Todos los modos se comprueban para verificar que se ajustan a las limitaciones de ancho de banda de memoria del hardware. Esta prueba puede desactivarse con la opción NoBandWidthTest del archivo de configuración de X. o Todos los modos restantes se revisan para garantizar que superan los requisitos descritos más adelante en REQUISITOS ADICIONALES DE MODOS. Los últimos tres pasos se realizan también cuando se programa cada modo para conocer los posibles modos no válidos enviados por XF86VidModeExtension (xvidtune(1)). Respecto de la función TwinView, la validación antes mencionada se realiza en los modos solicitados para cada monitor. REQUISITOS ADICIONALES DE MODOS A continuación, se muestra una lista de requisitos adicionales que deben cumplir ciertos parámetros de los modos. En algunos casos, son específicos de determinados procesadores. o La resolución horizontal (HR) debe ser múltiplo de 8 e inferior o igual al valor especificado en la tabla siguiente. o El ancho de blanqueo horizontal (el máximo de longitud de fotograma horizontal y el final de sincronización horizontal menos el mínimo de resolución horizontal y el inicio de sincronización horizontal (máx(HFL,HSE) - mín(HR,HSS)) debe ser múltiplo de 8 e inferior o igual al valor especificado en la tabla siguiente. o El inicio de sincronización horizontal (HSS) debe ser múltiplo de 8 e inferior o igual al valor especificado en la tabla siguiente. o El ancho de sincronización horizontal (el final de sincronización horizontal menos el inicio de sincronización horizontal (HSE - HSS)) debe ser múltiplo de 8 e inferior o igual al valor especificado en la tabla siguiente. o La longitud de fotograma horizontal (HFL) debe ser múltiplo de 8, superior o igual a 40, e inferior o igual al valor especificado en la tabla siguiente. o La resolución vertical (VR) debe ser inferior o igual al valor especificado en la tabla siguiente. o El ancho de blanqueo vertical (el máximo de longitud de fotograma vertical y el final de sincronización vertical menos el mínimo de resolución vertical y el inicio de sincronización vertical (máx(VFL,VSE) - mín(VR,VSS)) debe ser inferior o igual al valor especificado en la tabla siguiente. o El inicio de sincronización vertical (VSS) debe ser inferior o igual al valor especificado en la tabla siguiente. o El ancho de sincronización vertical (el final de sincronización vertical menos el inicio de sincronización vertical(VSE - VSS)) debe ser inferior o igual al valor especificado en la tabla siguiente. o La longitud de fotograma vertical (VFL) debe ser superior o igual a 2, e inferior o igual al valor especificado en la tabla siguiente. Valores máximos de DAC ---------------------- | GeForce/TNT Geforce2 y 3 Geforce4 o posteriores ______|____________________________________________________ | HR | 4096 4096 8192 HBW | 1016 1016 2040 HSS | 4088 4088 8224 HSW | 256 256 512 HFL | 4128 4128 8224 VR | 2048 4096 8192 VBW | 128 128 256 VSS | 2047 4095 8192 VSW | 16 16 16 VFL | 2049 4097 8192 He aquí un ejemplo de línea de modo donde se muestra el uso de cada abreviatura utilizada anteriormente: # Línea de modo personalizada para la pantalla plana SGI 1600SW # name PCLK HR HSS HSE HFL VR VSS VSE VFL Modeline "sgi1600x1024" 106.9 1600 1632 1656 1672 1024 1027 1030 1067 FORMA DE COMPROBAR SI LOS TIEMPOS DE LOS MODOS SON IDÉNTICOS Algunas funciones como Active Stereo en TwinView necesitan controlar con exactitud qué tiempos utilizan los modos. Hay varias formas de conseguirlo: o Si únicamente se quiere verificar que las dos pantallas utilizan los mismos modos, basta ver si ambas tienen los mismos valores en HorizSync y VertRefresh al realizar la validación de modos. Esto puede hacerse viendo primero si coinciden HorizSync y SecondMonitorHorizSync y, a continuación, si coinciden VertRefresh y SecondMonitorVertRefresh. o Existe un modo más explícito que consiste en especificar la línea de modo (modeline) que se quiere utilizar (usando uno de los generadores de líneas de modo disponibles) y asignar un nombre exclusivo. Por ejemplo, si quisiera utilizar 1024 x 768 a 120 Hz en cada monitor con la función TwinView y visión estereoscópica activa, debería añadir algo como: # 1024x768 @ 120.00 Hz (GTF) hsync: 98.76 kHz; pclk: 139.05 MHz Modeline "1024x768_120" 139.05 1024 1104 1216 1408 768 769 772 823 -HSync +Vsync En la sección monitor del archivo de configuración X y luego en la sección Screen de ese mismo archivo, especifique un MetaMode como éste: Option "MetaModes" "1024x768_120, 1024x768_120" VÉASE TAMBIÉN: Un generador de líneas de modos XFree86, que se ajusta a la norma GTF, está disponible en la siguiente dirección: http://gtf.sourceforge.net/ Para localizar otros generadores de líneas de modo, realice una búsqueda por "modeline" en freshmeat.net. __________________________________________________________________________ (ap-m) APÉNDICE M: FLIPPING Y UBB __________________________________________________________________________ El juego de controladores acelerados para Linux de NVIDIA incorpora las funciones UBB (Unified Back Buffer) y OpenGL Flipping. Estas funciones ofrecen mejoras del rendimiento en determinadas situaciones. o Unified Back Buffer (UBB): UBB está disponible sólo en Quadro y se activa por defecto cuando hay suficiente espacio de memoria de vídeo. Se puede desactivar con la opción UBB del archivo de configuración X descrita en el Apéndice D. Cuando se activa la función UBB, todas las ventanas comparten el mismo búfer de fondo, stencil y de profundidad. Cuando hay muchas ventanas, el uso del búfer de fondo, stencil y de profundidad nunca excede el tamaño del utilizado por una ventana de pantalla completa. No obstante, incluso para una ventana pequeña el uso de memoria de vídeo con el búfer de fondo, stencil y de profundidad equivale al de una ventana de pantalla completa, de forma que, en ese caso, la memoria de vídeo se puede emplear de forma menos eficaz que en caso de no tener la función UBB. o Flipping: Cuando esta función se activa, OpenGL puede realizar el intercambio de búfers cambiando el búfer que el convertidor DAC explora en vez de copiar el contenido del búfer de fondo en el búfer frontal; en general, este mecanismo proporciona un mayor rendimiento y permite un intercambio sin problemas durante el barrido vertical (cuando se define __GL_SYNC_TO_VBLANK). Las condiciones en las que OpenGL puede realizar el intercambio son algo complicadas pero, en general, es posible hacerlo en unidades GeForce o más modernas cuando se está ejecutando una sola aplicación OpenGL en primer plano y en pantalla completa, y está activada la variable __GL_SYNC_TO_VBLANK. También puede realizar el intercambio en unidades Quadro incluso aunque la ventana OpenGL esté parcialmente oculta, no se ejecute en pantalla completa o no esté activada __GL_SYNC_TO_VBLANK. __________________________________________________________________________ (ap-n) APÉNDICE N: PROBLEMAS CONOCIDOS __________________________________________________________________________ Los problemas expuestos a continuación aún existen en esta versión y están en proceso de resolución. o OpenGL + Xinerama En la actualidad, OpenGL sólo presenta imágenes en el primer monitor cuando funciona en un entorno Xinerama. o OpenGL y dlopen() Hay algunos problemas con versiones anteriores del cargador dinámico glibc (por ej. la versión distribuida con RedHat 7.2) y aplicaciones como Quake3 y Radiant, que utilizan dlopen(). Consulte el capítulo PREGUNTAS MÁS FRECUENTES si precisa más información. o DPMS y TwinView Los modos DPMS "suspend" y "standby" no funcionan correctamente en un segundo monitor CRT cuando se utiliza la función TwinView. La pantalla pierde la imagen en lugar de obtener el estado DPMS solicitado. o DPMS y pantalla plana Los modos DPMS "suspend" y "standby" no funcionan correctamente en una pantalla plana. La pantalla pierde la imagen en lugar de obtener el estado DPMS solicitado. o Varias tarjetas, varios monitores En algunos casos, el módulo kernel de NVIDIA no inicia la tarjeta secundaria correctamente. Para solucionar este problema, active el módulo Int10 de XFree86 para iniciar todas las tarjetas secundarias. Consulte el "APÉNDICE D: OPCIONES DEL ARCHIVO DE CONFIGURACIÓN DE X" para obtener más detalles. o Portátil Si utiliza un portátil, consulte la sección "Problemas comunes en los portátiles" del APÉNDICE D. o FSAA Cuando está activada la función FSAA (la variable de entorno __GL_FSAA_MODE tiene un valor que activa FSAA y se selecciona modo multimuestreo), el renderizado puede fallar si se redimensiona la ventana. o Interacción con pthreads Las aplicaciones monohilo (single threaded) que abren la librería libGL de NVIDIA con dlopen() y luego vuelven a usar dlopen() para abrir cualquier otra librería vinculada a pthreads se bloquean en la librería libGL de NVIDIA. Esto no ocurre con las nuevas librerías ELF TLS OpenGL (consulte el (ap-c) APÉNDICE C: COMPONENTES INSTALADOS, para ver la descripción de las librerías ELF TLS de OpenGL). Hay varias alternativas para resolver el problema: 1) Cargar la librería vinculada a pthreads antes de cargar libGL.so. 2) Vincular la aplicación a pthreads. PROBLEMAS CON EL HARDWARE En esta sección se describen problemas que no tienen solución. Por lo general, el origen del problema está fuera del alcance de NVIDIA. Esta es una lista de dichos problemas: o Placa base Gigabyte GA-6BX Esta placa base utiliza un regulador LinFinity en la ranura de 3,3 V con una corriente de tan sólo 5 A, menos que la especificación AGP, que exige 6 A. Cuando se ejecutan diagnósticos o aplicaciones, la temperatura del regulador aumenta, lo que provoca que el voltaje del chip NVIDIA disminuya hasta 2,2 V. En estas circunstancias, el regulador no puede suministrar la corriente de 3,3 V que el chip NVIDIA necesita. Este problema no sucede cuando la tarjeta gráfica tiene un regulador de corriente o cuando se conecta una fuente de alimentación externa a la ranura de 3,3 V. o Chipsets VIA KX133 y 694X con AGP 2x En las placas base Athlon con el chipset VIA KX133 o 694X, como la ASUS K7V, los controladores NVIDIA se presentan con el modo predeterminado AGP 2x para solucionar la falta de fuerza de una de las señales de control. o Chipsets Irongate con AGP 1x Las transferencias AGP 1x se utilizan en las placas base Athlon con el chipset Irongate para solucionar un problema con la integridad de la señal del chipset. o Chipset Ali: ALi1541 y ALi1647 En los chipsets ALi1541 y ALi1647, los controladores NVIDIA desactivan AGP para solucionar problemas de control e integridad de la señal de reloj. Consulte el "APÉNDICE G: PROBLEMAS ESPECÍFICOS DE ALI" para obtener más información sobre los chipsets ALi. o E/S de APIC (SMP) Si experimenta problemas de estabilidad en una máquina Linux con SMP y recibe mensajes de aviso relativos a la E/S de APIC del kernel de Linux, puede mejorar considerablemente la fiabilidad del sistema activando el parámetro "noapic" del kernel. o APIC local (UP) En algunos sistemas, activar la opción de configuración "Local APIC Support on Uniprocessors" del kernel puede repercutir negativamente en la estabilidad y el rendimiento del sistema. Si detecta bloqueos en una máquina Linux UP y esta opción está activada, pruebe a desactivar el soporte de APIC local. __________________________________________________________________________ (ap-o) APÉNDICE O: INTERFAZ PROC __________________________________________________________________________ La interfaz del sistema de archivos /proc proporciona información de ejecución útil sobre el controlador, las tarjetas gráficas NVIDIA instaladas y el estado de AGP. Esta información se almacena en diferentes archivos del directorio /proc/driver/nvidia: o /proc/driver/nvidia/version Indica la revisión del controlador instalado y la versión del compilador GNU de C utilizado para generar el módulo kernel de kernel. o /proc/driver/nvidia/cards/0...3 Proporciona información sobre todos los adaptadores gráficos de gráficos NVIDIA instalados (modelo, IRQ, versión de la BIOS, tipo de bus). Tenga presente que la versión de la BIOS sólo está disponible mientras se está ejecutando X. o /proc/driver/nvidia/agp/card Información sobre la capacidad de la tarjeta AGP instalada. o /proc/driver/nvidia/agp/host-bridge Información sobre el puente (bridge) de comunicación con el bus del sistema (modelo y capacidad de AGP). o /proc/driver/nvidia/agp/status Estado actual de AGP. Si se ha activado el soporte de AGP en el sistema, el controlador de AGP, muestra el controlador de AGP en uso, la velocidad de AGP y el estado de las funciones de escritura rápida (Fast Writes) y SBA (Side Band Addressing). El controlador de AGP puede ser el que integra NVIDIA o AGPGART (el controlador agpgart.o del kernel de Linux). Si observa la indicación "inactive" junto a AGPGART, significa que el chipset AGP ha sido programado por AGPGART, pero no se encuentra en uso. El estado de SBA y Fast Writes indica si se está utilizando alguna de las funciones. Recuerde que hay varios factores que determinan si se activará el soporte de alguna de ellas. En primer lugar, la tarjeta AGP y el puente de comunicación con el bus del sistema deben soportar la función. Pero, incluso aunque ambos la soporten, el controlador puede decidir no usarla en favor de la estabilidad del sistema. Esto es especialmente cierto en el caso de Fast Writes. __________________________________________________________________________ (ap-p) APÉNDICE P: SOPORTE DE XVMC __________________________________________________________________________ Esta versión incluye soporte del API XvMC versión 1.0 (compensación del movimiento en X-Video) en los productos GeForce4 y GeForce FX exclusivamente. Hay una librería estática, "libXvMCNVIDIA.a", y otra dinámica, "libXvMCNVIDIA_dynamic.so", que es adecuada para dlopening. GeForce4 MX y GeForce FX soportan los niveles de aceleración "IDCT" y "compensación del movimiento" (motion-compensation) de XvMC, en tanto que los productos GeForce4 Ti sólo soportan el nivel "compensación del movimiento". También se soportan subimágenes AI44 e IA44, al igual que superficies 4:2:0 hasta 2032x2032. libXvMCNVIDIA observa la variable de entorno XVMC_DEBUG y envía el resultado de la depuración a stderr si se configura con el entero propiado. '0' desactiva la salida de la depuración. '1' activa la salida de la depuración con condiciones de error. '2' o superior activa la salida de mensajes de advertencia. __________________________________________________________________________ (ap-q) APÉNDICE Q: SOPORTE DE GLX __________________________________________________________________________ Esta versión soporta GLX 1.3 con las siguientes extensiones: GLX_EXT_visual_info GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_ARB_get_proc_address Para obtener una descripción cualquiera de ellas, consulte el registro de extensiones OpenGL http://oss.sgi.com/projects/ogl-sample/registry/index.html. Algunas de las extensiones de la lista forman parte de las funciones centrales de GLX 1.3, pero también se exportan como extensiones para proporcionar compatibilidad con versiones anteriores. __________________________________________________________________________ (ap-r) APPENDICE R: CONFIGURACIÓN DE VARIAS PANTALLAS X EN UNA TARJETA __________________________________________________________________________ Los procesadores gráficos que soportan TwinView (consulte (ap-i) APLENDICE I: CONFIGURACIÓN DE TWINVIEW) también pueden configurarse para tratar cada dispositivo de visualización como una pantalla X independiente. Aunque esta alternativa presenta varios inconvenientes con respecto al uso de TwinView (p. ej.: las ventanas no pueden arrastrarse de una pantalla X a otra, las funciones OpenGL aceleradas por hardware no se aplican a ambas pantallas), también ofrece algunas ventajas: o Si cada dispositivo de visualización es una pantalla X independiente, las propiedades de cada pantalla pueden ser distintas en cada dispositivo (por ejemplo, profundidad, tamaño de la ventana raíz, etc.). o Las funciones que sólo pueden utilizarse en un monitor cada vez (por ejemplo, la superposición de vídeo o la superposición RGB acelerada por hardware) y que, por tanto, no son aptas para TwinView, pueden utilizarse en la primera pantalla X cuando hay dos pantallas independientes. o Históricamente la asociación 1-1 entre dispositivos de visualizacion y pantallas X está más en línea con X. Para configurar dos pantallas X distintas que compartan un mismo procesador de gráficos, es preciso hacer lo siguiente: En primer lugar, cree dos secciones Device, cada una de ellas con el BusID de la tarjeta gráfica que van a compartir, el controlador "nvidia" y una de las pantallas asignadas: Section "Device" Identifier "nvidia0" Driver "nvidia" # Especificar en BusID la ubicación de la tarjeta gráfica utilizada BusID "PCI:2:0:0" Screen 0 EndSection Section "Device" Identifier "nvidia1" Driver "nvidia" # Especificar en BusID la ubicación de la tarjeta gráfica utilizada BusId "PCI:2:0:0" Screen 1 EndSection A continuación, cree dos secciones Screen, en cada una de las cuales utilizará una de las secciones Device: Section "Screen" Identifier "Screen0" Device "nvidia0" Monitor "Monitor0" DefaultDepth 24 Subsection "Display" Depth 24 Modes "1600x1200" "1024x768" "800x600" "640x480" EndSubsection EndSection Section "Screen" Identifier "Screen1" Device "nvidia1" Monitor "Monitor1" DefaultDepth 24 Subsection "Display" Depth 24 Modes "1600x1200" "1024x768" "800x600" "640x480" EndSubsection EndSection (Nota: también necesitará crear otra sección Monitor) Por último, actualice la sección ServerLayout para utilizar y ubicar ambas secciones Screen: Section "ServerLayout" ... Screen 0 "Screen0" Screen 1 "Screen1" leftOf "Screen0" ... EndSection Si precisa más información, consulte las páginas de ayuda online sobre XF86Config(5x) o xorg.conf(5x). __________________________________________________________________________ (ap-s) APÉNDICE S: GESTIÓN DE LA ENERGÍA __________________________________________________________________________ Esta versión incluye soporte de gestión de la energía basada en APM e inicialmente también admite gestión de la energía basada en ACPI. Esto significa que nuestro controlador permite usar las funciones de suspensión (suspend), reanudación (resume) y reposo (standby). Tenga presente que ACPI sólo se incluye en los kernels 2.6 y posteriores gracias al uso de un nuevo modelo de controlador de 2.6 diseñado para aceptar las funciones standby/resume de ACPI. Consulte la documentación de su distribución para averiguar el modo de configurar y utilizar la gestión de la energía en su sistema. El soporte de la gestión de la energía (Power management) aún está en fase de desarrollo y es una función en versión beta. Por tanto, parte de su funcionalidad aún no está disponible o no es totalmente fiable. Entre los problemas conocidos se incluyen: Algunos chipsets pierden su configuración APG después de un tiempo de suspensión tras el cual puede haber quedado dañado el bus. El controlador de AGP está obligado a guardar y restaurar la información de estado relevante de los registros en tales sistemas. El NvAGP de NVIDIA recibe la notificación de los eventos de gestión de la energía y se segura de mantener su configuración intacta durante los ciclos de suspensión/reanudación. El controlador AGPGART de Linux 2.4 no admite la gestión de la energía, pero el de Linux 2.6 sí, aunque sólo en determinados chipsets. Si utiliza cualquiera de estos dos controladores de AGP y detecta que el sistema no reanuda el funcionamiento correctamente, pruebe a utilizar el controlador NvAGP de NVIDIA. Desactivar el soporte de AGP (consulte el APÉNDICE F: CONFIGURACIÓN DE AGP para averiguar la manera de desactivar AGP) puede ser otra forma de resolver este problema. De ACPI sólo se admite la función S3 "Suspend to Ram". Esto significa que la función S4 "Suspend to Disk", también conocida como "Software Suspend" o "swsusp", no funciona de forma fiable. __________________________________________________________________________ (ap-t) APÉNDICE T: NOMBRES DE DISPOSITIVOS DE VISUALIZACIÓN __________________________________________________________________________ Se entiende por "dispositivo de visualización" cualquier componente de hardware capaz de mostrar una imagen. Estos dispositivos se dividen en tres categorías generales: pantallas TRC analógicas, pantallas planas digitales (DFP) y televisores. Recuerde que el controlador enmarca las pantallas planas analógicas en la misma categoría que las pantallas TRC. El "nombre de dispositivo de visualización" es una cadena que identifica de forma exclusiva un dispositivo de visualización y normalmente tiene el formato "-", por ejemplo: "CRT-0", "CRT-1", "DFP-0" o "TV-0". Conviene tener en cuenta que el número indica cómo se ha realizado la conexión entre el dispositivo de visualización y la placa de gráficos, y no tiene nada que ver con el número de dispositivos existentes de una misma clase. Esto significa, por ejemplo, que podemos tener "CRT-1" aunque no tengamos "CRT-0". Para saber qué dispositivos de visualización se encuentran conectados en un determinado momento, busque una línea similar a la siguiente en el archivo de registro de X: (II) NVIDIA(0): Connected display device(s): CRT-0, DFP-0 Los nombres de dispositivos de visualización pueden utilizarse en las opciones MetaMode, HorizSync y VertRefresh del archivo de configuración de X para indicar a qué pantalla debe aplicarse el valor definido. Por ejemplo: Option "MetaModes" "CRT-0: 1600x1200, DFP-0: 1024x768" Option "HorizSync" "CRT-0: 50-110, DFP-0: 40-70" Option "VertRefresh" "CRT-0: 60-120, DFP-0: 60" No es obligatorio especificar el nombre del dispositivo de visualización en estas opciones. Si no se hace, el controlador intenta deducir a qué dispositivo se refiere la opción. Por ejemplo, en el caso de MetaModes, el primer modo de la lista se aplica al "primer" dispositivo de visualización y el segundo modo al "segundo" dispositivo. Lamentablemente, no siempre está claro qué dispositivo es el "primero" y cuál es el "segundo", por eso es preferible especificar el nombre de dispositivo de visualización. Al indicar los nombres de dispositivos de visualización, también se puede omitir el número, aunque esto únicamente es útil en el caso de que sólo haya un dispositivo de ese tipo. Por ejemplo, si se ha conectado una pantalla TRC y otra DFP, puede referirse a ellas de la forma siguiente en la opción MetaMode: Option "MetaModes" "CRT: 1600x1200, DFP: 1024x768"