040209/xorg

From BluWiki

Por Brice Goglin:

Xserver 1.6, Intel 2.6.1,... ¿Qué pasa con XSF?

Ha pasado algún tiempo desde mi última entrada. No porque no haya pasado nada, más bien porque no tuve tiempo de hacer nada por X. Afortunadamente, Julien está cuidando de X en Debian por lo que seguimos de cerca los últimos acontecimientos. Obviamente, por el congelamiento de Lenny, esto todo está pasando en experimental.

Xserver 1.6

Se espera el lanzamiento de Xserver 1.6 para un futuro cercano. 1.6-rc1 (1.5.99.901) entró recientemente en experimental. Ambos controladores, de vídeo y los de entrada ABI, cambiaron; y también se han reconstruido unos cuantos controladores más. Así que si no estáis usando Intel o Radeon, aún no tenéis por qué actualizaros. Por favor, ser pacientes :) Puede que hayáis escuchado que últimamente están pasando muchas cosas en X.org: DRI2, kernel-modesetting (KMS), RandR 1.3,... Todavía no está todo listo, pero no le falta mucho.

Radeon 6.10.0 e Intel 2.6.1

Se ha liberado el controlador Radeon 6.10.0 a principios del 2009. Como es usual, incluye muchas correcciones y mejoras para las tarjetas modernas (ver el blog de Alex Deucher para más detalles). Después de todo, Radeon aún no está listo para DRI2 ni KMS. La mayoría del desarrollo para estas nuevas características está empezando a realizarse para el controlador Intel, que recientemente también liberó su versión 2.6.1.

DRI2

DRI2 es la nueva Infraestructura de Renderizado Directo. El cambio más destacado desde el punto de vista del usuario, es el soporte para Redirect Direct Rendering, lo que significa, básicamente, que vuestras aplicaciones 3D pueden ser oscilantes y transparentes en Compiz. Ver el blog de Kristian Høgsberg para más detalles.

Si queréis probar DRI2 en Intel, tenéis que activar UXA como la arquitectura de aceleración en xorg.conf (Option «AccelMethod» «UXA» en la sección Debice). Luego DRI2 estará activa automáticamente. Después podrá funcionar o no, dependiendo del hardware, por ejemplo. Yo obtengo una pantalla en negro con i865 mientras que funciona bien con i945 hasta que ejecuto Compiz (luego el servidor se apaga por alguna razón). Tened en cuenta que probablemente, queráis actualizar a los paquetes Mesa de experimental (7.3 ha sido liberada recientemente). Seguramente, si usáis las instantáneas git de varios componentes (Mesa, libdrm, kernel drm, controlador Intel,...) podréis ayudar, pues las versiones liberadas aún no parecen estar completamente listas. Pero, en un futuro cercano las cosas deberían ir a mejor para el uso de todos.

Kernel Modesetting

La otra gran novedad que estos días que ha hecho mucho ruido en X.org es el Kernel Modesetting (KMS). Mueve la gestión de modo (resolución y ratio) al kernel. Lo que ayuda a soportar el cambio entre diferentes sesiones de usuario, permite reportar mensajes del kernel (oops, panics,...) mientras se está ejecutando X y reduce la necesidad de poner en blanco la pantalla durante el arranque (porque el kernel puede configurar la pantalla antes y X no tiene que cambiarlo después).

Probar KMS requiere de un kernel muy nuevo (2.6.29). También es buena idea usar una instantánea git de la pila drm porque yo no pude hacerlo funcionar en el 2.6.29-rc2. Otra vez, en principio sólo Intel soporta KMS, los otros controladores lo harán más tarde.

El regreso del panorámica (RandR 1.3)

Xserver 1.6 da soporte para la versión 1.3 de la extensión RandR de X. Entre otras mejoras, reintroduce una característica que muchos usuarios echaban de menos desde que se había deshabilitado en Xserver 1.3 y sucesivos. «Panning» (a menudo referido a «Virtual Desktop») da la posibilidad de mover la pantalla por un escritorio más grande cuando acercas el ratón a su borde. En vez de configurarse con la opción Virtual en xorg.conf (ahora esta opción significa algo más), ahora puede ser habilitada y configurada con xrandr --panning. Necesitaréis los últimos libxrandr2 y xrandr para hacerlo (este último todavía no se ha subido).

¿Cómo cambiar a «Input-hotplug»?

Hace un tiempo que he estado pensando en cómo conseguir que funcionase el «input-hotplug» de X.org, pero nunca lo había intentado hasta hoy. En estos momentos es muy sencillo, una vez que sabes cómo hacerlo.

Requerimientos

Primero aseguraos de que tenéis instalado el controlador evdev (xserver-xorg-input-evdev). Puede que queráis usar los paquetes X de experimental pues son mucho más recientes que los de Lenny o Sid, mientras se mejora la gestión de entrada. Luego, si no estáis ejecutando un núcleo pre-compilado, revisad que el controlador evdev esté habilitado y cargado en vuestro núcleo (CONFIG_INPUT_EVDEV).

Cómo decirle a hal qué hacer con los dispositivos de entrada

Ahora necesitaréis decirle a hal cómo configurar los dispositivos de entrada. En estos momentos, no tenéis demasiado que hacer pues el último paquete xserver-xorg-input-evdev os da lo que necesitáis. hal lee todos los archivos fdi como le indica /usr/share/hal/fdi/policy, para saber configurar los dispositivos. Si ejecutáis lshal y buscáis input, deberíais ver que evdev está seleccionado para controlar tus dispositivos de entrada.

De todas formas, si buscáis dispositivos de teclado en lshal (buscad input.keys), veréis que se está usando la configuración US. Para cambiar a otra, podéis añadir reglas en un nuevo archivo *.fdi en /etc/hal/fdi/policy/. Por ejemplo, para la configuración francesa:

<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="2.0">
<device>
<match key="info.capabilities" contains="input.keys">
<-- Enforce XkbLayout=fr and XkbVariant empty -->
<merge key="input.xkb.layout" type="string">fr</merge>
<merge key="input.xkb.variant" type="string" />
</match>
</device>
</deviceinfo>

Gracias a esto, como es habitual, podéis forzar a XkbLayout, XkbVariant y a sus amigos en /etc/X11/xorg.conf. No os olvidéis de reiniciar hal después de modificar los archivos fdi. Luego ejecutad lshal y buscar Xkb, allí debería aparecer vuestra configuración. Tened en cuenta que podéis añadir algunas reglas coincidentes para configurar dispositivos con diferentes configuraciones, si lo necesitáis. Sólo tenéis que leer la salida de lshal y encontrar algo como un identificador de hardware para seleccionarlo.

Podéis encontrar alguna documentación sobre estas reglas mirando en los archivos fdi existentes, en /usr/share/hal/fdi/policy/20thirdparty/, y en x11-input.fdi (recordad que input.skb.foo es la sintaxis recomendada actual, en vez de input.x11_options.XkbFoo).

Touchpads

Si tenéis un touchpad y queréis usar el controlador synaptics, instalar xserver-xorg-input-synaptics os dará otro archivo fdi. /usr/share/hal/fdi/10thirdparty/11-x11-synaptics.fdi que es el requerido con input.touchpad en las capacidades de dispositivo en hal. Ahora el controlador synaptics estará automágicamente cargado para tu touchpad (en vez de evdev para los ratones normales). De nuevo, podéis anular esta regla en /etc/hal/fdi/policy/ y también podéis añadir algunas opciones de configuración para synaptics. Ver /usr/share/hal/fdi/policy/20thirdparty/11-x11-synaptics.fdi como ejemplo.

Afortunadamente, nunca tendréis que tratar manualmente del archivo /etc/hal/fdi/policy. La idea es tener a hal examinando la configuración de la consola Debian y que coja, al menos, la configuración del teclado automáticamente.

Diciéndole al Xserver que hable con hal

Ahora, necesitáis decirle a Xserver que use lo que hal quiera. Básicamente, queréis borrar todo lo relacionado con el teclado, ratón y otros dispositivos de entrada de vuestro xorg.conf. Sólo cojer todas las secciones InputDevice y todas las referencias a ellas en las demás secciones. Con las versiones recientes de Xserver, las opciones AllowEmptyInput y AutoAddDevices están habilitadas por defecto (si no, podríais tener que añadirlas en la sección ServerFlags).

Para obtener más documentación, podéis leer el blog de Peter Hutterer, especialmente esta entrada y esta otra.

De todas formas, si no queréis esta forma de input-hotplug y queréis un Xserver reciente, deberéis marcar a off en la sección ServerFlags a AllowEmptyInput y AutoAddDevices.