Archivo de la categoría: Sin categoría

A ritmo de conga (14)

Esta creo que por fin será la última entrada en una serie que se ha prolongado muchísimo más de lo que esperaba. En esta hablaré de los últimos comandos que quedan por analizar.

En primer lugar está el comando 143. Este comando es el que se emite cuando se pulsa una especie de diana que hay en la parte superior derecha de la app oficial, y hace que el robot emita un pitido. En el manual no dice para qué sirve, por lo que lo único que se me ocurre es para localizarlo cuando no sabes donde anda. Sin embargo lo veo poco útil, pues si está en marcha lo escucharás perfectamente, y si está en pausa, al cabo de un minuto más o menos se apagará y dejará de responder a los comandos enviados por WiFi.

Por otro lado, ya he descubierto para qué sirve el comando 400, y no es para indicar que se ha abierto la app. Resulta que, al contrario de lo que pensaba, es la propia aspiradora la que recuerda las tareas cuando la programamos para que aspire tal día a la semana a tal hora. Así, si por ejemplo tenemos dos tareas programadas, una para que limpie de lunes a viernes a las 19:00 horas, y otra para que limpie sábados y domingos a las 16:30 horas, cuando emitimos el comando 400 nos devolverá esto:

{
  "version":"1.0",
  "control":{
    "targetId":"yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy",
    "targetType":"3",
    "broadcast":"0"
  },
  "value":{
    "transitCmd":"401",
    "maxRecord":"15",
    "result":"0",
    "orders":[
      {
        "sign":"1",
        "orderIds":"1,2,3,4,5",
        "valid":"1",
        "hour":"19",
        "minute":"0",
        "mode":"11",
        "fan":"1",
        "waterTank":"255"
      },{
        "sign":"2",
        "orderIds":"0,6",
        "valid":"1",
        "hour":"16",
        "minute":"30",
        "mode":"11",
        "fan":"2",
        "waterTank":"255"
      }
    ]
  }
}

En orders es donde viene toda la información clave: es una lista con tantos diccionarios como programaciones haya. En ellos, el campo sign es el identificador de cada programa. En orderIds vienen los días de la semana en los que se activará, siendo 0 el domingo, 1 el lunes, etc. El campo valid vale 1 si el programa está activo, y 0 si está desactivado. Los campos hour y minute especifican, como cabe suponer, la hora a la que se quiere que comience. Por último, los campos mode, fan y watertank indican el modo de limpieza, la potencia del ventilador y el modo de fregado que se quieren utilizar para ese programa concreto.

El siguiente comando importante es el 402, que permite añadir un nuevo programa a la lista o modificar uno ya existente. El formato es el siguiente:

{
  "cmd":0,
  "control":{
    "authCode":"xxxxxx",
    "deviceIp":"192.168.3.56",
    "devicePort":"8888",
    "targetId":"yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy",
    "targetType":"3"
  },
  "seq":0,
  "value": {
    "orders":[
      {
        "fan":"3",
        "hour":"19",
        "minute":"30",
        "mode":"11",
        "orderIds":"2,0,6,5,4,3,1",
        "sign":"1",
        "valid":"1",
        "waterTank":"255"
      }
    ],
    "transitCmd":"402"
  }
}\n

Vemos que en el campo orders van los valores del programa que queremos añadir o modificar (lo que se sabe gracias al campo sign.

Por último, el comando 404 permite borrar un programa. Su formato es el siguiente:

{
  "cmd":0,
  "control":{
    "authCode":"xxxxxx",
    "deviceIp":"192.168.3.56",
    "devicePort":"8888",
    "targetId":"yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy",
    "targetType":"3"
  },
  "seq":0,
  "value":{
    "orderIds":"3,6",
    "signs":"2",
    "transitCmd":"404"
  }
}\n

El formato es aún más sencillo: junto con el comando y el campo signs, que indica qué programa se quiere borrar, se incluye el campo orderIds con los días del programa a borrar. Este campo tiene que coincidir con lo que contenga en ese momento el campo del mismo nombre del programa a borrar. No he probado qué ocurre si contiene menos o más valores.

Un ultimo detalle curioso es que hace un par de días actualicé el firmware de la WiFi, y curiosamente el contenido del tercer entero de las cabeceras enviadas por el servidor cambió de 0x01090000 a 0x01F20000. Lo mismo para el PONG de respuesta a un PING, que pasó de 0x01080001 a 0x01F10001. Sin embargo, si utilizamos los valores viejos todo sigue funcionando exactamente igual, lo que es curioso.

Memes animados de hoy y de siempre

Estoy preparando una entrada nueva y me apeteció añadir memes en el texto, porque ayudan a leerlo al permitir descansar la vista entre párrafo y párrafo, y le dan un toque más divertido y agradable.

Por desgracia, la cosa no es tan sencilla. Una primera opción es buscar GIFs animados, pero esto tiene varios problemas:

  • El tamaño de un GIF es bastante grande
  • El número de colores es limitado

La solución obvia es utilizar vídeos en su lugar, algo que WordPress soporta perfectamente. Para ello hay que embeberlo, activar la reproducción automática, el bucle, quitar los controles y, sobre todo, quitar el sonido. Esto último es muy importante, pues si no, el navegador se negará a reproducirlo hasta que el usuario haya interaccionado con la página (lo que obliga a haber hecho click en ella, pero no sirve con hacer scroll). El motivo para esto es evitar que una página recién cargada empiece a reproducir sonido por sorpresa, pues es algo muy molesto. Si no se hace, el vídeo no se reproducirá hasta que el usuario lo ponga en marcha a mano.

Aunque es muy fácil, por desgracia tiene el problema de que obliga a acordarse de todos los pasos, con lo que es bastante sencillo que, por despiste, se nos cuele alguno y nos quede el meme mal. Por eso decidí hacer un poco de JavaScript para solucionar esto de manera sencilla.

Lo primero es bajarse algún plugin que permita añadir JavaScript a nuestra plantilla. Yo uso WordPress, por lo que escogí Simple Custom CSS and JS. Una vez instalado y activado, sólo tenemos que añadir en nuestra plantilla este trozo de código:

let memeList = [];
function setPlayStatus(element) {
// check if it is visible
var rect = element.getBoundingClientRect();
let isVisible = (
rect.bottom >= 0 &&
rect.right >= 0 &&
rect.top <= (window.innerHeight || document.documentElement.clientHeight) &&
rect.left <= (window.innerWidth || document.documentElement.clientWidth)
);
if (isVisible != element.memeData.isVisible) {
if (isVisible) {
element.memeData.video.play();
} else {
element.memeData.video.pause();
}
element.memeData.isVisible = isVisible;
}
}

function checkForMemes() {
let elements = document.getElementsByTagName(«figure»);
for (let element of elements) {
if (!element.classList.contains(‘meme’)) {
continue;
}
memeList.push(element);
element.memeData = {};
for (let child of element.childNodes) {
if (‘controls’ in child) {
element.memeData.video = child;
element.memeData.isVisible = false;
child.muted = true;
child.controls = false;
child.loop = true;
child.autoplay = true;
setPlayStatus(element);
}
}
}
}

function refreshMemesStatus() {
for (let meme of memeList) {
setPlayStatus(meme);
}
return true;
}

window.addEventListener(«load», checkForMemes);
window.addEventListener(«DOMContentLoaded», refreshMemesStatus, false);
window.addEventListener(«scroll», refreshMemesStatus, false);
window.addEventListener(«resize», refreshMemesStatus, false);

Con esto lo único que tenemos que hacer es añadir al elemento video la clase CSS meme, y automáticamente se establecerán los parámetros necesarios para que el vídeo funcione a la primera. A mayores, cuando el meme/vídeo se sale de la zona visible de la pantalla, se le da la orden de pausa para que no consuma nada de procesador. Aunque es probable que los navegadores lo tengan en cuenta, no es mala idea dejar indicado de manera explícita que nos da igual que el vídeo no siga avanzando mientras no lo vemos.

Parche para Gnome Boxes

Aunque hasta ahora utilizaba VirtualBox para hacer virtualización, hace unas semanas me dio por probar Gnome Boxes en su lugar, y la verdad es que me ha convenció mucho. Es cierto que no tiene muchas características avanzadas de VirtualBox, como son el portapapeles bidireccional o el acceso directo a USBs, pero la verdad es que, en general, no los necesito. Y, sin embargo, sí tiene algo que me era especialmente útil, que es que la emulación de la tarjeta gráfica funciona de manera nativa en Fedora y en Debian, sin necesidad de instalar nada. El motivo de que esto me resulte especialmente útil es que tengo algunos parches pendientes para mutter, el gestor de ventanas de Gnome, y la única manera de probarlos en condiciones (sobre la versión de desarrollo) es trabajar con Fedora. Por desgracia, no se qué pasa que los drivers de VirtualBox para la pantalla no me funcionan en Fedora. No es que funcionen mal, es que no he conseguido que me funcionen. En alguna ocasión parece que van, pero de pronto dejan de funcionar sin motivo aparente. Y depurar en un sistema en 640×480 es imposible. Por eso estoy utilizando Gnome Boxes para todo esto, porque me funciona perfectamente.

Por desgracia, hace unos días me encontré con que era imposible crear una nueva máquina virtual en Boxes: cada vez que escogía la opción en le menú, el programa se cerraba con un core dump.

Tras indagar un poco descubrí que el problema era que el programa se conectaba a una URL externa para bajar una lista de recomendaciones y mostrar las tres más interesantes; sin embargo, por algún motivo, todas menos dos fallaban a la hora de descargarlas. Y aquí llega el problema: el código no comprobaba cuantas recomendaciones había e intentaba mostrar siempre tres, pero al haber sólo dos, cascaba. Como solucionarlo era trivial, decidí escribir yo mismo el parche y enviárselo, y lo aceptaron de inmediato, por lo que ya vuelve a funcionar perfectamente.

Y aún me preguntan por qué me gusta tanto el software libre…

Juegos ALSA sobre PulseAudio

Hace unas semanas descubrí la saga de juegos de Deponia, y la verdad es que estoy enganchado. Además, hay versiones nativas para Linux en GOG games, y a un precio asequible, lo que es una maravilla.

Las tres primeras aventuras funcionaron en mi sistema Debian sin el más mínimo problema, pero la cuarta, sin embargo, sufría de un problema raro: al lanzarla se quedaba como colgada, con la pantalla en negro, y no aparecía el menú principal hasta que pulsaba ESC. Además, lo hacía sin sonido, lo que era muy sospechoso.

Al lanzarlo desde un terminal vi que salían una serie de errores referentes a que no podía abrir el dispositivo PCM de ALSA (el subsistema de sonido de Linux). Enseguida sospeché que el problema podía venir por tener PulseAudio gestionando todo el tema del audio. En concreto, el cuelgue del principio parecía que era porque intentaba mostrar un vídeo de presentación, pero se quedaba esperando a que la tarjeta de sonido estuviese lista (y por eso al pulsar ESC se desbloqueaba: porque cancelaba el vídeo y pasaba al siguiente paso).

La solución consistió en redireccionar el sonido PCM de los programas ALSA a través de PulseAudio. Para ello sólo tuve que crear un fichero llamado .asoundrc en mi directorio personal con este contenido:

pcm.!default {
type pulse
}

Gracias a él, ahora todos los programas que, por defecto, trabajan con ALSA, ahora enviarán su salida a través de PulseAudio. Esto es posible gracias al diseño de ALSA: mientras que en la vieja arquitectura OSS el programador abría el dispositivo de sonido directamente y utilizaba llamadas IOCTL para configurarlo, y llamadas read y write para capturar y emitir sonido, en ALSA se anima a utilizar únicamente una serie de bibliotecas de más alto nivel. Lo interesante es que esto permite que el programa se desentienda por completo de a donde se envía el sonido, pues eso lo decide el propio usuario mediante la configuración. Así, por defecto iría directamente al hardware, pero el sistema de plugins de ALSA permite enviarlo a cualquier otro sitio al poder definir tarjetas de sonido virtuales. Así, tenemos dos módulos especialmente interesantes que son pcm_pulse y pcm_jack, que permiten integrar de manera transparente cualquier aplicación ALSA con los demonios de sonido PulseAudio y JACK. El primero es justo el que utilizamos en el fichero de configuración de arriba.

Java vs. systemd

Pues parece que ya podemos añadir otra historia más a los problemas de systemd. Ahora resulta que un cambio inocente en sus políticas ha hecho que un bug serio en Java salga a la superficie: prácticamente todas las aplicaciones Java fallan en Debian SID por culpa de esto, dando un error de este estilo:

library initialization failed - unable to allocate file descriptor table - out of memoryAborted

En mi caso fueron MPlabX y SimplicityStudio las que me dieron problemas, pero parece que ocurre con muchas más aplicaciones Java, y en concreto Android Studio también lo da.

Según una entrada en github, el problema se debe a que Java toma el número máximo de descriptores que se pueden abrir y reserva un bloque de memoria lo suficientemente largo como para albergarlos a todos. Hasta ahora ese número era 4096, con lo que con 16 Kbytes tenía de sobra. Pero tras un cambio en Systemd (pedido, además, por la gente del kernel) dicho número se ha ampliado a 262144 (256 * 1024). En principio esto no debería ser problema (sigue siendo una cifra razonable, y con un mega puede almacenarlo todo), pero, por una serie de desafortunadas circunstancias, Java no recibe esa cifra en Debian SID, sino que, si no hay configurado ningún límite, recibe INFINITY (los detalles se pueden seguir en este hilo de github). El resultado, obviamente, es un error de memoria insuficiente.

Mientras el error no se corrige, es posible parchearlo temporalmente añadiendo esta línea a /etc/security/limits.conf:

    *   hard   nofile   4096

No olvidarse del asterisco al principio. Y en caso de que 4096 no sean suficientes descriptores, se puede aumentar. Un valor máximo razonable es 1048576. Una vez modificado es necesario cerrar la sesión y volver a entrar (o bien reiniciar) para que los cambios surtan efecto.

Por supuesto es bueno revisar de vez en cuando si ya han corregido el bug, y eliminar esa línea cuando ya no sea necesaria.