Linux kernel driver: this one is available for S905 and S905X on my github as you found
A libMali.so blob in userspace that acts like “Mesa” to provide all EGL, GLES and GLES2 calls to applications
But, this libMali is tied to the way you actually print stuff to screen, so for X11, Wayland, Framebuffer, DRM/KMS, … you will need a different libMali version (unlike mesa that can be rebuilt to handle all these), but (here it becomes nasty) the SoC vendor is the only one (except sometime some sublicensees like Hardkernel) that can build the libMali because it need to be configured against the actual HW configuration only Amlogic knows…
But, Amlogic only delivers the Android, X11 and Fbdev versions of the libMali.
The X11 needs this xf86-video-armsoc X11 driver to work, the fbdev needs a special libsdl2 version, and the android version can be used with libhybris.
The missing ones are the GBM and Wayland version that will perfectly match the upstream DRM/KMS driver.
Using the fbdev version is a hack, and X11 integration is so lame it’s not even worth the try…
For libhybris, we will need to emulate the way the Android libmali actually allocates buffers, so it’s also a huge hack…
Welcome in the highly imperfect world of Embedded 3D !!!
It’s great to hear from you personally @narmstrong Thank you for taking the time to explain the lay of the land
I’m getting a better understanding now
Looking at for-instance just X11:
Right now we have available a custom X11-compatible libMali.so built by Amlogic. It has the secret sauce for communicating with the hardware and in-effect it’s providing the definitions of GL headers. Now when you have an OpenGL application the linker can hook up to to this lib and everything should work. But isn’t that all you really need? What is the role of the
kernel driver (? meson_gx_mali_450)
x11 driver (? xf86-video-armsoc)
Are they effectively sitting at a lower-level? The libMali.so actually communicates to the hardware through these open source drivers?
An initiative already begun but for the Mali-400 GPUs (quite close from the Mali-450), but it stalled a few months/years ago because the author did not want to make a proper Mesa driver neither provide a global Linux driver + Mesa Driver support like other platforms: https://limadriver.org/
Hopefully, one day another genius will continue his work…
The kernel driver is only here to get the “jobs” created by the libMali and execute them on the right GPU, it’s kind of a jobs sequencer and hardware initializer.
The X11 driver (xf86-video-armsoc) is here to intercept the DRI2 calls from the libMali and forward them to the X11 server, for example the libMali needs some memory buffers, and so needs to tell the X11 driver to give it those buffers.
And it needs to tell the X11 server to flip the window content on the next vsync, …
Hi. I want to help support development of chips S805 S905 S905x S812 S912 in the new kernel. Do you need any help with testing and verification on real hardware ? I have got a few different options of models on the platform S805 S905 S905x S812 S912 (with different characteristics) and the ability to connect to the console UART.
Which part is in charge for hardware video decoding? I would like to use VIM Pro as a Kodi media center and Live TV client.
I wonder what part does c2play use to play ES streams on odroid c2. https://forum.odroid.com/viewtopic.php?t=23143
Thanks for explaining it @narmstrong
It something I haven’t been able to tease out from everything I’ve read online. I’m anxious to give your work a try in the coming weeks!
Thanks again for all the work you do
Thank you very much for provided the kernel sources. I collected on the base of Your kernel test images Armbian (server and desktop options with two variants of DE, Mate and XFCE Ubuntu-Debian). Checked run these images in several variants, TV boxes (S905 S905X S912). In this kernel (on the chip S905) are all fundamental components to the system as a work desktop. Working wired network, and output to the monitor (HDMI), USB (keyboard and mouse). On the chip s905x and s912 until he was able to run USB. This is the only problem that hinders to launch this kernel in the form of the desktop on these chips. I tried to add patches from Martin Blumenstingl kernel but USB is not working. Maybe I’m doing something wrong. Can you please tell me what links or patches I can look at that would be to implement USB on chips S905X S912 ? By the way, if You’re interested, there are a few users who are willing to help with testing new versions of the kernel on different chips (s905 s905x s912), because the testing process is now simplified. There are ready-made images that are easy to run by any user on their TV boxes with external speakers. Recorded image, hooked up to a TV box with an activated multi-boot, checked the new kernel. You can immediately generate a report and a lot of parameters via the utility armbianmonitor and upload to the website for General access (viewing).
Do you have a stable ethernet connection? I experience strange network hangs (without any further notification) when using Neil’s, Martin’s or the mainline kernel source tree. Just try to clone the kernel source repository with git and wait for a couple of seconds.
Issuing sudo ifdown eth0 && sudo ifup eth0 via serial console resolves the problem until the next ‘hang’.