State of Linux mainline OpenGL on S905X

I was watching this, about the latest progress with the S905X

And I’m left a bit confused by the state of OpenGL ES 2.0 on the latest kernel
The way I understand the stack is

Mali450 Hardware <-> Secret ARM library recompiled by Amlogic <-> interface to the ARM library <-> OpenGL interface for X11

The secret library I guess lies “below” the kernel, and the interface is part of the kernel?
This I think is the interface bit:

It will be included in the kernel 4.12? (so maybe I should just wait…)
I’m not sure what this is:

the github page also points to
“Original Mali kernel driver”

So I feel like I’m not understanding something :sweat:
Anyone have a better understanding of the lay-of-the-land? @narmstrong

And is all this stuff being included in the 3rd-Party ROMs by @balbes150 ?


The Mali needs 3 components to works:

  • Device tree node: this is merged for Linux 4.12
  • Linux kernel driver: this one is available for S905 and S905X on my github as you found
  • A 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 :blush: 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 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 actually communicates to the hardware through these open source drivers?

Another potential way is to RE the similar to what nouveau has done with nvidia, but that would require someone who knows quite a bit about arm asm and lots of free time.

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:

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, …

1 Like

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.


Any help is welcome !

You can start by subscribing to the linux amlogic mailiing list :

And you can reach us on the #linux-amlogic channel in the Freenode irc network.

Don’t hesitate to send emails about your configurations and whet needs to be tested.


1 Like

I have already subscribed to this newsletter. Soon I will try there to write your question. :slight_smile:

By the way, have You seen the kernel sources 4.9 in the latest version Amlogic BUILDROOT ? There is a HDMI video output. Though not in full screen, and just before the half.

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.

Tried to write in the newsletter, but the letter does not reach. The mail server does not accept HTTP requests when trying to send him emails from a browser.

I correctly understand, what now the most actual version of the kernel (which can be checked to run at S905) is this branch ?

Thanks for explaining it @narmstrong :blush:
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


For the bleeding edge, you can use the latest linux-next branch:

It reflects what will be linux-4.12-rc1 in 3 weeks.

But you may need something safer by either using:
which is the ARM Amlogic maintainer integration tree, but without HDMI.

Or you can also use my 4.10 + backports Yocto layer:

Which has almost everything in 4.11 + HDMI + audio but may lack some stuff pushed for 4.12


tried the yocto one, build is successful but can’t get it to create the image:

ric@ric-ubuntu:~/khadasyocto/build$ wic create 
../poky/scripts/lib/wic/canned-wks/sdimage-bootpart.wks -e amlogic-
Checking basic build environment...

Creating image(s)...

Error: No boot files defined, IMAGE_BOOT_FILES unset
1 Like

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).

1 Like

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’.


For USB, some more patches are needes for 4.10, the situation will be simple for 4.11.

I’ll be interested for more help for sure !!

On which SoC and linux version ?

On which SoC and linux version ?

Khadas VIM, Ubuntu 16.04.2 LTS.

These hangs resemble the network hangs I had on the ODROID-C2 (I know, totally different SoC, GbE vs. FE) last year.