I put Arch w/ the ChromeOS Kernel onto a micro SD card recently. It's really good, although I am having trouble keeping the root filesystem within 1 GB (I have changed the journald settings, thankfully, but each package install seems to bring ungodly numbers of deps...
)Anyways, could someone read through the following use case and tell me if I'm mad?
I would like to use my Flip to run SDL 2.x applications. SDL 2 is highly reliant on hardware graphics acceleration.
I would like to be able to do this without installing X.org (so no "startx" gibberish).
I don't need touchscreen support, but I don't think that this is that hard to implement so will not seek to remove it.
This might seem foolish, but as far as I can tell, it can be done on a Raspberry Pi.
What I have done so far to accomplish this:-
Installed Clang 4 and make
Downloaded mihailescu2m's patched SDL2 source creating a mali video driver (https://github.com/mihailescu2m/libsdl2-2.0.2-dfsg1), which is basically a copy of the rpi code
Configured and built the source to provide mali, opengles and opengles2 for video and alsa for audio
I appear to have a device node for the GPU (/dev/mali0) and there is a userspace driver (/usr/lib/mali-egl/libmali.so.0.1.20) with symlinks to all your favourite graphics APIs. My user is also in the "video" group.
Current state:-
When I go to run an SDL 2.x-based application, I receive error messages that the video driver failed to initialize.
Tracing into this, I find that the following happens:-
SDL calls libmali.so -> eglGetDisplay(EGL_DEFAULT_DISPLAY), which returns seemingly a valid pointer to something.
It then calls libmali.so -> eglInitialize(pointer, &majorVer, &minorVer) which returns 0x3001 (EGL_NOT_INITIALIZED).
I have replicated this by writing a small test program that makes the exact same calls.
Given the rapid way the driver responds with failure, I think that the default Mali userspace driver is reliant on an X server already being present (forgive me if I seem slow, I grew up on Windows and am having a hard time trying to get concrete info on how Linux graphics works, let alone on ARM...)
There are some newer userspace drivers that appear to support different subsystems, supplied by Rockchip at https://github.com/rockchip-linux/libma ... -gnueabihf , the latest for the Midgard series (which the RK3288 SOC that the Flip uses) is r13p0.
As well as vanilla, there is "-fbdev", "-gbm" and "-wayland".
I know that Wayland is a windowing server similar to X.org, so will not bother with that one, but what about "-fbdev" and "-gbm"?
I have tried dropping the "r13p0-fbdev" so into the mali-egl folder and renaming it, but when I run the test program it now tells me that the userspace driver version (10.4) is greater than the kernel driver version (10.2). The kernel driver appears to be compiled into the kernel, instead of as a module. How do I get around this?
Should I use the mainline kernel?
Thanks for any help
