XMINIX

Bases para la creacin de un servidor grfico de uso general sobre Minix 02-12-09
Integrantes: Manuel Aroz, Santiago Bermdez, Pablo Giorgi, Guido Marucci Blas, Santiago Perez de Rosso, Lucas Pizzagalli, Matas Williams

Introduccin
En este trabajo se busc y se logr crear las bases para una futura implementacin de un servidor X corriendo sobre Minix 2.0.4, con el objetivo de crear una capa sobre la que se puedan basar futuros trabajos y de a poco desarrollar un sistema operativo de uso general y no meramente con fines acadmicos, desarrollado por alumnos del ITBA. Es claro que el objetivo de este trabajo es formar las bases para compartir un trabajo con distintas camadas de Sistemas Operativos. Adems es muy interesante, no solo trabajar sobre el codigo de Minix, sino tambin sobre el cdigo de distintos compaeros, con distintas formas de programar y distintos modelos mentales. Para alcanzar dichos objetivos, se consideraron necesarios los siguientes pilares: - Un slido driver de mouse. - Una simple y extensible librera grfica basada en modo video. - Un nivel aceptable de seguridad del sistema a la hora del manejo de paquetes con otros sistemas. - Una serie de interfaces amigables para que un usuario no experto pueda sentirse ms cmodo al navegar los archivos. Se busc como objetivo tambin integrar numerosos trabajos, antes olvidados. Se busc rescatar lo mejor de cada uno y unirlos en esta gran base para futuros desarrollos.

Features implementadas
Teniendo en cuenta los requisitos planteados previamente, las features implementadas por nuestro equipo fueron acordes. Para algunos se utilizaron trabajos anteriores, que se integraron al nuestro (con algn grado de dificultad y esfuerzo), y para otros se desarrollaron

soluciones propias. El sistema operativo xminix cuenta con las siguientes features agregadas sobre Minix 2.0.4: Driver de video y librera grfica: para esto nos basamos en el trabajo previo desarrollado por Rodrigo Rearden, Eduardo Casal, y Luciano Mangiarotti en la librera xlib, que provee interfaces con la placa de video mediante el estndar de VESA en la BIOS. Cuenta con varias funciones de renderizado de figuras geomtricas (rectas, crculo, puntos, etc.), y de renderizado de imgenes. Driver de mouse: El driver de mouse, se comporta 100% como cualquier driver de minix. Este driver permite leer informacin del mouse de forma exclusiva es decir solo un proceso puede leer informacin del mouse. Para ello debe abrir el archivo especial que se encuentra en /dev/mouse y luego leer de dicho archivo. Sucesivas llamadas a open devolvern error por lo anteriormente mencionado. El read sobre el dispositivo es nobloqueante y cuando hay algo para leer devuelve sizeof(mouseevent_t), que es la estructura que contiene dx, dy, rightClick y leftClick. La funcin que se encarga de manejar la interrupcin del mouse, se fija si el dispositivo fue abierto, y en caso de estarlo se enconlan los eventos para luego ser entregados al read. Renderizado de textos: Se agreg una extensin de la librera xlib para que permita el renderizado de fuentes basadas en bitmap (en las que cada letra es un mapa de bits). Esto permiti el desarrollo de aplicaciones grficas de varios modos, y abre el camino para el desarrollo de muchas otras ms. La extensin de la librera permite renderizar fuentes de mapas de bits en distintos tamaos, colores, y es performante. La librera tambin permite encuadrar textos y wrappearlos al renderizar. Explorador de archivos: el explorador de archivos consiste en una ventana que contiene un fondo de escritorio, una barra de tareas, y los conos (carpetas y archivos) que contiene el directorio en el que estamos. Permite hacer cosas como recorrer el sistema de archivos como en cualquier explorador de directorios, agrandar y achicar el tamao de los conos, subir un nivel, entrar en una carpeta y adems mostrar archivos y carpetas ocultos. Firewall: Se agreg un firewall realizado por alumnos de la cursada pasada que posee, entre otras cosas, filtrado por MAC. Manejo de archivos ocultos: Se modific el sistema de archivos utilizado por Minix 2.0.4. Esto se realiz segn el informe y trabajo entregado por Villegas Patlis, Ezequiel. Este modifica levemente el sistema de archivos de minix V2 para que tenga soporte para archivos ocultos. Se logra modificando la estructura interna del inodo, modificando el tamao del arreglo de zona de direccionamiento de los bloques, y utiliza este espacio libre para agregar propiedades sobre el ocultamiento. Las mismas cubren el ocultamiento del archivo para: i. todos los usuarios menos el dueo. ii. todos los usuarios menos los del grupo. iii. solo los usuarios de ese grupo.

A su vez, se puede habilitar o deshabilitar a todos usuarios para cambiar estas propiedades de ocultamientos. Debido a la compativilidad entre el filesystem V2 y el filesystem modificado, se decidi utilizar la versin V2 como si fuese la versin modificada. Para ms informacin sobre lo realizado y el manual de usuario ver el informe correspondiente en el anexo. Cambio de algoritmo de scheduling: Se modific el algoritmo de scheduling utilizado por Minix 2.0.4. Se reemplaz el Round-Robin de procesos de usuarios por un sistema con prioridades dinmicas que castiga a los procesos que utilizan mayor cantidad de tiempo la CPU. Los sistemas operativos que usan Round-Robin tienen el problema de que procesos que consumen ms CPU que el resto reciben la misma prioridad que todos. Al implementar un sistema con prioridades dinmicas se mejora la performance de procesos que requieren CPU por un pequeo porcentaje de tiempo sin dejar de servir a aquellos procesos ms demandantes. El scheduler de Minix 2.0.4 utiliza un Round-Robin de 3 niveles donde los distintos niveles corresponden a procesos de kernel, drivers y procesos de usuario lo que garantiza que los procesos de kernel tienen prioridad sobre los drivers y estos sobre los procesos de usuario. Este esquema de tres niveles se mantiene, lo que cambio fue el scheduling de procesos de usuario.

Instalacin
Para instalar y correr nuestro trabajo, se debe hacer lo siguiente: En el directorio en el que se descomprimi el proyecto, ejecutar ./restoreimg Esto crear una nueva imagen conteniendo un Minix 2.0.4 base. Sobre ste se compilaran los agregados. Para meter todos nuestros cdigos fuentes dentro de la imagen, correr el comando ./msync Luego, ejecutar ./launchminix para abrir la imagen con una mquina virtual utilizando qemu. Una vez dentro de la imagen, presionar '=' o ESC y luego escribir 'boot', y luego loguearse como el usuario root (no tiene password). Ejecutar el siguiente comando desde /usr: sharma

Eso debera instalar todo automticamente. En caso de que no ande, ejecutar los siguientes comandos:

Moverse al directorio /usr/src/tools y ejecutar makehdboot cd../lib makeclean makeinstall cd../commands makeinstall Para crear los disposivos especiales para el driver VESA y el driver de mouse, ejecutar los siguientes comandos estando dentro de la carpeta /dev: cd/dev MAKEDEVvesa MAKEDEVmouse Luego de hacer esto, deberan existir los archivos especiales 'mouse' y 'vesa'. Para probar..

Comandos de prueba
Se conservaron los programas de prueba anteriores (racoon, x, clock, etc.) y se agregaron algunos ms. fonts: muestra varios textos renderizados en distintos tamaos de letras a partir de la misma fuente bitmap. Se muestran ambos modos de la funcin draw_string, la que encuadra el texto en una caja invisible, y la que trabaja en modo single-line. click: un programa en el que vemos al raccoon persiguiendo al mouse. mouse_read: sirve para ver los eventos de mouse.

fractal: muestra el poder de la librera grfica renderizando un fractal. window: inicia la interfaz grfica (explorador de archivos) de minix. busy : while(1); busyX : while(1) sleep(X); para x = 1, 5, 10 busy1-5-10 : va cambiando de comportamiento entre ser un busy1, busy5 y busy10

Posibles extensiones
Algunas posibles extensiones para este trabajo son: Separar el servidor X del cliente de aplicaciones grficas Desarrollar un manejador de ventanas que permita abrir varias carpetas a la vez Modificar el driver VESA para que maneje zonas de dibujo para cada imagen y un mapa de bits que marque las zonas fueron modificadas desde la ltima vez que se bajaron los cambios a pantalla. De este modo, se evitara redibujar toda la imagen completa cada vez que se ejecuta un imgScreenRefresh. Modificar el driver de VESA para que en vez de acceder a la BIOS para ejecutar el cdigo de manejo grfico, se encargue de copiar el cdigo al kernel de minix. As se evitaran varios pasajes de mensajes Generar el proceso xserver o similar que tenga un 'thread' dedicado al leer el mouse y subscribir proceso e implementar el patrn obsever. Hacer ms eficiente el mdulo grfico.Tanto la parte matemtica (clculo de zonas activas) y la parte de imprimir la pantalla misma (intentar reusar toda la mayor parte posible de la zona que se mantiene constante en la prxima impresin de pantalla). Optimizar el scheduling, intentando disminuir el orden del algoritmo. Adems sera interesante incluir las tres colas (kernel, drivers y usuario) en el scheduling. Quitar la SYSTEM TASK, para optimizar minix, obteniendo gran performance en toda el sistema visual. Portear el codigo de la vesa de la bios para correrlo en memoria en el kernel. Permitir realizar filtro en otros niveles. De la misma manera que se implement ltros a nivel enlace se podran agregarse otros ltros pertinentes en otros niveles.

Problemas encontrados
Algunas de los problemas ms importantes que encontramos fueron: La mayora de los trabajos o papers de base tenan muchos errores. Esto conlleva a tener que analizar todo el cambio de manera global y luego corregir dichos errores. Algunos trabajos se solapaban en cambio por lo cual tuvimos que tomarnos tiempo para mergearlos correctamente. Se perdi mucho tiempo (literalmente 3 das) tratando de migrar trabajos anteriores que corran en la versin 2.0.0 de Minix hacia Minix 2.0.4, la versin en la que se decidi hacer nuestro trabajo. Esto se debi principalmente a que la documentacin que encontramos era pobre (los informes que se entregaron junto con los trabajos), faltaban muchos archivos de cdigo fuente, y las versiones que conseguimos no eran las finales.

Conclusiones
A lo largo del trabajo se busc cumplir los objetivos propuestos, se logr satisfactoriamente crear una slida base, con numerosas funcionalidades agregadas sobre Minix 2.0.4. Durante el proceso de desarollo surgieron diversos problemas que atentaron contra el desarrollo pero se logr seguir adelante. Se identificaron posibles extensiones que invitan a nuevos grupos a seguir con esta cruzada hacia el objetivo final de desarrollar un sistema operativo de uso general y no meramente con fines acadmicos, desarrollado por alumnos del ITBA.

Agradecimientos
Rodrigo Rearden, Eduardo Casal, Luciano Mangiarotti, Emmanuel Teisaire,Jos Liendro, Hemilse Devrouvier, Ezequiel Villegas Patlis, Richard Roehl, Gou Xinwe, Oybin Pablo Nahuel, Sessa Carlos, Eduardo Martnez

Anexo

Soporte grfico para Minix.

Integrantes: Eduardo Casal, Luciano Mangiarotti, Rodrigo Rearden.

Interface, detalles de implementacin y proceso de creacin de un driver de video estndar VESA y una librera de soporte que simplifican su uso, para el sistema operativo Minix.

VESA driver
Introduccin
Existen dos consideraciones principales para entender como funcionan y se implementan los drivers en Minix, la primera consideracin esta referida a la interface que debe ofrecer el driver a los procesos, la segunda a la implementacion del driver en el kernel y del kernel de minix mismo. 1- Debmos tener en cuenta que Minix es un clon del sistema UNIX, esto implica que todo dispositivo, includo nuestro driver de video, deber ser accedido como un archivo comn y corriente, mediante las system calls 'open', 'write', 'read', 'lseek' y 'close', (con la nica diferencia que los dispositivos adem pueden servirse de la ayuda de una funcion de control llamada 'ioctl' para controlar comportamientos del mismo). Esta interface impuesta por el estandar POSIX que minix sigue a rajatabla, soluciona la implementacion de ciertos controladores de dispositivos, y complica muchsimo la de otros. 2- Minix es un sistema operativo de tipo microkernel, este diseo hace que los drivers sean hilos, o procesos similares a los de usuario, pero con privilegios superiores. La comunicacion entre el driver y el resto del sistema se realiza mediante el mecanismo de IPC por excelencia de Minix: randezvou, este enfoque a pesar de ser muy prolijo y modular, puede traer problemas, en especial a la hora de desarrollar un driver, y ms en especial a la hora de debuggear un driver. La ecuacin planteada por estos dos enfoques, se completa en Minix 2 al plantear los conocidos Memory Manager y File System tambin como procesos, aunque son procesos de usuario no privilegiados, (lo cual es lgico, ya que estos se encargan de realizar tareas lgicas, y no de administrar hardware) y al comunicar todos los 'daemons' con un Message Dispatcher que se encarga de coordinar los Randez vou. MM y FS junto con el infame System Task, se encargan de hacer las veces de proxy entre los procesos de usuario, y el kernel en si, compuesto por los drivers , el MD y otros componentes, todos estan compilados en el mismo nico archivo binario.

El 'cmo funciona'

Desde el nivel ms abstracto, hasta el driver en s: Un proceso realiza un llamada a sistema 'open' sobre un archivo especial vinculado con el driver (se explicar mas adelante), al llamar a open, un mensaje es enviado al File System, el FS, busca en su tabla de archivos, el archivo que fue invocado, y verifica que corresponde a un dispositivo identificado por un nmero (en nuestro caso con el nmero 15), internamente el FS maneja un arreglo de PIDs relacionados con con otros datos, donde cada PID identifica un proceso driver, el nmero que se obtuvo de la tabla de archivos, indica la posicion en este arreglo donde se encuentra el PID correspondiente, el FS enva un mensaje al System Task, este a su vez enva un mensaje al proceso privilegiado, que finalmente lo recibe y acta en consecuencia... y ac empiezan los problemas: SIEMPRE hay que responder los mensajes, no hacerlo en un proceso del ncleo, implica el cuelgue del sistema, sin posibilidad de recuperacin. Ac el driver deber interpretar el mensaje, y ejecutar las funciones privilegiadas que necesite, como en nuestro caso acceder a la BIOS para lograr las llamadas a interrupciones del sistema que brinda el estandar VESA, para esto es necesario una funcion auxiliar llamada 'level0' que permite acceder al anillo mas privilegiado del sistema. Luego de que el driver cumple con su funcin, enva al system task una respuesta, deshaciendo todo el camino andado, y ultimamente retornando con un felz 'file descriptor' al proceso invocador. La misma parafrenalia de mensajes, cambios de contexto entre al menos tres procesos y cambios de anillos de privilegios desde 2 a 1 y luego 0 se realiza para las demas system calls como read, write, y close, esto le dio a Minix y al modelo Microkernel la fama de ser poco performantes, sorprendentemente, esto no es completamente cierto, nosotros encontramos que implementaciones de eficiencia pobre, que no realizen ni un solo cambio de contexto o llamada a sistema, pueden ser cuellos de botella muchsimo mas graves que el pasaje de mensajes. Todo esto se aprendi desarrollando un driver prototipo, en base al de tty y a la observacin de otros (Tcnica comunmente conocida cmo 'Selective Copypasta'), el prototipo simplemente se encargaba de imprimir un mensaje en pantalla cuando reciba un 'open', 'write' y dems, bsicamente estaba compuesto de una inicializacion, y un bucle que se bloquea al principio esperando un mensaje, que luego es interpretado. Sobre este prototipo se implement el driver real. El usuario del driver, luego de abrir el archivo para lectura y escritura, simplemente escribir los colores de los pixeles que quiere que se muestren en pantalla con write, en orden BGR, estos seran puestos en pantalla desde la esquina superior izquierda de manera horizontal hasta completar la linea, luego se seguira por la segunda linea hasta completar la pantalla entera, donde la sucesiva llamada a write retornar 0 indicando el fin del archivo, se podr volver a llenar la pantalla mediante la llamada a lseek para ubicar el cursor al incio de la memoria de video (o bien en cualquier otro lugar, especificando un desplazamiento en bytes, no en pixels). Lo anterior en una cascara de nuez: || || User Space Process <----> File System <-----> System Task <---||---> Driver-||-level0() Ring 2 (User Land) || Ring 1 (KL)|| Ring 0 (Kernel Land) donde '<---->' un mensaje representa un intercambio de mensajes, y '||' un cambio en el nivel de privilegios

El estndar VESA y la implementacin del driver en s, problemas y soluciones

VESA es el estander que define una interface que nos permite comunicarnos con la placa de video de la computadora, su implementacion esta nada ms ni nada menos que como interrupciones de la BIOS, haciendo su primera versin, la 1.0 casi completamente intil para un sistema operativo que trabajara en modo protegido. Los implementadores de Minix afortunadamente se tomaron el arduo (muy arduo a juzgar por el cdigo) trabajo de lograr reactivar las llamadas a interrupciones, mediante la implementacion de una funcion llamada int86, en la libreria de funciones en lenguaje Assembley de Minix. Versiones posteriores de VESA, comenzando desde la 1.2 incluyen punteros globales traducidos al direccionamiento de modo protegido, que identifican las funciones que implementan el estandar, que se pueden obtener (por supuesto) a traves de una

interrupcin de la BIOS, (el objetivo de esto es ganar eficiencia en las llamadas). Luego de resolver estos problemas y lograr el primer cambio a modo grfico, se encontr una nueva muralla, o mejor dicho dos, ambas relacionadas con la memoria: Solo se pueden escribir 64 kilobytes de la memoria de video, que estan mapeados a memoria RAM (lo cual es lgico, ya que en modo real solo se dispone de 1MB de RAM para mapeos de dispositivos y similares), esto es menos que insuficiente para lo que necesitamos. El segundo problema fue realmente escribir algo en esa memoria, en Minix cada proceso esta en su propio espacio de memoria, lo cual quiere decir que a fines de uso, la direccion de memoria de video (0xA0000) en cualquier proceso (incluso en los drivers), es una direccin 'virtual' (As la llaman en Minix, la denominacion correcta de Intel es 'lineal'), correspondiente a un offset en el espacio de memoria del proceso, esto implica que para lograr acceder realmente a la direccin deseada, fue necesario utilizar una primitiva de copiado proveda felizmente por los desarrolladores: 'phys_copy', similares problemas se presentaron a la hora de obtener datos del buffer que un proceso enva mediante la system call write.

Consideraciones tcnicas
Es necesario que el kernel sepa de la existencia del driver: Para esto fue necesario definir el tamao del stack del driver (VESA_STACK), agregarlo al espacio total reservado por el kernel (TOT_STACK_SPACE) y agregar los datos de la 'task' o proceso al arreglo 'tasktab' (especificamente luego de la entrada de TTY y antes de la de impresora, segn instrucciones cdigo, dadas en el comentario anterior al arreglo), el dato mas importante es la funcin que iniciar la ejecucin del driver, en nuestro caso 'vesa_task'. Es necesario que el filesystem sepa de la existencia de dos entidades: 1- El PID del proceso que controla el dispositivo: Para esto se debe modificar el archivo src/fs/table.c, agregando en el arreglo llamado 'dmap', una entrada con el PID y otros datos necesarios 2- El archivo que permite al usuario hablar con ese proceso: Para esto se debe realizar con el comando mknod, un archivo especial que est vinculado al indice correspondiente en la tabla anterior, opcionalmente se podr incluir un subnmero de dispositivo (no fue necesario para nosotros) Para que el driver reciba mensajes, tambin debe ser includo en una cadena de defines ubicada en /include/minix/com.h, los comentarios explican claramente cmo. Por ltimo, en /include/minix/const.h se debe incrementar en 1 la constante NR_TASKS, de otro modo Minix se negar a compilar.

La librera xlib
Introduccin
Ms all de su nombre, que nos recuerda a la conocida xlib de otros sistemas Unix, 'nuestra' xlib no implementa ningun tipo de comunicacin con un servidor x, en su lugar provee de primitivas de dibujo que abstraen el manejo del driver de video antes descripto, estas primitivas permiten: abrir archivos de imagen, copiar sus partes, dibujar puntos, rectangulos, circulos y lneas, e incluso crear una pseudo transparencia, abrir la pantalla como una imgen ms y crear una imagen vaca (que se suele usar como buffer).

Abstrayendonos de open, read, write y close.

Afrontemoslo: escribir en una pantalla como si se tratara de un archivo es como mnimo molesto, en el mejor de los casos, desesperante y por sobre todo, LENTO, si cada vez que se quiere cambiar un simple y nico pixel aleatorio, se debe realizar un lseek estamos haciendo al menos seis pasajes de mensajes/cambios de contexto, ni hablar si debemos dibujar un cuadrado en el medio de la pantalla, son tantos lseek como alto en

pixels tenga el cuadrado, alguno inmediatamente dira: "Ah, culpa del microkernel!". Por supuesto que NO es culpa del microkernel, el desarrollador debe proveer una librera lo suficientemente abstracta y eficiente para manejar el driver. En xlib, al crear una imagen con la funcion 'imgScreen', se abre el driver de video, y se crea un buffer temporal, a donde iran todos los dibujos que haga el usuario, hasta que este llame a la funcion 'imgScreenRefresh', que se encargar de volcarlos en el driver, esta solucin permite no solo simplificar la forma de trabajar e implementar, sino tambin incrementa la eficiencia, limitando la cantidad de llamadas a sistema a unas pocas cada vez que se utiliza 'imgScreenRefresh'.

La cara bonita: dibujando, copiando, simulando transparencias y abriendo archivos bitmap.

Para representar figuras geomtricas se implementaron tres funciones bsicas, 'drawPixel', 'drawLine' y 'drawCircle'. Teniendo en cuenta que las dos ltimas dos no son triviales de implementar (no lo son, aunque lo parecen) y que en la web hay muchas versiones de que funcionan perfectamente, decidimos obtenerlas de all, 'drawLine' esta implementada usando el algortmo de Bresenham para dibujo de lineas, 'drawCircle' usando una adaptacin de dicho algortmo. Tambin se incluyen las funciones 'drawSquare' y 'drawRect' implementadas en funcion de las anteriores, y las funciones 'getPixel' para obtener el color de un pixel en pantalla o de una imagen e 'imgClear' para borrar una imagen con un color especificado en los parametros. Se puede ver una demostracin en los archivos de ejemplo ejecutables x y clock. Podemos abrir imgenes en formato bitmap de 32 bits con la funcion 'imgLoad', luego copiar sus partes a otras imagenes, por ejemplo a la pantalla (creada con 'imgScreen') o a un buffer (creado con 'imgCreate'), la funcin que utilizamos para esto es 'imgBlt', dispone de cuatro operadores, copia plana (BLT_COPY), suma lgica (BLT_AND), multiplicacin logica (BLT_OR), e inversin (BLT_XOR), los operadores de suma logica y multiplicacin, son especialmente utiles a la hora de simular transparencias totales por medio del uso de mscaras (se hace un AND de la mascara en negro en fondo blanco, y luego un OR de la imagen en colores con fondo negro). Pueden apreciarse jugosos ejemplos en los ejecutables 'testbmp' (ejecutar en /usr/src/commands/testbmp) y 'raccoon' (ejecutarse en la /usr/src/commands/raccoon). Fue con las implementaciones inciales poco performantes, de 'imgBlt' y 'imgClear' que encontramos cuellos de botella en velocidad muy grandes, muchsimo mas grandes que los de enviar y recibir mensajes, bast con implementar ambas funciones usando la funcion setPixel, algo aparentemente inofensivo, luego lo arreglamos en siguientes versiones, recuperando velocidad. Todas las primitivas de dibujo y copiado reciben un puntero a imagen 'imgT *' y otros parmetros necesarios para la creacion del dibujo, las funciones para crear estos tipos de imagen son (nuevamente): - 'imgCreate': recibe como parametro ancho y alto. - 'imgLoad': acepta como parametro el nombre del archivo a cargar. - 'imgScreen': no recibe parametro alguno.

raccoon!
En este ejemplo podemos ver a nuestro mapache favorito caminando feliz por su bosque de pixels.

clock
El comando clock utiliza la librera xlib para mostrar un reloj analgico en pantalla. Mediante la interfaz con xlib, dibuja todos los elementos del reloj: el crculo, las rayitas de las horas y las agujas. Adems utiliza la funcin gmtime para obtener la hora del sistema y las funciones de la libreria math.h para poder pasar los angulos de los brazos del reloj a coordenadas cartesianas para poder pasarlas como parmetro a la libreria xlib. Desafortunadamente, el reloj tiene un funcionamiento lento. Luego de varias optimizaciones al cdigo, comprobamos que el retraso se deba a la funcin gmtime. Este cdigo no quisimos modificarlo por ser parte del sistema Minix.

x y testbmp
En estos ejemplos vemos parte de las distintas capacidades de la librera xlib, apriete enter sucesivamente para ir viendo distintas demostraciones, testbmp recibe dos imgenes como parmetro, ingrese 'qq' 'enter' para salir.

Actualizacin de soporte grfico para Minix

Mltiples resoluciones y soporte para imgenes de 24 bits
27-6-09
Integrantes: Emmanuel Teisaire,Jos Liendro, Hemilse Devrouvier En este trabajo lo que se ha hecho es agregarle al driver vesa la posibilidad de manejar mltiples resoluciones de imgenes por medio de la system call ioctl. Mediante dicha system call se obtiene un cdigo que identifica a alguna de las cinco resoluciones soportadas por el driver: 320x200, 640x480, 800x600, 1024x768 y 1280x1024. Luego de obtenida la resolucin, se llama a la bios para realizar el cambio. Adems de modificar el driver, en este trabajo se ha actualizado la librera xlib y los distintos programas de prueba para soportar imgines de distintas resoluciones. La librera xlib ahora provee una funcin que dada una imagen retorna el cdigo de su resolucin, por lo cual no es necesario saber de antemano ni cablear en el cdigo el tamao de una determinada imagen antes de utilizar el sistema. Otro aporte a este trabajo fue la posibilidad de utilizar no solo imgenes de 32 bits sino tambin de 24 bits. Tambin es posible usar imgenes de 16 y de 8, aunque se mostrar una advertencia, ya que muy posiblemente esas imgenes no se puedan mostrar correctamente. Tambin se validan las imgenes con resoluciones distintas a las soportadas.

Raccoon
En este ejemplo ahora se pide que se ingrese por lnea de comandos una imagen, la cual ser el habitat del mapache. Ahora es posible salir de esta aplicacion en cualquier momento presionando 'enter'.

Testbmp
A esta aplicacin ahora se le pueden ingresar desde una hasta cinco imgenes como argumentos, las cuales se irn rotando a medida que el usuario presione 'enter'. Para salir basta con presionar 'q' y luego 'enter'.

Clock
Si no se le pasan argumentos, este programa dibujar el reloj en un fondo negro y con una resolucin de 1024x768. Se le puede pasar una imagen como argumento, en cuyo caso el reloj se dibujara sobre dicha imagen. Al igual que Raccoon, esta aplicacin ahora se puede cerrar en cualquier momento presionando 'enter'. En la aplicacin x no se han hecho cambios significativos.