Archive for the ‘Notas’ Category.

Calibración del Touchpad en Linux y GNOME3

Ya comprendí a mi hermana cuando le instalé Debian. Utilizar un Touchpad en una laptop con Linux es una de las peores experiencias que he tenido con este sistema operativo.

El problema: estando escribiendo, cualquier rozón —a veces ni siquiera se necesita un rozón— provoca que el ratón se considere presionado en una ubicación diferente a la del cursor. Esto nos mueve súbitamente el cursor a la ubicación del puntero y quienes mecanografiamos debemos detener nuestra escritura para reubicar el cursor y continuar frustradamente (no sin antes corregir las consecuencias de lo ocurrido: salida de foco, tecleo en un lugar incorrecto, etc.).

Estoy usando una laptop Samsung NP-R540-JA09US. Naturalmente, tan pronto como la recibí, le instalé Debian. A diferencia de la IBM ThinkPad T42 la Samsung no tiene TrackPoint. Mi hermana tenía instalado Debian 6.0 en una laptop HP Pavilion dv6700. Lo menciono porque, al ser diferente hardware, me resulta más fácil echarle la culpa al software. Yo estoy usando Debian Sid; no Wheezy, sino Sid: dos versiones adelante de la estable. Lo que no puedo creer es que nadie más haya experimentado el mismo problema en todo este tiempo.

La mayoría de los linuxeros acostumbramos resolver nuestros propios problemas, así que a veces los desarrolladores no se enteran de la problemática que envuelve a los usuarios novatos y no-técnicos. Llamada de atención para los desarrolladores de GNOME.

Al menos por default, en GNOME, las interfaces para ajustar los parámetros del Touchpad son muy pobres. El afán de hacer las interfaces amigables a veces llevan a los desarrolladores a la falacia de eliminar cosas que realmente son útiles, como los valores numéricos que resultan de un control tipo “slider” (de esos que son como para controlar el volumen, pero rectos). Esto hace que sea difícil tener valores de referencia para calibrar algo tan importante como el equivalente del ratón.

Por ejemplo, para la “detección de palma” tienen un slider cuyos extremos dicen algo así como “leve” y “fuerte”. Es un control que no tiene retroalimentación inmediata o visual, con valores sin sentido y sin disponer de una referencia comparativa.

Al usar Debian Sid, actualizar a una versión más reciente de software no es una opción, a menos que quiera arriesgar mi laptop con software experimental y con baja probabilidad de que el problema esté realmente resuelto.

Hecho el berrinche correspondiente, incluyo los pasos que seguí para reducir mi estrés con el uso del Touchpad.

Habilitar de manera personalizada la desactivación del Touchpad mientras escribo

Esta parte la hice bajo GNOME 3. Aunque GNOME Control Center trae una opción llamada “Deshabilitar el Touchpad mientras se escribe”, la realidad es que los parámetros de esta opción son extremadamente conservadores.

Lo que esta opción hace es cargar un programa llamado syndaemon, que monitoriza los eventos de teclado y desactiva el Touchpad mientras se detecta que el usuario está escribiendo. GNOME Control Center, en su versión 3.2.2, al menos en Debian Sid, deshabilita el Touchpad durante 2 segundos después del último teclazo, con el inconveniente de que ni siquiera permite el movimiento del puntero.

Para resolver esto, deshabilité dicha función, dejando que el touchpad siempre estuviera habilitado por default, pero yo cargué manualmente syndaemon desde un “Startup Application” (gnome-session-properties) con los siguientes parámetros:

syndaemon -i 0.8 -K -t -R -d

-i 0.8, que deshabilita el Touchpad por sólo 0.8 segundos después del último teclazo.
-K, que no deshabilita el Touchpad si se usan combinaciones de teclas (como Ctrl+W). Esta opción ya la incluye GNOME.
-t, que sólo deshabilita los taps y los scrolls. El puntero se sigue moviendo.
-R, porque ya la incluía GNOME (usa XRecord).
-d, porque ya la incluía GNOME (carga como demonio).

Con esto, espero menos de la mitad del tiempo para poder hacer un tap (y siempre dispongo de los botones de todos modos) y mientras puedo ir moviendo el puntero. Esto hace que el uso de la computadora sea mucho más fluido.

Calibración de la detección de palma

Esto lo hice a nivel X.org. A falta de parámetros reales para calibrar la palma, opté por usar el siguiente comando fuera de X11:

sudo evtest /dev/input/event6 | egrep 'WIDTH|PRESSURE'

Esta instrucción (cambiando event6 por el valor que corresponda en tu laptop) permite ver los eventos que ocurren con el Touchpad, relevantes a la presión y el ancho del toque.

Después de comparar con algunos taps comunes, toques accidentales, mi palma, etc., decidí que después de una anchura de 7 y una presión de 70, se considere palma. Así, creé el archivo /etc/X11/xorg.conf.d/synaptics con las siguientes líneas:

Section "InputClass"
	Identifier "Touchpad" #Requerido
	MatchIsTouchpad "yes" #Requerido
	Driver "synaptics" #Requerido

	Option	"PalmDetect"	"1"
	Option	"PalmMinWidth"	"5"
	Option	"PalmMinZ"	"70"
EndSection

Para ver los valores que actualmente tiene su driver de Synaptics (el Touchpad), se usa:

synclient

stail-notify.bash

El siguiente script hace que cada línea nueva que aparezca en un archivo remoto, salte en mi pantalla como notificación.

Con pocas modificaciones se puede hacer lo mismo para un archivo local.

Se puede colocar el comando en el arranque de sesión, pero se va a bloquear para pedir la contraseña. Se recomienda tener acceso al servidor remoto por medio de claves públicas para que el agente de SSH automáticamente pida la contrafrase en pantalla.

Puesto que tail -f nunca debería salirse, tal vez sería conveniente agregar una línea después del SSH que mande una alerta de que concluyó el tail -f o de que falló la conexión con el servidor. Tal vez se pueda hacer revisando el código de retorno, pero hay que ver qué ruido le provoca el tubo.

Se puede modificar para que también el icono y la severidad de la notificación sean distintas, pero en mi caso no es necesario.

El comando podría fallar si la cadena a mostrar contiene comillas.

#!/bin/bash

# stail-notify.bash
# Escrito por Octavio Alvarez.
# Licencia: WTFPL

[ $# -lt 3 ] && {
	echo "usage: "`basename $0`" <user@host> <file-to-tail> <alert-title>"
	exit
}

ssh $1 "tail -n 0 -f "$2 | while read M D T ELSE; do notify-send -t 5000 -i dialog-warning -u critical "$3" "$ELSE"; done

Para usarlo, lo ejecutan así:

stail-notify.bash alvarezp@192.168.2.100 /var/log/messages "Alerta de Syslog"

Dando la bienvenida a los usuarios de IRC con X-Chat 2.

Algunos usuarios, cuando entran a algún canal de charla (como el del Gultij) por IRC, saludan y preguntan si pueden ser ayudados. La gente que tiene más experiencia ya sabe lo que va a ocurrir:

  1. USUARIO_NUEVO entra al canal de charla y, después de no percatarse de lo que dice el topic, dice «tengo una pregunta» o «¿alguien me puede aydar?»
  2. VOLUNTARIO_1 dice «¿cuál es tu pregunta?»
  3. USUARIO_NUEVO le hace la pregunta específicamente a VOLUNTARIO_1.
  4. Si VOLUNTARIO_1 no contesta en menos de 2 minutos USUARIO_NUEVO se siente ignorado y repite la pregunta. Además de que no es obligación del resto del mundo estar atento de sus reclamos, es posible que VOLUNTARIO_1 no sepa, pero sí VOLUNTARIO_2, VOLUNTARIO_3 o VOLUNTARIO_N, que no están en el canal en ese momento.
  5. En ocasiones, cuando USUARIO_NUEVO no recibe respuesta, adopta una actitud donde VOLUNTARIO_1 está obligado a contestarle, como si fuera un servicio pagado de soporte.

Por eso, en los canales de charla, el protocolo es simplemente entrar, hacer la pregunta y ser paciente, muy paciente.

Obviamente, no todos saben esto y no es su culpa. Siempre entrará gente pidiendo ayuda y, claro, hay que darles la bienvenida. Esto toma tiempo, desde 1) estar al pendiente del canal hasta 2) escribir el mensaje de guía a cada usuario para que escriba su pregunta, dando a entender que yo sólo le doy al bienvenida. Para reducir la parte 2, algunos canales tienen un bot al que se le da la instrucción de darle la bienvenida al “usuario nuevo”. Yo creo que esto sale contraproducente porque la automatización se revela al usuario.

Para facilitar la parte 2, he configurado en mi X-Chat 2 los siguientes comandos para que la gente reciba un mensaje de mi parte.

/adelante $nick
say %2: adelante, qué pregunta tienes? Tal vez alguien sepa.
/paciencia $nick
say %2, sugiero que esperes un rato. Si alguien te puede ayudar, puede ser que esté ocupado o haya salido un momento.

y sus equivalentes en inglés:

/goahead $nick
say %2, what question do you have? Go ahead and ask; someone around might know.
/patience $nick
say %2, I suggest you wait for a while. If someone can help you, he may be busy or out for a moment.

El de /patience es para cuando el usuario haya repetido su pregunta a escasos minutos.

Aún falta pulir los mensajes para que se vean más naturales pero que, a su vez, abarquen más casos.

De esta manera me facilito el guiar a un usuario nuevo cuyo saludo, con un poco de suerte, yo vea. Creo que sólo siendo amigables con los usuarios nuevos, es como percibirán un valor real en la famosa “comunidad”. Para aumentar la probabilidad de detectar un saludo, es posible hacer cosas como configurar el realzado de palabras como “buenas” u “hola”, pero esto es harina de otro costal (X-Chat está muy limitado en este aspecto, pero se pueden escribir plug-ins).

Obviamente, si alguien va a tomar esta sugerencia, ponga su propio mensaje a su propio estilo. Realmente sería feo entrar a un canal y ver que 5 usuarios diferentes me contesten exactamente con el mismo mensaje.

Linux driver — ethX

$ ls -l /sys/class/net/*/device/driver
lrwxrwxrwx 1 root root 0 Oct 11 14:03 /sys/class/net/eth1/device/driver -> ../../../../bus/pci/drivers/skge
lrwxrwxrwx 1 root root 0 Oct 11 14:03 /sys/class/net/eth3/device/driver -> ../../../../bus/pci/drivers/8139too

Thanks to bldewolf. / Gracias a bldewolf.

Breve prueba de VNC Inversa, documentada

Esta es una nota rápida para documentar una prueba de conexion VNC inversa (Reverse VNC).

A diferencia de una conexión regular de VNC, en la cual te conectas a la PC a controlar, en una conexión inversa de VNC, la PC a controlar se conecta a ti. El control es en la misma dirección pero la conexión está invertida.

El beneficio? No tener que preocuparse sobre el estado de red ni direcciones de la PC remota. Suele ser más fácil iniciar conexiones que recibirlas. Así, quien tiene mejor conocimiento de redes será el que escuche y el alma en pena será el iniciador. Esto mueve las preocupaciones de red al “escuchante” del socket, justo donde deben estar en este caso en particular. Además, con el estado actual de IPv4 lleno de NAT, el mal necesario, no habrá que preocuparnos sobre la configuración de NAT / port forward en el router remoto.

Conformación de la prueba

La prueba se conforma de mi estación de trabajo de escritorio corriendo Ubuntu y mi laptop corriendo Windows, ambas en el mismo dominio de broadcast de Ethernet. No se toca gateway alguno en la prueba.

Nota: la prueba se realizó con software en inglés, de la cual traduje al español. La traducción podría no ser exacta en comparación con la versión en español del software.

Las características de mi estación de trabajo:

  • Sistema operativo: Ubuntu Lucid Lynx (10.04).
  • Paquete de VNC: xvnc4viewer 4.1.1+xorg4.3.0-37ubuntu2.
  • Rol: Computadora de control (cliente VNC). En un caso real aquí es donde yo estaría sentado y controlando computadoras remotas.
  • Dirección IP: 192.0.2.10 (esta dirección es falsa, para documentación según RFC 5735).

Características de la laptop:

  • Sistema operativo: Microsoft Windows XP SP3.
  • Paquete VNC: TightVNC 1.3.10, instalado de la colección OpenDisc.
  • Rol: PC a ser controlada (servidor VNC). En la vida real, esta sería la PC que recibiría soporte técnico por mí..
  • Dirección IP: 192.0.2.20 (esta dirección es falsa, para documentación según RFC 5735).

Pasos realizados para establecer la conexión

En la estación de trabajo (el cliente VNC, computadora de control):

  • Abrí una terminal
  • Ejecuté vncviewer -listen
  • Se debe recibir un mensaje como “main: Listening on port 5500″ (”escuchando en puerto 5500″)

En la laptop (el servidor VNC, la computadora a ser controlada):

  • Me fui a Inicio » Todos los programas » TightVNC y ejecuté Lanzar Servicio de TightVNC
  • Si aparece la ventana Propiedades, deshabilitar “Aceptar conexiones” y hacer click en OK (sólo por seguridad).
  • Click derecho en el icono de Servidor TightVNC en la bandeja de sistema y escoger Agregar nuevo cliente…
  • Ingresar la dirección IP de la estación de trabajo, en este ejemplo, 192.0.2.10 y hacer clic en OK o presionar Enter.

Notas

  • La prueba fue realizada con el Firewall de Windows habilitado. Podrías recibir un mensaje como Para ayudar a proteger tu equipo, el Firewall de Windows bloqueó algunas de las características de este programa. | El administrador del equipo podría ayudar a desbloquear el siguiente programa: TightVNC Win32 Server cuando al correr el Servidor TightVNC. Se le puede dar simplemente “Aceptar” puesto que esa PC será la que inicie y no la que escuche. Este mensaje se inhibe al deshabilitar Aceptar conexiones en la ventana Propiedades del Servidor TightVNC.
  • La prueba fue repetida usando una cuenta restringida de Windows con resultados satisfactorios. Esto te da gran flexibilidad. Podrías hasta hacer una versión portátil del servidor de TightVNC siguiendo el paso de las instrucciones en esse documento sobre VNC en el blog TinyApps.Org
  • Dependiendo del ancho de banda y latencia disponibles, podría ser necesario ajustar el servidor en la ventana de propiedades.
  • Noté una demora algo larga durante el primer intento de conexión, incluso llegando a fallar. En el segundo intento funcionó bien. Quiero suponer que tiene que ver con demoras de resolución de DNS y el caché, pero eso es mera especulación.

Se aceptan comentarios. Si conoces instrucciones para este mismo escenario usando otra plataforma, publícalo en tu blog y enlázalo desde un comentario aquí, o escríbelo directamente en un comentario.

Quick Reverse VNC test, documented

This is a quick note, documenting a quick successful test on Reverse VNC connections.

Unlike regular VNC connections, in which you connect to the controllable PC, in a Reverse VNC connection the controllable PC will connect to you. The control is in the same direction, but the connection is reversed.

What’s the benefit? Not having to worry about the network status and addresses of the remote PC. It is usually easier to initiate connections than to receive. This lets the guy with better network understanding to be the listener and the poor soul to be the initiator. This will put the network worries near to the tech support guy, where it should be for this particular scenario. Also, as with the current state of IPv4, full of the evil but necessary NAT, you will not have to worry about router NAT / port forwarding configuration in the remote router.

Test setup

The test setup consisted on my desktop workstation running Ubuntu and my laptop running Windows, both on the same Ethernet broadcast domain. No gateway was involved in the test.

The desktop workstation had the following characteristics:

  • Operating System: Ubuntu Lucid Lynx (10.04).
  • VNC package: xvnc4viewer 4.1.1+xorg4.3.0-37ubuntu2.
  • Role: Controlling computer (VNC client). In real life here is where I would sit and control other computers.
  • IP address: 192.0.2.10 (this is a fake, RFC 5735 documentation address).

The laptop had the following characteristics:

  • Operating System: Microsoft Windows XP SP3.
  • VNC package: TightVNC 1.3.10, installed from the OpenDisc software collection.
  • Role: Controlled computer (VNC server). In real life this would be the PC receiving remote tech support from me.
  • IP address: 192.0.2.20 (this is a fake, RFC 5735 documentation address).

Steps performed to establish the connection

On the desktop workstation (the VNC client, controlling computer):

  • Opened a terminal
  • Ran vncviewer -listen
  • You should get a message like “main: Listening on port 5500″

On the laptop (the VNC server, controlled computer):

  • Went to Start » All Programs » TightVNC and ran Launch TightVNC Server
  • If the Properties window pops up, disable “Accept socket connections” and click OK (just for security reasons).
  • Right click on the system tray TightVNC Server icon and choose Add New Client…
  • Enter the IP address of the desktop workstation, in this example, 192.0.2.10 and click OK or hit Enter.

Sidenotes

  • The test was done with the Windows Firewall enabled. You might get a message like To help protect your computer, Windows Firewall blocked some of this program features. | The computer administrator may unblock this program for: TightVNC Win32 Server when running the Tight VNC Server. You may safely click “OK” because you will initiate connections and not listen for a connection. This message gets inhibited by disabling Accept socket connections in the Properties window.
  • The test was repeated using a restricted Windows account, with a successful result. This gives you a lot of flexibility. You might even try making a portable TightVNC server by following the Step 2 from the instructions on this VNC document from the TinyApps.Org blog
  • Depending on the available bandwidth and latency, it might be necessary to tweak the server on the Properties window.
  • I noticed a somewhat long delay on the first connection attempt, in one case even leading to a connection failing. On the second try it worked fine. I would guess this has to do with DNS resolving delays and caching, but it’s just speculation.

Comments welcome. If you have instructions for the same scenario on different platforms, post it on your blog and link it from a comment, or write it directly on a comment.

Remplazo interactivo en vim

Una nota rápida para que no se me olvide la siguiente vez.

Para remplazar texto en vim, confirmando cada remplazo, basta con agregar la opción “c” al comando “s”.

Si nuestro comando original era %s/viejo/nuevo/g entonces se usa %s/viejo/nuevo/gc.

Cada posible remplazo se sombrea y vim solicita confirmación con las siguientes opciones:

y = yes, remplazar el texto sombreado.
n = no, ignorar el texto sombreado.
a = all, siempre sí remplazar todo.
l = last, cambiar el actual y terminar.
q = quit, ignorar el actual y terminar.
^E = desplazar el texto hacia adelante (para ver más texto).
^Y = desplazar el texto hacia atrás.

Fuente:
Vim tips: The basics of search and replace

Notas sobre gamma en monitores en X.org 7.4

Estoy acostumbrado a usar monica para establecer la calibración gamma de mi monitor en la casa, donde sólo tengo un monitor. Cuando guardo las preferencias, monica guarda un pequeño .monicarc en $HOME, que simplemente manda llamar xgamma.

Sin embargo, en el trabajo, donde tengo dos monitores, ambos pertenecen al mismo display y pantalla (parece ser por XRandR). Puesto que xgamma cambia el gamma para toda la pantalla, afecta a ambos monitores a la vez.

Para ajustar el gamma para sólo uno de lo monitores hice esto:

xrandr -d :0 --screen 0 --output VGA-0 --gamma 1.2:1.2:1.2

En #xorg se me sugirió que tal vez podría prescindir de los parémtros -d y –screen. Para obtener valores posibles de -d, –screen y –output usé lo siguiente:

xrandr | grep connected

Aún me falta por encontrar por qué usar valores mayores que 1 me obscurece la pantalla en lugar de aclararla.