Sí, esa cosa llena de hacks para ocultar el parpadeo del cursor y cosas así no me hace sentir muy orgulloso, pero sobre FBDEV, que es lo único que soportan estas placas inmundas, no podía hacer otra cosa.
Con Odroid C1, debido a su core MALI para gráficos, la situación es esta:
-Si quieres OpenGL_ES como en el vídeo que has puesto, estás atado a un kernel desactualizado y a drivers cerrados de ARM Holdings. Cuando ARM Holdings cierre el grifo, adiós, ahí te quedas. Y reza para que funcione el vsync como debe fuera de las X: hasta hace poco no lo hacía y sé que lo arreglaron para las Odroid XU3, pero de las C1 no tengo noticia.
Tendrías que acabar usando GLES sobre X11, con lo que adiós a la baja latencia.
Para que veas que no tengo mala intención con estas placas rancias, también implementé un driver G2D, para no tener que usar NADA de código cerrado de ARM Holdings: https://github.com/libretro/RetroArch/blob/master/gfx/drivers/sunxi_gfx.c
Esto se usa en otras placas con MALI, como las cubie. En la C1 igual no te funciona ni esto. Pero de igual modo, si somos optimistas y suponemos que te funciona mi driver, estarás atado a un kernel 3.x y bien jodido.
Esto ya fue una machada: "ah, sí, o sea que tengo que usar basura propietaria y cerrada, eh? Pues me haré mi propio driver que use el bloque G2D, con casinos, y furcias!". Y no lo pienso volver a hacer con ninguna placa más. Si el fabricante no sigue estándares ni abre drivers, que se meta el hardware por el recto. Esto es un ejercicio de responsabilidad que deberíamos hacer todos, por el bien de todos.
-Si quieres un kernel actual, olvídate de OpenGL_ES, de G2D y de todo.
Así que, este es el resúmen: siempre que veais una placa con MALI, y mientras ARM Holdings no libere sus drivers o coopere para tener unos abiertos, huid de ella como de la peste.
Da igual si aparentemente la relación potencia/precio se decanta por la placa con MALI: en el mundo Linux, unos drivers cerrados os pueden atar a versiones del kernel concretas (como ocurre con las placas con MALI), y esa es una situación muy jodida en la que no os gustará veros, ni como usuarios ni como programadores.
"Ah! Pero a mi esas cosas del opensource me dan lo mismo! yo sólo quiero jugar.", pensará alguno. Vale: cuando se te resetee la placa, o se te vaya la imágen medio segundo cada dos horas y te veas a ti mismo buceando en dmesg para reportar ese error a un fabricante que pasa de tu culo, debido a que tienes un kernel con problemas de gestión de energía o sabe dios qué otro problema que no se va a debugear jamás, recordarás por qué debiste pasar de esa placa "barata y potente" y optar por una donde haya drivers abiertos (sí, la Pi ya tiene drivers abiertos e incluso el soporte para KMS está empezando a verse en mainline).
Lo barato suele ser barato, sin más, pero ignorar lo perjudiciales que pueden ser los drivers cerrados en el mundo Linux te puede salir muy caro.
#84 Lo siento pero NO. Y lo digo con conocimiento de causa: el soporte MALI GLES sobre FBDEV que usan estas placas en RetroArch es mi propio código:
https://github.com/libretro/RetroArch/blob/master/gfx/drivers_context/mali_fbdev_ctx.c
Sí, esa cosa llena de hacks para ocultar el parpadeo del cursor y cosas así no me hace sentir muy orgulloso, pero sobre FBDEV, que es lo único que soportan estas placas inmundas, no podía hacer otra cosa.
Con Odroid C1, debido a su core MALI para gráficos, la situación es esta:
-Si quieres OpenGL_ES como en el vídeo que has puesto, estás atado a un kernel desactualizado y a drivers cerrados de ARM Holdings. Cuando ARM Holdings cierre el grifo, adiós, ahí te quedas. Y reza para que funcione el vsync como debe fuera de las X: hasta hace poco no lo hacía y sé que lo arreglaron para las Odroid XU3, pero de las C1 no tengo noticia.
Tendrías que acabar usando GLES sobre X11, con lo que adiós a la baja latencia.
Para que veas que no tengo mala intención con estas placas rancias, también implementé un driver G2D, para no tener que usar NADA de código cerrado de ARM Holdings:
https://github.com/libretro/RetroArch/blob/master/gfx/drivers/sunxi_gfx.c
Esto se usa en otras placas con MALI, como las cubie. En la C1 igual no te funciona ni esto. Pero de igual modo, si somos optimistas y suponemos que te funciona mi driver, estarás atado a un kernel 3.x y bien jodido.
Esto ya fue una machada: "ah, sí, o sea que tengo que usar basura propietaria y cerrada, eh? Pues me haré mi propio driver que use el bloque G2D, con casinos, y furcias!". Y no lo pienso volver a hacer con ninguna placa más. Si el fabricante no sigue estándares ni abre drivers, que se meta el hardware por el recto. Esto es un ejercicio de responsabilidad que deberíamos hacer todos, por el bien de todos.
-Si quieres un kernel actual, olvídate de OpenGL_ES, de G2D y de todo.
Así que, este es el resúmen: siempre que veais una placa con MALI, y mientras ARM Holdings no libere sus drivers o coopere para tener unos abiertos, huid de ella como de la peste.
Da igual si aparentemente la relación potencia/precio se decanta por la placa con MALI: en el mundo Linux, unos drivers cerrados os pueden atar a versiones del kernel concretas (como ocurre con las placas con MALI), y esa es una situación muy jodida en la que no os gustará veros, ni como usuarios ni como programadores.
"Ah! Pero a mi esas cosas del opensource me dan lo mismo! yo sólo quiero jugar.", pensará alguno. Vale: cuando se te resetee la placa, o se te vaya la imágen medio segundo cada dos horas y te veas a ti mismo buceando en dmesg para reportar ese error a un fabricante que pasa de tu culo, debido a que tienes un kernel con problemas de gestión de energía o sabe dios qué otro problema que no se va a debugear jamás, recordarás por qué debiste pasar de esa placa "barata y potente" y optar por una donde haya drivers abiertos (sí, la Pi ya tiene drivers abiertos e incluso el soporte para KMS está empezando a verse en mainline).
Lo barato suele ser barato, sin más, pero ignorar lo perjudiciales que pueden ser los drivers cerrados en el mundo Linux te puede salir muy caro.