Expediente X(org)

Dado que la administración de sistemas es pariente lejana del vudú, a veces pasan cosas muy misteriosas en nuestras máquinas. Hay aplicaciones que no funcionan como debieran mientras que en otros PC no dan problemas. Voy a contar 3 casos que me han tocado de cerca:

• En las LibreOffice, al ir escribiendo un documento de texto se quedaban en blanco determinadas partes de la pantalla, siendo imposible ver lo escrito.
• El pseudo-driver de las pizarras Interwrite, el Device Manager (hecho en Java, toma moreno), no arrancaba en un PC y por tanto no se mostraba el icono del driver en el panel. Lanzando el LinuxLauncher.sh a mano desde un terminal de las X acababa dando una excepción y un error del tipo:
  

  
  The error was 'BadMatch (invalid parameter attributes)'.
   (Details: serial 253 error_code 8 request_code 73 minor_code 0)
   (Note to programmers: normally, X errors are reported asynchronously;
    that is, you will receive the error a while after causing it.
    To debug your program, run it with the --sync command line
    option to change this behavior. You can then get a meaningful
    backtrace from your debugger if you break on the gdk_x_error() function.)
  

• En el software Notebook de las pizarras Smartboard hay una funcionalidad llamada Screen Shade que simula una cortinilla que puedes mover y tapar parte de la imagen (como en los chistes "se baja el telón...") desde los 4 laterales. Al usarlo no funcionaba y no tapaba nada al correr/descorrer las cortinas.

Todo estos expedientes X, que parecen problemas de la aplicación, son realmente problema de la versión o configuración del driver de las X que usamos (es decir, son expedientes X.Org). Hay una manera rápida y segura de confirmarlo: no usando dicho driver y repitiendo la acción, ¿cómo "no usamos dicho driver"?. Bueno, podríamos modificar /etc/X11/xorg.conf para cargar el driver Vesa y reiniciar las X para hacer la prueba, pero no hace falta ser tan drásticos. Hay un par de maneras más sencillas:

• Para probarlo con una aplicación concreta (problema anterior de las LibreOffice): desde otro PC entrar con
  

  # ssh -X usuario@ip-pc-problematico
  

  Y una vez aquí lanzamos la aplicación desde línea de comandos y probamos a intentar repetir el problema. En el caso de LibreOffice ya no se hacían "invisibles" los caracteres escritos.
  La solución que encontraron mis compañeros fue cambiar el driver usado de nouveau a nvidia.
  
• Para probarlo con el escritorio completo (problema anterior del Device Manager de Interwrite o del Screen Shade de Smart Notebook) lo mas rápido es usar xrdp en el PC que da el problema:
  

  # apt-get install xrdp
  

  y conectar mediante rdesktop a él remotamente desde otro:
  

  # apt-get install rdesktop
  # rdesktop ip-pc-problematico
  

  Y una vez hemos hecho login en el escritorio remoto vemos que el problema ya no sucede (ni el de Interwrite ni el de Smartboard).
  

Aquí vemos, dentro de una conexión xrdp, el Device Manager ejecutándose en la parte derecha del panel:

En este caso la solución que encontré fue cambiar el xorg.conf para que la aceleración pasase de ser EXA a SNA.

Y aquí el Notebook con el telón a medio descorrer:

En este caso no he encontrado todavía la solución, pero estoy en ello :-).

Con esto nos queda claro que haciendo la conexión con ssh -X o rdesktop, que no usan el driver X de la máquina destino para los gráficos, no existe ninguno de los problemas descritos. El problema está por tanto en el driver X o en su configuración.

A partir de aquí habría que investigar si procede cambiar el driver (actualizando o instalando la versión propietaria del mismo) o bien generar un xorg.conf y retocar sus esotéricos parámetros (como siempre, a ciegas y sin tener ni idea de lo que estamos haciendo). Con eso tendremos el Expediente X(org) resuelto.

Hasta pronto.....