Minimal EGL context (possibly on framebuffer?)

[CNLohr]

I found various information from various places about running minimal egl programs on the OrangePi.  Suggesting I need to do things such as modify various .fex's, etc.  http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=53

 

However, I can't seem to find anything that's up-to-date, and much less one that doesn't rely on X to run.  And, I'd really like to avoid a dependency on X. 

 

1) Is the most up-to-date userspace driver still https://github.com/linux-sunxi/sunxi-mali I find it hard to believe that that is right considering its age.  It is also referenced here: http://linux-sunxi.org/Mali_binary_driver.  In addition, no mali module seems to be present in the kernel, and also no /dev/mali.

 

2) are the packages libmali-sunxi-dev mali-sunxi-utils the most up-to-date?  They don't seem to go.  Got the following error:

 

Mali binary driver can be used only with legacy kernel

3) I found someone else trying to update everything, but they reported they could not get it working.

 

4) Is there any hope of an X-less interface in the future as it seems most of this is built around an assumption of having X.

 

 

[jernej]

First, are you trying to set up OGL ES on mainline kernel? That will not work yet, because SimpleFB driver doesn't support double buffering and everything else which is needed for Mali driver to work, so only real possibility is legacy kernel for now. I'm working on mainline driver which will fix that but it is not ready yet.

 

Secondly, as you figured out, my OpenELEC fork uses r4p0 driver and there is even r6 Mali driver, but they have all same issue - license. Allwinner for some reason doesn't want to add proper license, which make redistribution legal grey area or even prevents it. That's why Armbian doesn't include any newer driver.

 

Yes, X-less OGL ES context is possible, I'm using it on my OpenELEC fork. Trick is that you have to use fbdev version of Mali driver, which means that you have to find it and copy it by yourself, since Armbian supports only X version. And if you doing it, be aware that kernel driver version and userspace lib version have to match. For example, if you will copy Mali r4p0 from my OpenELEC fork, you will have to check my kernel (only big difference with Armbian kernel is Mali driver) and either patch Armbian kernel with same Mali source or compile driver out of tree (https://github.com/jernejsk/linux/tree/master/drivers/gpu/mali). Of course it is much easier just to use mali r3p2 fbdev version.

 

As you can see, it is possible on legacy kernel, since I'm using it on my OpenELEC fork, but it is tedious to get it right.

[zador.blood.stained]

2 hours ago, jernej said:

Secondly, as you figured out, my OpenELEC fork uses r4p0 driver and there is even r6 Mali driver, but they have all same issue - license. Allwinner for some reason doesn't want to add proper license, which make redistribution legal grey area or even prevents it. That's why Armbian doesn't include any newer driver.

 

This one has a proper license: https://github.com/NextThingCo/chip-mali-userspace

It is r6p0 X11 mali400 dma-buf

 

2 hours ago, jernej said:

First, are you trying to set up OGL ES on mainline kernel? That will not work yet, because SimpleFB driver doesn't support double buffering and everything else which is needed for Mali driver to work, so only real possibility is legacy kernel for now. I'm working on mainline driver which will fix that but it is not ready yet.

 

I thought you can run framebuffer mali on simplefb. What kind of framebuffer is needed then?

[CNLohr]

I seem to be unable to get the legacy kernel to output to the vive, since it requires such an oddball resolution 2160x1200@90.    I spent a while fooling around and eventually gave up trying to get it to output on the legacy kernel.  It seemed that the modes are restricted to the common modes.  That's why I believe the r3p2 option is off the table :-/

 

@jernej your phrasology regarding the relationship between the kernel and userspace driver is confusing to me.  I can't tell if this IS supported or is NOT supported with simplefb in the mainline kernel.  It sounds like because you don't want to support the simplefb mali driver, I would need to (1) get the kernel module, compile against kernel on my desktop.  (2) get the userspace driver and compile against the kernel headers.  This seems very trivial to me, but your discussion of what is or is not supported is confusing to me, like things aren't that simple.

 

[zador.blood.stained]

8 hours ago, zador.blood.stained said:

I thought you can run framebuffer mali on simplefb.

Okay, looks like I was wrong https://irclog.whitequark.org/linux-sunxi/2017-03-09#19008020:

Quote

11:10 <Net147> akaWolf: it is being used for Mali fbdev rather than with X11 

11:11 <Net147> akaWolf: Mali requires virtual resolution that is double the height for double-buffering. it pans the display to swap buffers when rendering. simplefb doesn't provide that capability. 

11:11 <Net147> akaWolf: also, simplefb has no ability for vsync so you get tearing 

11:12 <Net147> akaWolf: CMA fbdev which emulates fbdev for DRM drivers can support double-buffering with a patch and also avoids tearing as panning the display is an atomic with sun4i-drm 

11:15 <akaWolf> Net147: okay, thanks for exhaustive explanation 

12:03 <mripard> Net147: that part will be in 4.12 btw 

 

[jernej]

Ok, sorry for any confusion. No, you can't use Mali drivers with mainline YET, only chance is legacy kernel. @zador.blood.stained, simplefb also doesn't provide vsync event, although that does not prevent you to make it work, but there will be some tearing.

 

@CNLohr, You just have to to have matching kernel driver to userspace library. In short, if user space library is r3p2 so it has to be kernel driver. There is easy way, go with r3p2 fbdev user space library and you don't have to recompile anything, or try to upgrade to newer version and then you have to find appropriate sources. Ones from ARM site doesn't work, because you need Allwinner hacks, so the easiest way is to find some Allwinner kernel code drop with appropriate version of Mali driver. And no, you can't compile userspace drivers, they are always in binary form, but at least they are kernel neutral, they connect only to Mali kernel driver.

[zador.blood.stained]

58 minutes ago, jernej said:

And no, you can't compile userspace drivers, they are always in binary form, but at least they are kernel neutral, they connect only to Mali kernel driver.

While looking at the output of "strings libMali.so" (for the r6p0) I noticed the TARGET_CORE_REVISION option which may suggest that not every libMali.so version may be used:

CORES=MALI400 USING_MALI400=1 TARGET_CORE_REVISION=0x0101

 

[CNLohr]

1 hour ago, jernej said:

Ok, sorry for any confusion. No, you can't use Mali drivers with mainline YET, only chance is legacy kernel. @zador.blood.stained, simplefb also doesn't provide vsync event, although that does not prevent you to make it work, but there will be some tearing.

 

@CNLohr, You just have to to have matching kernel driver to userspace library. In short, if user space library is r3p2 so it has to be kernel driver. There is easy way, go with r3p2 fbdev user space library and you don't have to recompile anything, or try to upgrade to newer

 

 

Well, considering legacy is a dead-end as far as I can tell with the output modes, I think we're stuck on mainline.   Based on what Net147 says, looks like whenever the double-height virtual window becomes available for Mali will be when it becomes available for me, too.   So, everything I want to do is contingent on something better than simplefb (with or without x).  Any ideas how I could help push that along?

 

Unless I'm missing something and there being a real way of using the legacy kernel with EDID or other nonstandard modes?

[zador.blood.stained]

8 minutes ago, CNLohr said:

Well, considering legacy is a dead-end as far as I can tell with the output modes, I think we're stuck on mainline.

Not exactly. @jernej made a customized u-boot version which prints EDID info as it is expected to go to the legacy kernel source, you just have to patch it correctly and recompile the kernel.

[CNLohr]

29 minutes ago, zador.blood.stained said:

Not exactly. @jernej made a customized u-boot version which prints EDID info as it is expected to go to the legacy kernel source, you just have to patch it correctly and recompile the kernel.

Any way I can get link?  Googling isn't showing very much for me, but that could also be because I'm not very into this scene so a lot is unfamiliar for me.

[zador.blood.stained]

https://github.com/igorpecovnik/lib/issues/594#issuecomment-272992961

[CNLohr]

Ugh... More compile issues when I try to compile the legacy kernel (haven't even tried patching it yet!)

 

The legacy version initially boots into the correct EDID mode, and everything's fine, however, as soon as the kernel starts, it immediately switches to 720p.  After letting it do the full unattended upgrade, it seems to have more modes in h3disp, however, nothing that seems to inherit the modes from the uboot environment or other edid anything.

 

@jernej described a pre-built version "https://down.nu/temp/u-boot-h3-video-helper.bin" But when I followed his instructions found here:

dd if=uboot-h3-video-helper.bin of=/path/to/sdcard bs=1k seek=8 conv=fsync,notrunc 

 

Only sadness ensued with a failed CRC check.

 

 

[CNLohr]

Is there some magical "Make my kernel just do whatever uboot says" button?

[zador.blood.stained]

13 hours ago, CNLohr said:

Only sadness ensued with a failed CRC check.

Environment CRC message is only a warning and should be ignored.

 

13 hours ago, CNLohr said:

Is there some magical "Make my kernel just do whatever uboot says" button?

For the legacy kernel - no. I mean it can be done in theory, but it's too much work for this kernel and it won't benefit in mainlining, which is the main priority of most developers.

[CNLohr]

 

2 hours ago, zador.blood.stained said:

Environment CRC message is only a warning and should be ignored.

 

For the legacy kernel - no. I mean it can be done in theory, but it's too much work for this kernel and it won't benefit in mainlining, which is the main priority of most developers.

 

Hmm, it still refused to boot anyway.  I did not pay attention to if there were other errors on-screen, but, it certainly did not get past uboot.  Is that the correct way to apply the binary patch?

 

I admit I was rather confused to hear the developers mentioning using the legacy branch, as I would imagine almost all focus should be on mainline.  It feels /sooo/ close.  Even though a non-mali option isn't ideal, even just being able to pan the framebuffer would be a workable solution for what I'm working on, and it sounds like that is /very/ close to completion on your guys side.

[zador.blood.stained]

2 minutes ago, CNLohr said:

Hmm, it still refused to boot anyway.  I did not pay attention to if there were other errors on-screen, but, it certainly did not get past uboot.  Is that the correct way to apply the binary patch?

This modified u-boot doesn't have to boot anything, it only has to read the EDID and output a buch of numbers to the serial console, and these numbers can be inserted to 2 tables in the kernel sources to add a new video mode.

[CNLohr]

OOHHH That makes a lot more sense!  Are those tables from that patch still the recommended mechanism for adding new video modes?  Once they're added, I suppose I just compile my kernel and they'll pop up in h3disp?   I have to admit, I can't recall seeing a table of numbers or anything, but I will try again!

 

The one thing that was a little daunting to me about the patch is that the numbers in the table did not appear to line up to what I was used to seeing in the EDID data or the modeline data I have the vive working with in other arenas, and I didn't see any obvious way to translate.  I'm hoping that table /just/ contains the numbers.

 

Charles