Pues eso, que estoy algo cansado de forzarme a escribir una entrada válida para poner aquí (y no es que las que pongo sean de mucha calidad), así que de momento voy a dejar estar un poco el tema.
No es un cierre absoluto, sino más bien cautelar, ya que iré haciendo eco de mis entradas en Geeks y quizás ponga alguna otra cosa, pero no con la frecuencia habitual…
Pues eso, que hasta luego.
Otra tarea pendiente y que he solucionado a medias consiste en mi Microsoft Wireless Natural Multimedia Keyboard (sí, esos partidos) y su ratón correspondiente. Para decirlo con pocas palabras, simplemente hay que decir que bajo Linux no funciona.
No funciona conectado al puerto PS/2 porque genera una serie de texto basura como consecuencia de lo que yo considero es un bug del núcleo 2.6, pues no contempla las 255 teclas, pero no tengo ganas de meterme en líos. Lo curioso es que conectado mediante USB no presenta ese problema.
Este teclado tiene varias teclas completamente muertas, es decir, que el kernel de linux es incapaz de ver, como la de Messenger, la de Cerrar Sesión o la de Suspender. Pero hay otras que sí que ve pero el sistema se encuentra incapaz de remapear convenientemente.
Y son esas las que vamos a forzar a que funcionen y tengan un cometido. No es necesario decirle a las X qué modelo de teclado tenemos, pero si se lo decimos, algunas de esas teclas ya estarán auto asignadas. Por ello, en mi xorg.conf tengo la línea
Option “XkbModel” “microsoft”
El siguiente paso es localizar los keycodes de dichas teclas. Para ello ejecutamos en una consola el programa “xev”. Si no lo tenemos, lo instalamos mediante
emerge xev
Mientras este programa tenga el foco, nos capturará las teclas y nos dará su código de tecla. Entre todo el texto aparecerá algo como
keycode 240
Eso es lo que necesitamos. El código 240 se corresponde con la tecla de “Mis Documentos” en mi teclado, pero sin embargo la de “Mis Imágenes” no genera ningún código, por lo que no podremos usarla para nada.
Hace tiempo estuve mirando el código fuente del núcleo de linux respecto a este tema, y vi alguna cosa rara pero no me atreví a tocar nada. Lo curioso del tema es que con un núcleo 2.4 funcionan todas, pero con uno 2.6 no, así que me reitero en lo del bug.
El siguiente paso es buscar teclas no asignadas para remapear. Para ello abrimos el fichero /usr/include/X11/keysymdef.h y allí tenemos todos los valores disponibles. En mi caso, y dado que mi teclado sólo llega al F12, he elegido remapear de la F35 hacia abajo.
Remapear una tecla en linux es sencillo: ejecutamos
xmodmap -e ‘keycode <code>=<keyname>’
para asignar un nombre a una tecla que no lo tiene. Por ello, si ejecutamos
xmodmap -e ‘keycode 240=F35′
estaremos diciendo a Linux que la tecla “Mis Documentos” es F35. Y F35 es una tecla válida para asignar allá donde queramos.
Y ahora viene el truco del almendruco, al menos para el KDE. Si tuviéramos que ejecutar esa línea de comandos para cada tecla y cada vez que entremos en el KDE, sería un absurdo, por lo que creamos un fichero de texto con permisos de ejecución con el nombre que queramos y lo situamos en
.kde/Autostart
y dentro de ese fichero colocamos todas nuestras asignaciones, más o menos así:
#! /bin/sh
xmodmap -e ‘keycode 130=F35′
xmodmap -e ‘keycode 129=F34′
…
De este modo, cada vez que iniciemos KDE se nos remapearán esas teclas y podremos usarlas dentro del entorno. Evidentemente, hay más lugares en donde colocar un script para que se autolance, pero en mi caso me vale así.
Otra cosa que debería hacer es reasignar los dos botones laterales del ratón -lo ideal es que se mapearan en combinaciones de teclas-, pero aparte de reordenarlos y de asignar los de la rueda, no he visto nada… Así que si alguien sabe cómo hacerlo, que por favor me lo diga…
No era mi intención iniciar otra serie de entradas sobre el tema de arriba, pero considero que puede resultar interesante, y es en lo que estoy ahorita mismo.
Tras terminar de actualizar nuestra placa con Windows CE, nos surge la obligación de realizar los mismos pasos con Linux, ya que varios de nuestros clientes así nos lo exigen.
No es que esté muy contento con ello, porque por experiencia propia sobrevivir bajo este sistema operativo es toda una odisea -muy a persar de lo que digan los fundamentalistas linuxeros-, principalmente porque para hacer cualquier cosa necesitas leerte diez mil documentos, trastear durante dos horas y al final, si hay suerte, te funcionará. O no.
Para mi va a ser toda una aventura, pues será la primera vez que voy a implentar un sistema embebido que no es un PC y que va a ejecutar Linux en sus tripas.
La primera decisión es qué distribución instalar. Todas las distros populares adolecen del mismo problema: cargan todos los módulos del núcleo, son lentísimas a la hora de cargarse y cuando te sales de lo políticamente correcto no hay asistente y tienes que pelearte con los miles de ficheros de texto.
Por eso he elegido una Gentoo, porque yo lo valgo, porque si uno elige Linux ha de elegir lo mejor y porque me siento cómodo con ella. Además, entro a formar parte del selecto grupo de la gentooza, y cuando me surga un problema, voy a saber dónde tocar, pues asistentes tiene pocos.
Compilar una Gentoo desde un estado 3 es casi una bagatela en un AMD64 X2 con 2 Gb de RAM, eso se come el código fuente a espuertas; tardó apenas cuatro horas a compilar el KDE completo junto al KOffice, KDevelop y KDESdk.
El primer problema surge con los formatos de partición. Mi Windows XP tiene NTFS y mi Gentoo, reiserfs. Y debo por lo menos ver las particiones NTFS desde Linux.
El Kernel 2.6.xx trae soporte de serie para montar particiones NTFS de sólo lectura (También lo trae para escribir en ellas, aunque ni borracho se me ocurriría).
Pero sería estupendo si pudiera escribir en NTFS. Por ejemplo, todo el código fuente de la placa colgaría de las mismas ramas que todo mi código fuente Windows, podría utilizar el Opera como lector de correo y news compartido con Windows (Uitiliza el mismo formato de ficheros).
Así que me lío la manta a la cabeza y… descubro ntfs-3g, un parche al kernel y paquete que permite la escritura sobre NTFS sin problemas… en un sistema x86. El autor de la herramienta dice que no puede probar sobre un sistema de 64 bits porque no tiene, pero a la gente que lo ha hecho le ha ido bien.
Efectivamente, funciona de cine, de momento tengo el Opera compartido y no he observado nada extraño.
Para instalar este soporte en una Gentoo es necesario lo primero de todo desenmascarar el paquete ntfs3g y fuse, por lo que hay que añadir estas dos líneas en /etc/portage/package.keywords:
y luego realizar un “emerge ntfs3g”.
¿Sencillo?
Si hubiera funcionado, sí, pero no funciona.
Estos paquetes dependen de PyQt que presenta un bug que impide compilarlo con la biblioteca glib instalada por defecto y de momento no tiene solución, aunque sí rodeo.
Vamos allá. Tenemos que enmascarar la versión actual, la 3.14.1-r2. Pare ello añadimos la línea
<=dev-python/PyQt-3.14.1-r2
al fichero /etc/portage/package.mask
Pero así no podemos compilar el proyecto. Tenemos que hacernos un “portage overlay”, o sea, crearnos una rama interna del Portage, copiar el paquete y subir una versión, cambiando una serie de cosas en sus ficheros de paquetes.
Primero creamos la rama de carpetas /usr/local/portage/dev-python/PyQt y copiamos todo el contiendo de /usr/portage/dev-python/PyQt. Posteriormente copiamos el fichero PyQt-3.14.1-r2.ebuild como PyQt-3.14.1-r3.ebuild, lo editamos y quitamos la línea del parche de compatibilidad. Luego hacemos un digest sobre el propio fichero.
Pero tenemos que decirle al Portage que tenemos nuestra rama de portage personalizada. Para ello abrimos el fichero /etc/make.conf y añadimos el texto “PORTDIR_OVERLAY=/usr/local/portage” sin las comillas.
Ahora, cuando el sistema pida compilar el PyQt verá que hay una versión superor a las enmascaradas en el repositorio local, y usará ese paquete. Y cuando se actualice y se solucione e bug, como poco se presentará la versión r3 si no una superior, y entonces el sistema actualizará la nueva, a no ser que ésta presente el mismo bug y tengamos que repetir el proceso.
¿Veis lo que quiero decir con lo de sobrevivir?
Seguimos.
Ahora sí que podemos instalar el paquete adecuado. Ya solo nos queda modificar el fstab con el nuevo sistema de ficheros
/dev/partición /punto_montaje ntfs-3g auto,user,uid=1000,rw 0 0
y actualizar el listado de módulos con update_modules. La pega es que cada vez que recompilemos el núcleo debemos regenerar dicho paquete.
Y ahora viene el publicar este post. El Opera se arma la picha un lío con los campos de edición y hace unos desbarajustes de cojones. El Konqueror no entiende el login de Geeks.ms, por lo que mientras escribo este texto en el Kate, compilo el Firefox 2.0, que también he tenido que poner en package.keywords.
Y ya es hora de publicar el post, pero antes tengo que añadir el Firefox a la lista de menús, por lo que tengo que ejecutar el “Actualizador de Menús”… ¿Van entendiendo?
Tengo que copiar el texto desde el Kate, y en el proceso se pierde el formato… con lo que tengo que volver a meter todos los párrafos y las indentaciones y, finalmente, aquí está el post.
Mañana hablaremos sobre cómo hacer funcionar las teclas multimedia… cuando estas no funcionan.
Llevo como tres meses dándole caña al Windows CE 5.0, principalmente como ayuda a uno de nuestros partners tecnológicos, ya que se encuentran desbordados de trabajo y nuestros clientes nos exigen/quieren ciertas actualizaciones y mejoras al desarrollo base, no de las bibliotecas ofrecidas, sino de la propia plataforma y del modo de desarrollar, que ciertamente se abandonó en preferencia a la creación de una biblioteca de clases, puesto que el dispositivo que ahora tenemos es de los denominados no head, o sea, sin vídeo.
No es que nuestra placa no disponga de pantalla, que la tiene, sino que se ha eliminado todo lo relativo al GUI que trae Windows CE de serie y se ha sustituído por una biblioteca gráfica mucho más potente y acorde con el destino del dispositivo, al modo de las Direct X, pero con otros conceptos sobre los cuales no puedo hablar.
Esta entrada quiere ser, pues, un punto de introducción sobre Windows CE y la construcción de sistemas operativos a partir de él. Por lo tanto, comencemos por el principio.
Windows CE es un sistema operativo de tiempo real no estricto, adecuado para ser instalado en multitud de arquitecturas y microprocesadores de 32 bits, que van desde el clásio x86 hasta los modernos ARM 9, XScale, SuperH, y un largo etcétera. Y por si eso fuera poco, Windows CE está compuesto por un sistema modular que ofrece la posibilidad de incluir aquellos componentes que estimemos oportunos.
Además, el coste de la licencia básica es, si no me equivoco, de 4 dólares USA.
El Platform Builder es la herramienta con la que se construye el sistema. Disponemos de un amplísimo catálogo de componentes que podemos ir instalando en nuestro proyecto, para luego pasar a la construcción del sistema operativo en sí. La tarea a simple vista puede parecer trivial, y generalmente lo es, aunque a veces pueden presentarse problemas insospechados.
Por otro lado, el fabricante del microprocesador tiene que suministrarnos lo que se llama la BSP, que es un bloque de código fuente, así como una serie de archivos que instruyen al Platform Builder de la arquitectura y de los recursos disponibles, de forma que la conjunción de estos dos elementos constituye lo único necesario para tener rápidamente un sistema operativo específicamente construido para nuestra placa.
Evidentemente, necesitamos una placa sobre la que ejecutar dicho sistema operativo, y desde mi opinión es el punto más difícil de todos, y requiere buenos ingenieros de hardware dada la complejidad del asunto. Construir una placa para Windows CE no es tarea trivial. Consideremos que una PDA o un teléfono móvil son dos ejemplos tipo, y de hecho ambos ejecutan versiones modificadas de Windows CE, ya que los Windows Mobile no son mas que versiones modificadas de Windows CE, aunque no aparezcan en los catálogos del Platform Builder.
Un dispositivo que ejecute Windows CE permite varios modelos o formas de desarrollo, algunas de ellas casí idénticas -pero con ciertas limitaciones- a las de PC. El marco de trabajo básico es un subconjunto bastante amplio del API de Win32, y sobre él se ejecutan otras bibliotecas como las MFC y otros marcos más modernos, como las versiones Compact del -NET 1.0 y 2.0. Podemos, pues, desarrollar los siguientes tipos de aplicativos:
Podemos comprobar que las posibilidades de desarrollo son enormes. El autor de estas líneas ha realizado proyectos en Win32, MFC y .NET 2.0 en C#, y puede afirmar que el rendimiento, dentro de las características, es muy bueno, sobre todo con lenguajes no tan evidentes como el C#.
En una próxima entrega hablaremos de las diferencias entre programar para PC y para dispositivos embebidos.
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Aug | ||||||
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | ||||||
Get free blog up and running in minutes with Blogsome
Theme designed by Gary Rogers