Archive for the 'Programación' Category

Usando DBus desde lenguaje C y JavaScript

viernes, diciembre 11th, 2015

Trabajar con DBus desde Python o Vala es muy sencillo: esconden la complejidad del protocolo de manera que uno tiene la ilusión de estar haciendo una llamada local. Sin embargo, históricamente, trabajar con DBus desde C ha sido considerado un peñazo de dimensiones colosales. Sin embargo, desde la llegada de la biblioteca GDBus, que integra DBus dentro de GIO la cosa se ha simplificado bastante, sobre todo en aquellos casos en los que simplemente queremos llamar de manera síncrona a un método remoto.

Debido a algunos cambios que estuve haciendo en Panther Launcher, necesité poder hacer precisamente eso: llamar a un método remoto mediante DBus desde C, para implementarlo dentro del applet para Gnome Flashback. Dado que no encontré documentación sencilla para este detalle concreto (esto es, sin usar entre medias un bucle de eventos), voy a comentar como lo hice, por si le es útil a alguien más.

Lo primero que necesitamos para poder llamar a un método remoto mediante DBus es la interfaz correspondiente donde se define dicho método. Esta interfaz se puede obtener de manera muy sencilla mediante dbus-send y las capacidades de introspección de DBus:

dbus-send --session --type=method_call --print-reply --dest=com.rastersoft.panther.remotecontrol /com/rastersoft/panther/remotecontrol org.freedesktop.DBus.Introspectable.Introspect

En este ejemplo obtenemos las interfaces disponibles en el objeto  /com/rastersoft/panther/remotecontrol, del servicio  com.rastersoft.panther.remotecontrol. El resultado es éste:

freedesktop.DBus.Introspectable.Introspect
method return time=1449871353.404951 sender=:1.1222 -> destination=:1.1246 serial=104 reply_serial=2
 string "<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
<!-- GDBus 2.46.2 -->
<node>
 <interface name="org.freedesktop.DBus.Properties">
   <method name="Get">
     <arg type="s" name="interface_name" direction="in"/>
     <arg type="s" name="property_name" direction="in"/>
     <arg type="v" name="value" direction="out"/>
   </method>
   <method name="GetAll">
     <arg type="s" name="interface_name" direction="in"/>
     <arg type="a{sv}" name="properties" direction="out"/>
   </method>
   <method name="Set">
     <arg type="s" name="interface_name" direction="in"/>
     <arg type="s" name="property_name" direction="in"/>
     <arg type="v" name="value" direction="in"/>
   </method>
   <signal name="PropertiesChanged">
     <arg type="s" name="interface_name"/>
     <arg type="a{sv}" name="changed_properties"/>
     <arg type="as" name="invalidated_properties"/>
   </signal>
 </interface>
 <interface name="org.freedesktop.DBus.Introspectable">
   <method name="Introspect">
     <arg type="s" name="xml_data" direction="out"/>
   </method>
 </interface>
 <interface name="org.freedesktop.DBus.Peer">
   <method name="Ping"/>
   <method name="GetMachineId">
     <arg type="s" name="machine_uuid" direction="out"/>
   </method>
 </interface>
 <interface name="com.rastersoft.panther.remotecontrol">
   <method name="DoPing">
     <arg type="i" name="v" direction="in"/>
     <arg type="i" name="result" direction="out"/>
   </method>
   <method name="DoShow">
   </method>
 </interface>
</node>

Vemos que aparecen varias interfaces, dentro de cada una varios métodos, y dentro de cada método puede haber cero o más parámetros, y cero o más valores devueltos. Para nuestros propósitos no vamos a necesitar todo, sino sólo la interfaz com.rastersoft.panther.remotecontrol, así que eliminaremos el resto de entradas (y las líneas superiores descriptivas, sólo queremos el XML), y nos quedará esto:

<node>
 <interface name="com.rastersoft.panther.remotecontrol">
   <method name="DoPing">
     <arg type="i" name="v" direction="in"/>
     <arg type="i" name="result" direction="out"/>
   </method>
   <method name="DoShow">
   </method>
 </interface>
</node>

Este fichero XML es el que describe las llamadas que vamos a implementar.

Si queremos llamar a alguno de estos métodos desde JavaScript (por ejemplo, para hacer una llamada desde una extensión de Gnome Shell), sólo necesitaremos hacer lo siguiente:

const Gio = imports.gi.Gio;

const MyIface = '<node>\
 <interface name="com.rastersoft.panther.remotecontrol">\
  <method name="DoShow" />\
  <method name="DoPing" >\
   <arg name="n" direction="in" type="i"/>\
   <arg name="response" direction="out" type="i"/>\
  </method>\
 </interface>\
</node>';

const MyProxy = Gio.DBusProxy.makeProxyWrapper(MyIface);

let instance = new MyProxy(Gio.DBus.session, 'com.rastersoft.panther.remotecontrol','/com/rastersoft/panther/remotecontrol');
instance.DoShowSync();
instance.DoPingSync(0);

Primero importamos Gio para tener acceso a GDBus. Después insertamos el XML con la interfaz en una variable, y creamos un Proxy DBus con ella. Finalmente, cada vez que queramos acceder a un objeto (en este caso /com/rastersoft/panther/remotecontrol) de un servicio DBus (en este caso com.rastersoft.panther.remotecontrol), sólo tenemos que crear una instancia del proxy anterior, el cual nos permitirá llamar a los métodos definidos en la interfaz.

Cabe recalcar que aquí estoy llamando a los métodos con su nombre terminado en Sync. Eso significa que la llamada será bloqueante, y no retornará hasta que se reciba la respuesta del otro extremo. Es posible hacer llamadas asíncronas, pero no lo he investigado y no voy a entrar ahí.

Hasta aquí JavaScript, que es la parte más sencilla. Ahora llega el turno de como hacer esto mismo desde C.

GDbus tiene un generador de código que nos simplifica el trabajo. Para usarlo basta con grabar en un fichero el XML anterior (por ejemplo, remotecontrol.xml) y llamar a gdbus-codegen para que construya el código necesario para poder llamar a dichos métodos:

gdbus-codegen --c-generate-object-manager --generate-c-code dbus remotecontrol.xml

Este comando creará dos ficheros: dbus.c y dbus.h (se utiliza el nombre indicado en –generate-c-code) a partir del fichero remotecontrol.xml. Existen algunos parámetros extra, como –c-namespace, que permite especificar un prefijo para todas las funciones que se generen, y así evitar choques de nombres.

En dichos ficheros tendremos un montón de código ya escrito, y es precisamente este código el que nos simplifica el proceso, pues no tendremos que escribirlo nosotros. Una vez que lo tenemos, sólo hemos de llamarlo así:

#include "dbus.h"

GError *error = NULL;

ComRastersoftPantherRemotecontrol *proxy;

proxy = com_rastersoft_panther_remotecontrol_proxy_new_for_bus_sync (G_BUS_TYPE_SESSION,
                                                  G_DBUS_PROXY_FLAGS_NONE,
                                                  "com.rastersoft.panther.remotecontrol",
                                                  "/com/rastersoft/panther/remotecontrol",
                                                  NULL, /* GCancellable */
                                                  &error);
if (proxy != NULL) {
    error = NULL;
    retval = com_rastersoft_panther_remotecontrol_call_do_show_sync(proxy,NULL,&error);

    ...

    error = NULL;
    gint value;
    retval = com_rastersoft_panther_remotecontrol_call_do_ping_sync(proxy,0,&value,NULL,&error);
}

Tras incluir el fichero dbus.h para disponer de las llamadas, lo primero que hacemos es crear un puntero de tipo GError para recibir las excepciones que se produzcan.

A continuación creamos de manera síncrona un proxy de la interfaz concreta que queremos utilizar. Vemos que lo estamos haciendo para el bus de sesión, para el objeto /com/rastersoft/panther/remotecontrol del servicio com.rastersoft.panther.remotecontrol. Es fundamental que el puntero GError esté inicializado a NULL, pues de no hacerlo la llamada fallará.

Y una vez que tenemos dicho proxy ya podemos llamar a los métodos remotos. Vemos que cada llamada está formada por el nombre de la interfaz, más _call_, más el nombre del método, y en este caso, como la llamada queremos que se bloquee hasta que llegue la respuesta, termina en _sync. El primer parámetro es el proxy, y los dos últimos un puntero a la función para cancelar la llamada (que ponemos a NULL para no complicarnos la vida) y un puntero a GError, que también debe estar inicializado a NULL antes de llamar a la función.

Entre medias se introducen, en el mismo orden en que están definidos en el XML, los parámetros de entrada (que se pasan por valor) y punteros para los parámetros de salida.

Para compilarlo hay que utilizar pkg-config gio-2.0 gio-unix-2.0 para que se añadan las cabeceras y bibliotecas necesarias.

Y ya está, con esto podemos por fin llamar de manera sencilla un método DBus desde lenguaje C.

Peleandome con Python 3.4

jueves, julio 30th, 2015

Dado que quiero tener soporte para gnutls, tuve que cambiar el USE de mi distribución a:

USE="${ARCH} -pam -fortran -sanitize -iptables -static -systemd -mdev gnutls internal-glib -caps -filecaps -X -gtk -qt -tk"

Las siete últimas adiciones fueron para no añadir nada de entorno gráfico (pues no tiene sentido en el WebTV) y para asegurar de que las nuevas bibliotecas necesarias para incluir gnutls se puedan compilar. Hubo varios problemillas, pero uno a uno los fui resolviendo.

Por desgracia, el último escollo estaba en python. Cuando compilé el sistema la versión estable era la 3.3, pero ahora ya salió la 3.4. El problema es que se negaba a compilar, dando un error raro:

Python build finished successfully!
The necessary bits to build these optional modules were not found:
    _tkinter
To find the necessary bits, look in setup.py in detect_modules() for the module's name.
Failed to build these modules:
    _socket               _ssl

Decía que se había compilado correctamente, pero emerge devolvía un error. Al principio pensaba que el problema estaba en tkinter, el módulo gráfico de python, pero no tenía sentido porque había especificado que no quería ni tk, ni X ni nada relacionado con un entorno gráfico. Entonces, revisando el log, vi que en medio de la compilación había este error:

/tmp/portage/dev-lang/python-3.4.3/work/Python-3.4.3/Modules/socketmodule.o
/tmp/portage/dev-lang/python-3.4.3/work/Python-3.4.3/Modules/socketmodule.c: In function 'makesockaddr':
/tmp/portage/dev-lang/python-3.4.3/work/Python-3.4.3/Modules/socketmodule.c:1175:14: error: dereferencing pointer to incomplete type
         if (a->can_ifindex) {
              ^
/tmp/portage/dev-lang/python-3.4.3/work/Python-3.4.3/Modules/socketmodule.c:1176:32: error: dereferencing pointer to incomplete type
             ifr.ifr_ifindex = a->can_ifindex;
                                ^
/tmp/portage/dev-lang/python-3.4.3/work/Python-3.4.3/Modules/socketmodule.c:1183:38: error: dereferencing pointer to incomplete type
                                     a->can_family);
                                      ^
/tmp/portage/dev-lang/python-3.4.3/work/Python-3.4.3/Modules/socketmodule.c: In function 'getsockaddrlen':
/tmp/portage/dev-lang/python-3.4.3/work/Python-3.4.3/Modules/socketmodule.c:1802:28: error: invalid application of 'sizeof' to incomplete type 'struct sockaddr_can'
         *len_ret = sizeof (struct sockaddr_can);
                            ^
building '_ssl' extension

¿CAN? ¿En el módulo de sockets? Bastante raro. Rebuscando encontré que, efectivamente, desde el núcleo 2.6.25 hay soporte para el bus CAN; sin embargo, mi núcleo (y sus cabeceras) es el 2.6.22. ¿Por qué se empeñaba en incluir soporte? Por otro lado, python 3.3 también trae de serie soporte para bus CAN, pero esa versión sí compilaba bien. ¿Qué estaba pasando?

Al final descubrí que el núcleo 2.6.22 tiene algo de soporte del bus CAN, pero parece que no el suficiente, y eso lía a python 3.4.

La solución que encontré fue editar el fichero /usr/include/bits/socket.h, y comentar la línea donde se define AF_CAN:

//#define AF_CAN PF_CAN

Y con eso, por fin, pude compilar absolutamente todo, listo para empezar a preparar el sistema que va a llevar definitivamente.

Generando Gentoo para el WebTV

domingo, julio 19th, 2015

Nota: actualizado el parche para BusyBox.

Estos días estoy bastante liado con el trabajo-que-paga-las-facturas, pero por suerte he podido sacar un rato para cacharrear. Me he puesto con el WebTV (que tengo bastante abandonado desde que me compré la Raspberry Pi) y he decidido intentar meter un sistema “decente”. ¿A qué me refiero? Pues a que, por defecto, la máxima versión de Debian que puede correr es wheezy, que ya es old-stable. La estable actual (jessie) necesita un núcleo más reciente, y se niega a trabajar con el que trae el WebTV (2.6.22).

Ante esto decidí probar con Gentoo, a ver si conseguía compilarlo todo. A continuación indicaré como lo hice.

NOTA: para los que no quieran leerse este tocho, en mi web está disponible este entorno Gentoo completo para WebTV, ya compilado y listo para usar.

Para empezar, me bajé la stage 3 de Gentoo para X86_64, bajé también la última lista de paquetes de portage, y descomprimí ésta última en /usr de la stage 3. Con ello ya pude lanzar un contenedor de gentoo con

sudo systemd-nspawn -D /directorio/con/la/stage3 /bin/bash

Aquí toca primero preparar el sistema para hacer crossdev. Esto se puede repasar en una entrada anterior: Emergiendo.

Una vez dentro intenté hacer un crossdev para compilar una gentoo para mipsel usando

crossdev --kernel 2.6.22 -t mipsel -v

Por desgracia fallaba: se empeñaba en utilizar las cabeceras de la versión 2.4.36. ¿Qué pasaba? Pues que aunque en los repositorios de Gentoo sí existen las cabeceras del kernel 2.6.22, éstas no están disponibles en la lista de ebuilds de portage.

Ante esto empecé a buscar y probar, y finalmente con la ayuda de la gente de IRC del canal #Gentoo-kernel conseguí el ebuild de las cabeceras para la versión 2.6.22-r2. Sin embargo tuve que grabarlo en /usr/portage/sys-kernel/linux-headers con el nombre linux-headers-2.6.22-r3, pues la R3 es la versión disponible en el repositorio.

Tras ello actualicé el fichero Manifest para que encontrase el nuevo ebuild con

ebuild /usr/portage/sys-kernel/linux-headers/linux-headers-2.6.22-r3.ebuild manifest

Probé de nuevo a generar el crossdev pero seguía intentando usar la versión 2.4.36… porque la versión 2.6.22-r3 es posterior a la 2.6.22 a secas. Cambiando el parámetro en crossdev solucionó el problema.

crossdev --kernel 2.6.22-r3 -t mipsel -v

Por desgracia, ahora me encontraba con otro: ocurría un error durante la instalación de las cabeceras:

HOSTCC  scripts/unifdef
scripts/unifdef.c:209:25: error: conflicting types for 'getline'
 static Linetype         getline(void);
                         ^
In file included from scripts/unifdef.c:70:0:
/usr/include/stdio.h:678:20: note: previous declaration of 'getline' was here
 extern _IO_ssize_t getline (char **__restrict __lineptr,
                    ^
scripts/Makefile.host:118: recipe for target 'scripts/unifdef' failed
make[1]: *** [scripts/unifdef] Error 1
Makefile:927: recipe for target 'headers_install' failed
make: *** [headers_install] Error 2
emake failed

Tocaba buscar más soluciones. Afortunadamente esta era sencilla: bastaba con editar el fichero unifdef.c y sustituir todas las ocurrencias de getline por otra cosa, como por ejemplo get_line. Preparé el siguiente parche para ello:

--- a/scripts/unifdef.c
+++ b/scripts/unifdef.c
@@ -206,7 +206,7 @@ static void             done(void);
 static void             error(const char *);
 static int              findsym(const char *);
 static void             flushline(bool);
-static Linetype         getline(void);
+static Linetype         get_line(void);
 static Linetype         ifeval(const char **);
 static void             ignoreoff(void);
 static void             ignoreon(void);
@@ -512,7 +512,7 @@ process(void)
 
 	for (;;) {
 		linenum++;
-		lineval = getline();
+		lineval = get_line();
 		trans_table[ifstate[depth]][lineval]();
 		debug("process %s -> %s depth %d",
 		    linetype_name[lineval],
@@ -526,7 +526,7 @@ process(void)
  * help from skipcomment().
  */
 static Linetype
-getline(void)
+get_line(void)
 {
 	const char *cp;
 	int cursym;

Y entonces me encontré con el problema de como aplicarlo durante la generación del crossdev. La cosa no era sencilla, porque se empeña en comprobar los valores de sha256, sha512 y whirlpool de todo lo que baje. En teoría se pueden añadir parches manualmente en /etc/portage/patches, pero tras probar de todo no conseguí que funcionase, así que al final fui a la solución cazurra y metí el comando de parcheado directamente en el ebuild. Para ello edité el fichero /usr/portage/sys-kernel/linux-headers/linux-headers-2.6.22-r3.ebuild y lo dejé como sigue:

# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/sys-kernel/linux-headers/Attic/linux-headers-2.6.22-r2.ebuild,v 1.11 2008/04/12 22:24:36 vapier dead $

ETYPE="headers"
H_SUPPORTEDARCH="alpha amd64 arm cris hppa m68k mips ia64 ppc ppc64 s390 sh sparc x86"
inherit kernel-2
detect_version

echo ${PV}
echo ${PATCH_VER}

PATCH_VER="3"
SRC_URI="mirror://gentoo/gentoo-headers-base-${PV}.tar.bz2"
[[ -n ${PATCH_VER} ]] && SRC_URI="${SRC_URI} mirror://gentoo/gentoo-headers-${PV}-${PATCH_VER}.tar.bz2"

KEYWORDS="-* alpha amd64 arm hppa ia64 m68k mips ppc ppc64 s390 sh sparc x86"

DEPEND="dev-util/unifdef"
RDEPEND=""

S=${WORKDIR}/gentoo-headers-base-${PV}

src_unpack() {
        unpack ${A}
        cd "${S}"
        [[ -n ${PATCH_VER} ]] && EPATCH_SUFFIX="patch" epatch "${WORKDIR}"/${PV}
        patch -p1 < /getline.patch
}

src_install() {
        kernel-2_src_install
        cd "${D}"
        egrep -r '[[:space:]](asm|volatile|inline)[[:space:](]' .
        headers___fix $(find -type f)
}

src_test() {
        make ARCH=$(tc-arch-kernel) headers_check || die
}

Luego copié el texto del parche en el fichero /getline.patch y actualicé de nuevo el manifest. Ahora, siempre que se intente instalar el paquete, se parcheará correctamente.

A intentarlo otra vez… y otra vez falla, esta vez porque la versión 2.20 de glibc necesita, al menos, un kernel 2.6.32. Como el núcleo disponible es el que es, toca probar con una versión anterior. La 2.19r1 fue suficiente:

crossdev --kernel 2.6.22-r3 --l 2.19-r1 -t mipsel -v

Finalmente, con esto ya es capaz de compilar glibc. Ahora vienen las curvas, porque no es capaz de compilar el soporte de Fortran para el GCC, ni las pruebas sanity ni algunas cosas más, así que toca armarse de paciencia e ir probando opciones de USE hasta que todo compile. El resultado final es que hay que usar la siguiente línea (añadí el -X para reducir las dependencias, pues en el WebTV no es necesario):

USE="-fortran -sanitize -X" CFLAGS="-O2 -pipe" crossdev --kernel 2.6.22-r3 --l 2.19-r1 -s4 -t mipsel -v

Inicializamos los wrappers de compilación cruzada…

emerge-wrapper --target mipsel-unknown-linux-gnu --init

Y ya tenemos el sistema de compilación cruzada para MIPSel. Ahora toca configurar el entorno y preparar el sistema. Para ello lo primero es borrar el enlace /usr/mipsel-unknown-linux-gnu/etc/portage/make.profile (que, por defecto, apunta a /usr/portage/profiles/embedded) y sustituirlo por uno que apunte a /usr/portage/profiles/ default/linux/mips/13.0/mipsel.

Una vez hecho esto editamos /usr/mipsel-unknown-linux-gnu/etc/portage/make.conf, y ahí modificamos la línea donde se define el USE para añadir, al menos, -fortran -sanitize -X -iptables. También podemos añadir, opcionalmente, un MAKEOPTS=”-jX” (siendo X el número de núcleos de nuestro procesador más uno), para que la compilación sea más rápida.

También tenemos que editar el fichero /usr/mipsel-unknown-linux-gnu/etc/portage/package.mask, y añadir estas líneas:

>sys-libs/glibc-2.19-r1
>sys-kernel/linux-headers-2.6.22-r3

Con ellas evitamos que instale versiones posteriores de ambos paquetes, que harían que el sistema dejase de funcionar en nuestro WebTV.

Con esto ya podemos intentar generar nuestro sistema base con

emerge-mipsel-unknown-linux-gnu system

Si falla al compilar Busybox, es probable que haya alguna opción que no le gusta. En ese caso hay que editar su fichero .ebuild en /usr/portage/sys-apps/busybox/busybox-X.Y.Z.ebuild, añadir las opciones de configuración que se quieren activar o desactivar, y luego ejecutar ebuild /usr/portage/sys-apps/busybox/busybox-X.Y.Z.ebuild manifest para actualizar el manifest. En mi caso, el problema es que se activan por defecto el soporte de UBIFS y de I2C, cosa que no parece gustarle, así que para eliminarlo tuve que añadir las siguientes líneas en el sitio adecuado del ebuild:

busybox_config_option n I2CGET
busybox_config_option n I2CSET
busybox_config_option n I2CDUMP
busybox_config_option n I2CDETECT
busybox_config_option n UBIATTACH
busybox_config_option n UBIDETACH
busybox_config_option n UBIMKVOL
busybox_config_option n UBIRMVOL
busybox_config_option n UBIRSVOL
busybox_config_option n UBIUPDATEVOL

Con suerte, en un par de días este parche ya estará incluido en los repositorios oficiales.

Otro problema, esta vez más grave, es con Perl: se trata de un paquete al que no le gusta que le hagan compilación cruzada. El resultado es que, simplemente, no podemos instalarlo así. La solución consiste en, de momento, hacer creer al sistema que sí está instalado, e instalarlo manualmente desde el sistema final una vez que ya estamos en el equipo. Para hacer esto basta con editar el fichero /usr/mipsel-unknown-linux-gnu/etc/portage/profile/package.provided y poner, en cada línea, los paquetes que queremos marcar como instalados. Hice lo mismo con los paquetes de UDev, que tampoco los necesito. En mi caso su contenido fue:

dev-lang/perl-5.22
virtual/perl-Data-Dumper-2.158.0
perl-core/File-Temp-0.230.400-r1
virtual/perl-File-Temp-0.230.400-r3
dev-perl/Text-Unidecode-1.230.0
dev-perl/libintl-perl-1.240.0
virtual/perl-File-Spec-3.560.0
dev-perl/Unicode-EastAsianWidth-1.330.0-r1
sys-fs/udev-222
virtual/udev-217
sys-fs/udev-init-scripts-30
virtual/dev-manager-0

Pero, obviamente, depende de la versión de portage y de los paquetes disponibles.

Tras instalar todo esto, si el equipo es de 64 bits nos encontraremos con que nos ha metido varios elementos de python en /usr/lib64, cuando todo debería ir en /usr/lib. Es por esto que debemos mover todos los ficheros del primero al segundo.

Ahora ya podemos copiar el contenido de /usr/mipsel-unknown-linux-gnu/ a un disco duro externo (dentro de una carpeta llamada bg_apps), añadir un fichero init y otro vacío llamado no_base_system, y ya podemos arrancar nuestro sistema Gentoo en el WebTV.

Pero aún no hemos acabado. Para empezar, es necesario hacer el siguiente enlace cada vez que se encienda el equipo:

ln -s /proc/self/fd /dev/fd

para que emerge funcione correctamente. También es recomendable editar el fichero /etc/portage/make.conf y eliminar la opción de compilación -pipe, pues consume más memoria, y en un equipo relativamente limitado como el WebTV nos puede dar problemas con compilaciones muy tochas.

Por otro lado, tenemos que comentar las entradas de Perl que pusimos en el fichero /usr/mipsel-unknown-linux-gnu/etc/portage/profile/package.provided, y procer a instalarlos todos con emerge.

No hay que olvidar que, debido a la gran cantidad de ficheros que tiene el directorio /usr/portage, el arranque de la sesión en segundo plano del WebTV tardará bastante tiempo (en torno a un minuto), pues antes de lanzar la sesión, el sistema revisa todos y cada uno de los ficheros para asegurarse de que no hay “cosas raras”.

Tamaño constante en GTK

sábado, septiembre 6th, 2014

Hace unos días envié un parche para Slingshot, el lanzador de aplicaciones de Elementary OS. El problema que tenía es que tenía fijados al pixel los tamaños de todos los elementos. Esto se adapta bien si se utiliza el tema de Elementary y, además, en lengua inglesa. Sin embargo, en el momento en que se utiliza otro tema, o bien una lengua en la que alguna categoría de programas sea mucho más larga que en inglés, nos encontraremos con que el conjunto de iconos queda recortado por la derecha:

Se supone que esto no debería ocurrir porque Gtk permite crear interfaces que se redimensionen de manera automática, sin embargo en slingshot esto no ocurría. El motivo es que los iconos no están hechos con un Gtk.IconView, sino con botones dentro de un Gtk.Grid. Pero los autores querían, además, que dichos botones tuviesen un tamaño fijo de 130×130 pixels exactamente, por lo que la única idea que se les ocurrió fue fijar el tamaño exacto de la ventana que contiene todo el lanzador, incluyendo la lista de categorías, el buscador, etc. El motivo de hacerlo así es que dentro de cada botón hay, además del icono, una etiqueta con el nombre de la aplicación, y salvo que el contenedor tenga un tamaño determinado, la etiqueta intentará expandirse todo lo que pueda, y ni siquiera sirve de nada pedir un tamaño deseado, porque si el texto en la etiqueta es más largo, la etiqueta se expandirá todo lo que pueda para contener todo el texto.

La primera idea que se me ocurrió fue engancharme a la señal size_allocate del botón. Esta señal se emite cada vez que un widget cambia de tamaño por el motivo que sea, y recibe como parámetro sus nuevas medidas. Con ella y la propiedad max_width_chars intenté limitar el tamaño de la etiqueta para que el botón tuviese el tamaño máximo deseado; por desgracia era un proceso relativamente lento y que, además, provocaba un parpadeo en la ventana, pues ésta primero tomaba el valor máximo y se reducía progresivamente hasta el tamaño correcto, a medida que las distintas etiquetas iban reduciendo su número de caracteres.

La segunda idea, sugerida por la gente de la lista de desarrollo de Gtk, fue encapsular la etiqueta dentro de un Gtk.Fixed, pues permite ajustar manualmente el tamaño de cualquier widget situado en su interior. Esta solución casi funcionó, pues aunque la etiqueta se mantenía en el ancho deseado, el Gtk.Fixed contenedor se redimensionaba hasta ocupar el mismo espacio que ocuparía la etiqueta si estaba sola.

Ante esto me di cuenta de que la solución iba a necesitar de algo más de investigación y, sobre todo, de meterme en los entresijos del renderizado de Gtk, así que empecé a investigar, y descubrí que todo widget tiene dos métodos que participan de manera especial en la asignación de tamaño: get_preferred_width y get_preferred_height. Estos dos métodos devuelven dos valores: el primero es el tamaño mínimo que necesita dicho widget en el eje correspondiente para mostrar su contenido, y el segundo el tamaño deseado. En el caso de una etiqueta, el tamaño deseado será el ancho que ocupe la totalidad del texto puesto en una única línea, mientras que el tamaño mínimo dependerá de varias opciones: si no hay elipsis de texto coincidirá con el tamaño deseado, pero si no, será menor, de lo necesario para pintar el borde y unos puntos suspensivos.

Cuando un contenedor tiene en su interior otro widget, llama a estos dos métodos para saber cuanto espacio debe reservar. Lo interesante es que dichos valores son, realmente, orientativos, pues el contenedor puede asignar otros tamaños si así lo considera oportuno. Así, si una etiqueta pide 100 pixels pero está en una ventana que mide 200 y tiene activo el flag de expandirse, el tamaño final de la etiqueta será de 200. De igual forma, si una etiqueta pide un tamaño deseado de 100 pixels de ancho pero la ventana mide 50, recibirá 50 y el texto tendrá que ocupar varias líneas.

Ante esto se me ocurrió probar qué ocurriría si creo una nueva clase que herede de Gtk.Label, en la que redefino (override) el método get_preferred_width para que devuelva 120 como ancho mínimo y deseado (porque cada botón tiene un margen de 5 pixels por cada lado). El resultado es justo el deseado: la etiqueta mide exactamente el ancho que se le indica, y aplica las reglas para pasar a nuevas líneas o para añadir elipsis.

Por supuesto esto es fácil de hacer en Vala; en C es posible hacerlo también, pero obliga a meterse en el interior de GObject, una tarea que, sinceramente, no me llama demasiado en este momento.

Cagándola con un bug grave

domingo, agosto 10th, 2014

A veces a uno se le escapan pequeños bug que, en principio, no tienen la menor importancia, hasta que resulta que sí la tienen. Eso me ha ocurrido con la nueva versión en desarrollo de DevedeNG.

El bug ni siquiera era tal, sino más bien una combinación de valores por defecto poco adecuados, mensajes poco claros, y código que hacía demasiadas cosas. Básicamente, DevedeNG necesita una carpeta vacía donde crear el proyecto, así que le pide al usuario que le indique una. Si dicha carpeta ya existe le indica que va a proceder a borrarla, dejándole escoger si quiere continuar o cancelar antes de hacerlo.

Hasta aquí todo parece normal. El problema es que la carpeta por defecto era la carpeta personal del usuario, y el mensaje de aviso decía simplemente: “La carpeta seleccionada ya existe. Si continúa, será borrada. ¿Continuar?”. Este mensaje no es lo suficientemente claro porque en ninguna parte aparece qué carpeta se va a borrar. Ante esto, un usuario que se limite a pulsar Siguiente->Siguiente->Siguiente se encontrará con su carpeta personal borrada.

El código ya está corregido, para lo que he aplicado las siguientes lecciones aprendidas:

  • Debe evitarse utilizar la carpeta de usuario ($HOME) como destino por defecto cuando haya que realizar alguna acción que borre una carpeta. En el caso de DevedeNG, el primer cambio fue que la carpeta destino se componga de la carpeta escogida por el usuario más el nombre del proyecto, por lo que, por defecto, nunca será la carpeta de usuario sola la escogida para ser borrada.
  • Siempre que se le pida al usuario confirmación para borrar una carpeta debe mostrarse claramente en el texto qué carpeta se va a borrar. Nunca se debe dar por supuesto que el usuario lo sabe.
  • En la medida de lo posible no debe borrarse la carpeta al completo, sino buscar qué ficheros y directorios son los que pueden interferir con el proceso que se quiere realizar, borrando exclusivamente esos y ninguno más.

Afortunadamente, el usuario que se tropezó con este problema tenía copia de seguridad, por lo que todo quedó en un susto.

XCB y Cairo

sábado, septiembre 28th, 2013

Actualizado: Por fin he terminado la primera versión usable de TabletWM y TabletLauncher. Con ellos y el driver para la pantalla táctil he conseguido el gran objetivo de poder utilizar aplicaciones GNU/Linux nativas en una tablet sin teclado ni ratón.

Crear TabletWM fue, sin duda, la parte más compleja, porque supuso trabajar con un API completamente nuevo, como es XCB. Tenía claro que no quería utilizar XLib, así que me lié la manta a la cabeza, pero partiendo de un gestor de ventanas muy, pero que muy básico hecho por Cinolt a finales de 2011.

Lo primero que aprendí es que el protocolo X es lento, por lo que en un dispositivo como una tablet, con capacidades limitadas, no es recomendable pedir al servidor X las propiedades de una ventana cada vez que se quiere mostrar en pantalla o cambiar sus dimensiones o posición. Sin embargo no parece existir una manera de que el servidor avise al gestor de ventanas de que una propiedad ha cambiado, y dado que estas propiedades contienen información importante necesaria a la hora de mapear una ventana, la mejor solución que encontré fue hacer una caché de datos que relleno en el momento de hacer visible una ventana (en ese momento las propiedades ya tienen que estar definidas), aunque antes puedo haber almacenado otras operaciones que se hayan hecho en la ventana, como un cambio de tamaño o de posición.

Otra cosa que aprendí es que hay dos grupos de eventos de interés para un gestor de ventanas: request y notification. El primero se emite cuando una aplicación pide realizar alguna operación sobre una ventana suya, y la segunda si el resultado de dicha operación cambia algo realmente en la ventana. Así, si una aplicación pide cambiar el tamaño de una ventana, ejecutará un comando xcb_configure_window(). Si no existe un gestor de ventanas, dicho comando se ejecuta normalmente; pero si lo hay, se genera un evento xcb_configure_request en el gestor. Este puede decidir si ignorarlo, ejecutarlo tal cual o modificarlo. Si decide ejecutarlo y el tamaño de la ventana cambia realmente, se emite un evento xcb_configure_notification, que llegará a la aplicación.

Y aquí encontré otro de los problemas que tuve: mi intención es que las ventanas estén maximizadas siempre, por lo que cada vez que recibía un evento xcb_configure_request, emitía un comando xcb_configure_window() con el tamaño máximo de la pantalla. El problema ocurría con algunas ventanas que pedían ser más grandes que la pantalla, por ejemplo la ventana de configuración de Firefox. En este caso, se mostraba la ventana en la primera pestaña, y la pantalla es lo suficientemente grande como para contener todo; al recibir el evento, TabletWM modifica los valores pedidos por el navegador, ajustándolos al tamaño de la pantalla, y cambia las dimensiones de la ventana. Se emite el evento xcb_configure_notification y todo sigue perfectamente.

Pero cuando se escoge la pestaña de Seguridad, el nuevo contenido no entra en la pantalla, por lo que Firefox pide un tamaño más grande. El gestor de ventanas recibe el evento y cambia los parámetros por las dimensiones de la pantalla (que es el mismo tamaño que ya tiene la ventana), y da la orden de cambiar el tamaño. Pero como es el mismo, nunca se genera un evento xcb_configure_notification, pero Firefox espera que le llegue. El resultado es que la ventana queda sin refrescar.

La solución que apliqué fue ejecutar primero el comando de cambio de tamaño tal cual llega, y ejecutar luego un segundo comando con el tamaño que el gestor de ventanas desea. De esa manera la aplicación siempre recibe el evento que espera, y todos felices.

Otra curiosidad fue a la hora de leer ciertas cadenas de texto en las propiedades. En algunos casos, una propiedad (como por ejemplo _XKB_RULES_NAMES) contiene varias cadenas separadas por NUL (o sea, un byte a cero). Si pedimos el tamaño de ésta en la cookie (cookie->length) nos devolverá la longitud de la primera cadena exclusivamente. Si queremos obtener todas tenemos que utilizar xcb_get_property_value_length(), que sí nos dará el tamaño total. Por si fuera poco, no se garantiza que al final de la cadena haya un NUL, por lo que debemos tener en cuenta el tamaño para no pasarnos, en lugar de usar strcpy().

El teclado fue otro de los problemas serios que tuve: el método normal de entrada por teclado de X es relativamente rudimentario, por lo que hoy en día se utiliza la extensión XKB. Por desgracia esta extensión no está portada tal cual a XCB, sino que existe un proyecto separado, XCB-COMMON, que contiene aquellas partes no dependientes de un servidor X. Por si fuera poco, no puedo emular la pulsación de un carácter concreto, sino sólo la pulsación de una tecla en sí. Esto significa que los códigos que tengo que enviar a las X dependerán del idioma del teclado escogido por el usuario, además de tener que emular pulsaciones múltiples como la tecla mayúsculas, AltGR, etc.

Encima, esta biblioteca está orientada a obtener un carácter a partir de una pulsación, cuando yo necesitaba el proceso inverso. Aunque parte del trabajo lo hace (dado un carácter devuelve el código de la tecla), no devuelve el código de los modificadores necesarios. Así, si pido la arroba, me devuelve el código de la tecla ‘2’, pero no me dice si necesito pulsar también las mayúsculas (caso del teclado norteamericano) o AtlGR (caso del teclado español). Esto me obligó a realizar una pequeña chapuza, consistente en probar todas las posibles combinaciones de teclas normales y teclas modificadoras (shift, control, etc) para ver qué caracteres produce cada una.

Y para rizar el rizo, no es posible siempre obtener la combinación correcta, por lo que en algunos casos no queda más remedio que redefinir un código de tecla que no se utilice con un carácter determinado (por ejemplo, la letra Ñ). Esto hay que hacerlo con las funciones de entrada clásicas, no con las de XKB, por lo que el resultado final es algo caótico, pero funciona, y permite definir un teclado cualquiera en pantalla a partir de los caracteres que se quieren mostrar en lugar de las teclas físicas que se deben pulsar.

Pasando a Cairo, decidí utilizar esta biblioteca para los elementos gráficos (como el teclado o la ventana de apagado) en lugar de las funciones de X por varios motivos:

  • Cairo ofrece antialiasing, tanto en fuentes como en primitivas gráficas.
  • Cairo es una biblioteca moderna con un API sencillo y potente.
  • Ya conozco Cairo, pero no las funciones gráficas de X.
  • No supone una carga extra porque el lanzador de aplicaciones utiliza GTK, que por debajo trabaja también con Cairo.

Trabajar con Cairo directamente desde XCB no es muy complicado. Para ello, primero se debe crear una ventana, y a continuación una superficie Cairo con cairo_xcb_surface_create(). La principal complicación es conocer el visual_type de la ventana, para poder pasárselo a la función. Esto lo podemos saber mediante el siguiente código (la variable conn es el handler de la conexión con el servidor X):

    xcb_screen_t *scr=xcb_setup_roots_iterator(xcb_get_setup(conn)).data;
    xcb_visualtype_t *visual_type = NULL;
    xcb_depth_iterator_t depth_iter;

    for (depth_iter = xcb_screen_allowed_depths_iterator (scr); depth_iter.rem; xcb_depth_next (&depth_iter)) {
        xcb_visualtype_iterator_t visual_iter;

        visual_iter = xcb_depth_visuals_iterator (depth_iter.data);
        for (; visual_iter.rem; xcb_visualtype_next (&visual_iter)) {
            if (scr->root_visual == visual_iter.data->visual_id) {
                visual_type = visual_iter.data;
                break;
            }
        }
    }

Luego no tenemos más que engancharnos al evento expose de la ventana (XCB_EVENT_MASK_EXPOSURE) y, cada vez que se reciba, generar un contexto Cairo y repintar la ventana. Un detalle extra a tener en cuenta es que cada vez que se redimensione la ventana es necesario llamar a cairo_xcb_surface_set_size(), para cambiar el tamaño de la superficie Cairo.

Ah, y no olvidar hacer un xcb_flush() al terminar de pintar algo, para que efectivamente lo pinte en la ventana.

Gestion de ventanas

jueves, septiembre 5th, 2013

El siguiente paso lógico en el desarrollo de mi tablet era, obviamente, un gestor de ventanas adecuado. Y es que, aunque hay cienes y cienes de ellos, ninguno se adapta a lo que yo busco, que es:

  • debe maximizar las ventanas por defecto, para que aprovechen siempre toda la pantalla
  • sin decoraciones, para aprovechar al máximo la pantalla
  • que se pueda manejar tanto desde teclado como desde una pantalla táctil

Al final me lié la manta a la cabeza y escribí mi propio gestor: TabletWM. Este gestor está basado en XCB, la biblioteca ligera para XWindows, y sigue, en lo que puede, los estándares ICCCM y EWMH.

Entre las características importantes está la capacidad de distinguir entre las ventanas de una misma aplicación y las de otras, permitiendo recorrer, por ejemplo, sólo las ventanas de GIMP, aunque haya otras aplicaciones lanzadas. La idea es simplificar el uso cuando se trabaja en una tablet.

Ahora sólo me falta crear un lanzador/gestor de aplicaciones, y ya tendré mi sistema tablet listo.

Driver tactil

martes, agosto 27th, 2013

Acabo de terminar la segunda versión completamente funcional del driver para el chip táctil GSL1680 que incorpora mi tablet. Entre las ventajas que tiene están que, además de procesar pulsaciones normales, permite también emular la rueda de desplazamiento del ratón para hacer scroll de una ventana, así como emular zoom-in y zoom-out con el gesto pinch-to-zoom. Por último, también permite hacer click derecho de manera puramente táctil.

El scroll se hace con dos dedos, moviéndolos de manera simultanea. Cuando el driver lo detecta emite eventos wheel y hwheel, que todas las aplicaciones interpretan como scroll. Por otro lado, al detectar un pinch-to-zoom, emite un evento wheel más la tecla CTRL. Esto se interpreta, en general, como zoom (al menos en Firefox, GIMP e InkScape).

El click derecho es el menos intuitivo, pero dado que no es algo se se utilice demasiado, no es tan problemático. Para hacerlo hay que:

  • tocar con un dedo en la pantalla, y mantenerlo.
  • tocar y soltar con otro dedo sin quitar el primer dedo de la pantalla. Esto hace entrar al driver en el modo click derecho
  • mover el primer dedo al punto donde queremos hacer click derecho (lo normal es que ya esté ahí, pero…)
  • tocar y soltar con otro dedo sin quitar el primer dedo de la pantalla.
  • mientras no despeguemos el primer dedo de la pantalla, podemos hacer tantos clicks derechos como queramos en cualquier parte de la pantalla.

Como es algo lioso, sugiero ver este vídeo de demostración del driver. El click derecho se hace en el segundo 5:

Para programar el driver decidí no meterme en fregados, y lo implementé como un driver en espacio de usuario mediante uinput. La principal ventaja es que resulta mucho más sencillo de depurar que un módulo para el kernel, además de permitir hacer cosas más avanzadas, como cargar el firmware directamente, sin necesidad de meter a udev por medio. A nivel técnico, comentar que, en realidad, se crean dos dispositivos, uno de tipo absoluto (pantalla táctil, touchpad…) y otro de tipo relativo (ratón). El motivo es que un mismo dispositivo no puede enviar eventos relativos y absolutos a la vez, pero para el cursor necesitaba eventos absolutos, mientras que para el scroll y el zoom necesitaba relativos.

De momento el código del driver está disponible únicamente en github.

 

Pantalla tactil

jueves, agosto 22nd, 2013

Por fin he conseguido acceder a la pantalla táctil. Esta tablet lleva un controlador GSL1680, para el cual no hay casi documentación. Sin embargo, pude encontrar un presunto driver, y de él sacar mucha información.

Después de muchas pruebas fui capaz de leer las coordenadas, pero sólo si arrancaba Linux en caliente (o sea, si arrancaba primero Android y luego reiniciaba). Si apagaba a machete la tablet y encendía directamente en Linux, no funcionaba.

Tras investigar, descubrí que el motivo es que el chip necesita que le envíen el firmware para funcionar. Si arrancaba Android, éste le metía dicho firmware, y al reiniciar todo seguía funcionando. Pero si apagaba la tablet, al quedarse sin corriente, el firmware se borraba, y es necesario volver a cargarlo.

Encima, parece que el firmware es específico para cada modelo. Afortunadamente, en el caso de mi tablet éste estaba disponible en un fichero de texto, en /system/etc.

Los detalles específicos de programación los he escrito en la página sobre el GSL1680 en linux-sunxi, y como no me apetece repetirlo todo, me limitaré a poner un enlace.

Arrancando Linux en la tablet

lunes, agosto 5th, 2013

Actualizado: Hoy me puse a intentar meter Linux en la tablet de la que hablé en la anterior entrada. Y lo he conseguido, he aquí la prueba:

tablet_linux

Dado que esta tablet está equipada con un Allwinner A13, necesitamos un kernel y un cargador adecuados. Lo interesante de este chip es que no hace falta tocar la flash interna, sino que basta con ponerlos en una tarjeta SD, y arrancará desde ésta directamente. Y si luego queremos volver al sistema original, basta con retirar la tarjeta y reiniciar.

El núcleo y el cargador los podemos obtener del repositorio GIT linux-sunxi, orientado precisamente hacia este tipo de SoCs. Las instrucciones básicas para compilar y generar todo las saqué de la página de Olimex, y las he adaptado a este modelo.

Supondré que tienes una distribución basada en Debian. Lo primero que hay que hacer es instalar los paquetes de compilación cruzada y otras bibliotecas necesarias:

    sudo apt-get install gcc-4.7-arm-linux-gnueabi gcc-4.7-arm-linux-gnueabi-base gcc-arm-linux-gnueabi libncurses5-dev uboot-mkimage build-essential git libusb-dev libusb-1.0-0-dev

Ahora bajamos el u-boot modificado con:

    git clone -b sunxi https://github.com/linux-sunxi/u-boot-sunxi

Entramos en el directorio u-boot-sunxi y compilamos el código:

    cd u-boot-sunxi
    make CROSS_COMPILE=arm-linux-gnueabi- a13-olinuxino
    ls -l u-boot.bin spl/sunxi-spl.bin
    cd ..

Ahora que tenemos compilado el cargador, vamos con el núcleo. Nos lo bajamos desde el repositorio, preparamos una configuración base y entramos en modo configuración:

    git clone -b sunxi-3.0 https://github.com/linux-sunxi/linux-sunxi
    cd linux-sunxi
    make ARCH=arm a13_defconfig
    make ARCH=arm menuconfig

tablet_config

Entre las opciones que he tocado están las siguientes:

  • General Setup
    • POSIX message queues -> Y
  • System Type
    • Emulate SWP/SWPB instructions -> N
  • Device Drivers
    • Network Device Support
      • Ethernet (10 or 100Mbit) -> N
    • Character Devices
      • Non-standard serial port support -> N
      • Serial drivers
        • 8250/16550 and compatible serial support -> N
    • Console Display driver support
      • Map the console to the primary display device -> Y
    • Bootup logo -> Y
  • Security Options
    • Enable the securityfs filesystem -> N

 

Una vez configurado, procedemos a compilar el núcleo:

    make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage
    make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- INSTALL_MOD_PATH=out modules
    make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- INSTALL_MOD_PATH=out modules_install

Ahora llega el momento de generar la tarjeta SD con el sistema básico. Para ello, primero necesitamos dividirla en, al menos, dos particiones, una en formato VFAT (donde irá el núcleo) y otra en formato EXT2/3/4 con el sistema en sí. Así que arrancamos fdisk y empezamos. Es importante que la primera partición empiece, al menos, en el sector 2048, para dejar sitio para el arranque.

Una vez formateadas ambas particiones, descargamos un sistema Debian base, lo descomprimimos en la partición EXT2/3/4 (que supondremos que está montada en /media/particion2) y copiamos los módulos (asumiendo, también, que la versión de núcleo que tenemos es la 3.0.76):

    wget http://rcn-ee.net/deb/rootfs/wheezy/debian-7.1-console-armhf-2013-07-22.tar.xz
    tar xvf debian-7.1-console-armhf-2013-07-22.tar.xz
    sudo tar -C /media/particion2 -xvf debian-7.1-console-armhf-2013-07-22/armhf-rootfs-debian-wheezy.tar
    cd ../linux-sunxi
    sudo cp -a linux-allwinner/out/lib/modules/3.0.76/ /media/particion2/lib/modules/

Es importante descomprimirlo como root para que conserve los nombres de usuario correctos.

Ahora bajamos los ficheros de definición de placas y las utilidades, y las compilamos:

    git clone https://github.com/linux-sunxi/sunxi-boards
    git clone https://github.com/linux-sunxi/sunxi-tools
    cd sunxi-tools
    make

Ahora vamos a generar el fichero script.bin, necesario para configurar el núcleo durante el arranque. Para ello utilizaremos las utilidades que acabamos de compilar y el fichero de configuración a13_mid.fex, situado en el repo sunxi-boards, por ser el más parecido a nuestra tablet:

    ./fex2bin ../sunxi-boards/sys_config/a13/a13_mid.fex script.bin

El siguiente paso consiste en copiar el fichero uImage y script.bin en la partición VFAT de nuestra tarjeta SD:

    cp script.bin /media/particion1
    cd ../linux-sunxi
    cp arch/arm/boot/uImage /media/particion1

Por último sólo queda instalar u-Boot en la tarjeta, para lo cual hacemos (asumiendo que la tarjeta está en /dev/sdX):

    cd ../u-boot-sunxi
    sudo dd if=spl/sunxi-spl.bin of=/dev/sdX bs=1024 seek=8
    sudo dd if=u-boot.bin of=/dev/sdX bs=1024 seek=32

Y con esto ya está. Sólo queda meter la tarjeta SD en la tablet, encenderla, y conectar un teclado USB.

El próximo paso será intentar activar la WiFi, algo que me está dando bastantes quebraderos de cabeza.


Utilizamos cookies para garantizar que tenga la mejor experiencia en nuestro sitio web.