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: 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
github.com/libretro/RetroArch/blob/master/gfx/drivers_context/mali_fbd
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:
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
… » ver todo el comentario