Hikey960 Android 8.1.0 Slow rendering

Products Support HiKey 960
#1

Hello everyone,

I’m currently trying to put an Android 8.1.0 on my Hikey960. Problem is that the rendering is very slow. (Maybe, the hardware acceleration isn’t supported by the kernel version, v4.4)
When I’m trying to update it (v4.9), the system is not booting anymore. Do you have any solution for this ?

On Master branch, I have an Android P available, everything works fine except that we are not root on the image so it’s difficult to develop something on it.

In summary, I would like to get a version (> 8.0.0) on which I’ll be able to connect via ADB and with a hardware acceleration for the display. Do you know the best branch on google source to pull ?

Thank you for helping.

Hikey960 desktop rpb usb mouse and keyboard response slower
#2

Hikey 960 is not fully supported by stable branch of AOSP. You need to use MASTER branch.
Further, it would be better to post hikey960 questions in the hikey960 section.

(to clarify, this thread was since moved. It was originally in the hikey (620) section).

#3

I realize it’s not technically supported, but:

Add android.hardware.graphics.composer@2.1-impl to PRODUCT_PACKAGES in buildroot/device/linaro/hikey/hikey960.mk

From AOSP master, grab platform/hardware/interfaces ($R below).
Replace buildroot/interfaces/hardware/graphics/composer/2.1/default with $R/hardware/graphics/composer/2.1/default.
Copy $R/hardware/graphics/composer/2.1/utils/hwc2onfbadapter to buildroot/frameworks/native/libs/

Finally, in buildroot/frameworks/native/services/surfaceflinger/EventThread.cpp:

diff --git a/services/surfaceflinger/EventThread.cpp b/services/surfaceflinger/EventThread.cpp
index a9bb2ba0e..6dca9a62b 100644
--- a/services/surfaceflinger/EventThread.cpp
+++ b/services/surfaceflinger/EventThread.cpp
@@ -46,7 +46,7 @@ static void vsyncOffCallback(union sigval val) {
 EventThread::EventThread(const sp<VSyncSource>& src, SurfaceFlinger& flinger, bool interceptVSyncs)
     : mVSyncSource(src),
       mFlinger(flinger),
-      mUseSoftwareVSync(false),
+      mUseSoftwareVSync(true),
       mVsyncEnabled(false),
       mDebugVsyncEnabled(false),
       mVsyncHintSent(false),
@@ -137,21 +137,25 @@ void EventThread::requestNextVsync(
 }
 
 void EventThread::onScreenReleased() {
+#if 0
     Mutex::Autolock _l(mLock);
     if (!mUseSoftwareVSync) {
         // disable reliance on h/w vsync
         mUseSoftwareVSync = true;
         mCondition.broadcast();
     }
+#endif
 }
 
 void EventThread::onScreenAcquired() {
+#if 0
     Mutex::Autolock _l(mLock);
     if (mUseSoftwareVSync) {
         // resume use of h/w vsync
         mUseSoftwareVSync = false;
         mCondition.broadcast();
     }
+#endif
 }
 
 void EventThread::onVSyncEvent(nsecs_t timestamp) {
@@ -317,7 +321,7 @@ Vector< sp<EventThread::Connection> > EventThread::waitForEvent(
                 // We don't want to stall if there's a driver bug, so we
                 // use a (long) timeout when waiting for h/w vsync, and
                 // generate fake events when necessary.
-                bool softwareSync = mUseSoftwareVSync;
+                bool softwareSync = true; // mUseSoftwareVSync;
                 nsecs_t timeout = softwareSync ? ms2ns(16) : ms2ns(1000);
                 if (mCondition.waitRelative(mLock, timeout) == TIMED_OUT) {
                     if (!softwareSync) {

It’s not perfect - I’m getting the occasional system_server crash but it is up and working.

EDIT - the system_server crash seems to be gone. Forced ICU 61 in place of ICU 58.2 in external/icu, which is where system_server was crashing, rebuilt, and it seems to be working correctly now.

#4

I realize it’s not technically supported, but:

Thanks for sharing. Unsupported certainly doesn’t mean we think that
interested users shouldn’t hack in any interesting way they please!