VESA on lollipop-x86

[Ron M]

I assume someone has already encountered it, and I did see some "libegl translator" discussions here in the last couple of weeks, but no reference to our good old VESA feature so here goes:

Running "vanilla" lollipop-x86 32 bit build on VirtualBox and on QEMU results in terrible lags, when all "VESA" flags are intact:

1. egl.cfg  has the 0 0 android values

2. nomodeset is set in the kernel cmdline with vga=788  [default]

3. xforcevesa is set in the kernel cmdline with UVESA_MODE (although unnecessary)

4. debug.egl.hw = 0  in getprop

5. qemu = 1 [this has always been a trick to make vga std et. al work when booting with QEMU]

I have just started looking at it (same build works fine with i915 DRM), but I assume someone already ran into it and may have a solution/workaround for it.

I cannot attach logcat at the moment, but I can say kernel part is OK, and  /proc/fb validates nomodeset et. al work (  "0 VGA VESA" ).

Before I start digging further, does any one have any idea what's the cause and what is the workaround/solution?

Thanks,

Ron

P.S.

Nice "tag" feature. Hope I am not abusing it.

[Chih-Wei Huang]

Please took into the kitkat-x86 branch of frameworks/base.
(and system/core, maybe...)
Some patches needed by non-hardware-accelerated fb
are not ported to lollipop-x86 yet.
You may begin with that.
Thanks!


--
Chih-Wei
Android-x86 project
http://www.android-x86.org

[Ron M]

OK.

I'll do that in a couple of hours. Thanks.

Correct me if I'm wrong, but AFAIK, "modern" devices have no /dev/graphics/fb0  at all.

1. Was this introduced in Kit-Kat?

2. Are the changes in kk meant to workaround that "no framebuffer" behavior?

[Ron M]

Chih-Wei,
I am a am not sure about the strategy of tackling a new version - is it tracking upstream and then cherry-picking from the previous stable android-x86 branch?

I assume it is something like this, and I currently only did the quick searches, in the log, and found that the commit that is supposed to take care of ActivityManager's isHighEndGfx() function was not present in lollipop but that doesn't help at this point. Can you please give me pointers for what to look for (in Code, in commits , in committers (suppose that would be yourself) ), assuming the following trivial modifications are not enough (and they seem to not be enough unfortunately at this point):

# This one is not in lollipop-x86 but adding it doesn't solve the issue

frameworks/base$ git show 7ef033564a797a0475b1389952109b1f8b081056

commit 7ef033564a797a0475b1389952109b1f8b081056

Author: Chih-Wei Huang <cwh...@linux.org.tw>

Date:   Thu Dec 8 20:16:29 2011 +0800

    disables hardware acceleration if debug.egl.hw=0

diff --git a/core/java/android/app/ActivityManager.java b/core/java/android/app/ActivityManager.java

index 7ca3459..522a985 100644

--- a/core/java/android/app/ActivityManager.java

+++ b/core/java/android/app/ActivityManager.java

@@ -453,9 +453,14 @@ public class ActivityManager {

      * Used by persistent processes to determine if they are running on a

      * higher-end device so should be okay using hardware drawing acceleration

      * (which tends to consume a lot more RAM).

+     * Alternatively, setting debug.egl.hw=0 disables hardware acceleration.

      * @hide

      */

     static public boolean isHighEndGfx() {

+        if ("0".equals(SystemProperties.get("debug.egl.hw"))) {

+            return false;

+        }

+

         return !isLowRamDeviceStatic() &&

                 !Resources.getSystem().getBoolean(com.android.internal.R.bool.config_avoidGfxAccel);

     }

# This one is already in lollipop-x86, but I already saw it worked before.

/system/core$ git show 59f65a204da4e071a5d6d9ff91a2dd17a3fbadc0

commit 59f65a204da4e071a5d6d9ff91a2dd17a3fbadc0

Author: Chih-Wei Huang <cwh...@linux.org.tw>

Date:   Wed Nov 21 01:50:51 2012 +0800

    init: handle DEBUG and HWACCEL variables

    

    On DEBUG=1, set debug.logcat=1 to trigger actions in class debug.

    

    On HWACCEL=0, set debug.egl.hw=0 to disable hardware acceleration.

diff --git a/init/init.c b/init/init.c

index dc8283d..b7a19f7 100644

--- a/init/init.c

+++ b/init/init.c

@@ -1055,6 +1055,9 @@ int main(int argc, char **argv)

 

     process_kernel_cmdline();

 

+    if ((tmpdev = getenv("HWACCEL")) && *tmpdev == '0') {

+        property_set("debug.egl.hw", tmpdev);

+    }

     union selinux_callback cb;

     cb.func_log = log_callback;

     selinux_set_callback(SELINUX_CB_LOG, cb);

@@ -1103,6 +1106,9 @@ int main(int argc, char **argv)

     } else {

         action_for_each_trigger("late-init", action_add_queue_tail);

     }

+    if ((tmpdev = getenv("DEBUG")) && *tmpdev) {

+        property_set("debug.logcat", *tmpdev == '0' ? "0" : "1");

+    }

 

     /* run all property triggers based on current state of the properties */

     queue_builtin_action(queue_property_triggers_action, "queue_property_triggers");

[Ron M]

Just in case anyone else cares about it, I'll post some workarounds as I go
[at least 5 people in this world should care about it - you know who you are..]

First workaround (to the qemu=1 problem)

* Enable the debug.egl.hw = 0 patch on framework/base

* That's not enough since we do not have the GLES*.so blobs for the non accelerated device.

  ** Now we have another problem if we just wanted to copy the blobs from the AOSP - they are not built in

the same way, so on run time we'll have errors on dlopen(), claiming that DT_HASH does not match

* Resolving qemu=1 not working 

  ** Background: qemu=1 triggers the software only implementation of OpenGL (libagl / libGLES_android.so )

   *** Project: frameworks/native/opengl/libagl

  ** Immediate workaround From kitkat-x86 - copy libGLES_android.so to /system/lib/egl/

  ** Or build it yourself

   *** PRODUCT_PACKAGES += libGLES_android

[Ron M]

Chih-Wei,

When going over the "missing parts", I went over the HW accelerated canvas JNI/API (for 9Patch, Path, Shaders etc.) and since it is merely a workaround, which eventually has the exact same behavior of using qemu=1 in our case [ please correct me if I'm wrong ], I think most of the patches would not be relevant, as they are due to annoying API changes  (@see:  88993bf  at framework/base/core/jni/android/graphics  , which has conflicts if trying to merge.).

This was the behavior I observed in kitkat-x86 (just using libGLES_android.so and that's it).

Am I missing something, and there is any reason to maintain that code,  or should we just force qemu and discard the patches in framework/base/../graphics?

[I am aware of qemu gles style and the efforts to do something like the QEMU-pipe, but in these cases everything is 100% software based, and there is no reason to go through the GLES20_canvas et. al pipeline) ]

The other relevant commit (I think there aren't any more, but haven't looked thoroughly) for making the VESA command line work as is without specifying "qemu=1", is in  framework/natives: (also from kitkat)

Basically it has the same effect as qemu=1 since we do not provide a qemu.gles parameter, and the effect is again using libagl.

frameworks/native$ git show 33b2cf54

commit 33b2cf54f190b06d3c793ad73dea196c344832b5

Author: Chih-Wei Huang <cwh...@linux.org.tw>

Date:   Sun Jan 6 16:56:00 2013 +0800

    disables hardware acceleration if debug.egl.hw=0

diff --git a/opengl/libs/EGL/Loader.cpp b/opengl/libs/EGL/Loader.cpp

index 02914a0..a596ecb 100644

--- a/opengl/libs/EGL/Loader.cpp

+++ b/opengl/libs/EGL/Loader.cpp

@@ -86,6 +86,13 @@ checkGlesEmulationStatus(void)

     char  prop[PROPERTY_VALUE_MAX];

     int   result = -1;

 

+    /* Check if hardware acceleration disabled explicitly */

+    property_get("debug.egl.hw", prop, "1");

+    if (!atoi(prop)) {

+        ALOGD("3D hardware acceleration is disabled");

+        return 0;

+    }

+

     /* First, check for qemu=1 */

     property_get("ro.kernel.qemu",prop,"0");

     if (atoi(prop) != 1)

Would appreciate the feedback.

-Ron M

[Chih-Wei Huang]

I think you have found the essential commits.
Try to apply them.
But I think there are some conflicts.
That's why I skipped them in the initial porting.

I'm not sure what you meant qemu=1.
Did you mean a property or something else?

Seems libGLES_android is no longer a default module.
You may need to add it to the packages.mk.

> --
> You received this message because you are subscribed to the Google Groups
> "Android-x86" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to android-x86...@googlegroups.com.
> To post to this group, send email to andro...@googlegroups.com.
> Visit this group at http://groups.google.com/group/android-x86.
> For more options, visit https://groups.google.com/d/optout.

[Ron Munitz]

Hi,
I already did all of that, no worries.

Qemu=1 is a kernel cmdline (ro.kernel.qemu) that forces the system to use the libagl (libGLES_android.so).

There are basically 3 modes of operation:
Software, egl translation (I.e. qemu pipe or whatever, defined by qemu.gles property) and full he acceleration.

As you said the view/accelerated canvas patch has conflicts, and my question was if we really even need them. Speaking of merging I really think it's a pain in the ***, as the debug.egl.hw config achieves the exact same purpose from what I know - but we may be missing something.

I did not bother to resolve the conflicts in the jni part (GLES20 canvas et al) because of that, and because actually there were API changes I don't think we should care about, and so we can get rid of the added "useOpenGlRenderer()" checks in them which are ax86 patches.
Do you think otherwise?

You received this message because you are subscribed to a topic in the Google Groups "Android-x86" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/android-x86/n8jrP4BuCnU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to android-x86...@googlegroups.com.

[ma...@xemi.net]

I have set qemu=1 to force using the libGLES_android.so, and have also added this into the build. However, I get the following error:

no suitable EGLConfig found, giving up

How did you get around this?

[Ron Munitz]

What does your logcat say? Do you have the shared object in /system/lib ?

[Uno]

Hi, Ron.
Thanks for your post!
I applied your recommendation.
When I run Lollipop 5.1 in VirtualBox LogCat shows:

I/SurfaceFlinger( 1056): SurfaceFlinger is starting
I/SurfaceFlinger( 1056): SurfaceFlinger's main thread ready to run. Initializing graphics H/W...
D/libEGL  ( 1056): 3D software emulation enabled
D/libEGL  ( 1056): Emulator without GPU support detected. Fallback to software renderer.
D/libEGL  ( 1056): loaded /system/lib/egl/libGLES_android.so
W/gralloc ( 1056): page flipping not supported (yres_virtual=768, requested=1536)
I/gralloc ( 1056): using (fd=11)
I/gralloc ( 1056): id           = VESA VGA
I/gralloc ( 1056): xres         = 1024 px
I/gralloc ( 1056): yres         = 768 px
I/gralloc ( 1056): xres_virtual = 1024 px
I/gralloc ( 1056): yres_virtual = 768 px
I/gralloc ( 1056): bpp          = 16
I/gralloc ( 1056): r            = 11:5
I/gralloc ( 1056): g            =  5:6
I/gralloc ( 1056): b            =  0:5
I/gralloc ( 1056): width        = 163 mm (159.568100 dpi)
I/gralloc ( 1056): height       = 122 mm (159.895081 dpi)
I/gralloc ( 1056): refresh rate = 65.46 Hz
W/hwcomposer( 1056): getting VSYNC period from fb HAL: 15275339
D/hwcomposer( 1056): Intel hwcomposer module
I/SurfaceFlinger( 1056): Using composer version 1.0
W/SurfaceFlinger( 1056): no suitable EGLConfig found, trying a simpler query
W/SurfaceFlinger( 1056): EGL_SLOW_CONFIG selected!
I/SurfaceFlinger( 1056): EGL information:
I/SurfaceFlinger( 1056): vendor    : Android
I/SurfaceFlinger( 1056): version   : 1.4 Android META-EGL
I/SurfaceFlinger( 1056): extensions: EGL_KHR_get_all_proc_addresses EGL_ANDROID_presentation_time EGL_KHR_image_base EGL_KHR_fence_sync EGL_ANDROID_image_native_buffer

And when I try to run Gallery app I get error in LogCat:

E/AndroidRuntime( 2052): FATAL EXCEPTION: GLThread 130
E/AndroidRuntime( 2052): Process: com.android.gallery3d, PID: 2052
E/AndroidRuntime( 2052): java.lang.IllegalArgumentException: No configs match configSpec
E/AndroidRuntime( 2052):        at android.opengl.GLSurfaceView$BaseConfigChooser.chooseConfig(GLSurfaceView.java:858)
E/AndroidRuntime( 2052):        at android.opengl.GLSurfaceView$EglHelper.start(GLSurfaceView.java:1023)
E/AndroidRuntime( 2052):        at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1400)
E/AndroidRuntime( 2052):        at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1239)
W/ActivityManager( 1222):   Force finishing activity 1 com.android.gallery3d/.app.GalleryActivity
D/PermissionCache( 1056): checking android.permission.READ_FRAME_BUFFER for uid=1000 => granted (39 us)
D/gralloc ( 1056): Registering a buffer in the process that created it. This may cause memory ordering problems.
E/libEGL  ( 1056): called unimplemented OpenGL ES API
E/SurfaceFlinger( 1056): glCheckFramebufferStatusOES error 439811147
E/SurfaceFlinger( 1056): got GL_FRAMEBUFFER_COMPLETE_OES error while taking screenshot
W/WindowManager( 1222): Screenshot failure taking screenshot for (1024x768) to layer 21010

How can I enable software support for GLES?

[Chih-Wei Huang]

2015-12-17 22:15 GMT+08:00 Uno <uno...@gmail.com>:
>
>
> How can I enable software support for GLES?

GLES is not supported in VM yet.