yashsingh1/xdaforums huggingface dataset:
[Nexus S Android Development] cn.fyodor:
Thanks for the debug info. Will checkout this code snippet as soon as possible. Actually I also investigated WebView issue days ago, current driver does support GLES 2.0, but not fully support. WebView is also not always broken, I got black screen randomly. Seems that the buffer has been cleaned/freed up before GPU composition. I tend to think about it as an Android chromium bug on PVR GPU.

The fix commit has been pushed yesterday, check it here.
[Nexus S Android Development] DarkShadow69:
Guys have a look at this. Installed latest PA Gapps and changed the runtime from "Dalvik" to "ART". After rebooting twice phone is more snappier and responsive now. Also getting 200+ free mbs of ram :D

Note: Some apps might not work after this. For me SuperSu, Greenify, Titanium Backup, Whatsapp, Stock Camera (but third party camera apps are working) are not working. Also every time you reboot you have to let your phone some time to fully load. So I suggest do make a backup before trying.
[Nexus S Android Development] keb00:
Finally a 4.4 ROM, good work guys!:good:
[Nexus S Android Development] Setting.Out:
In your signature it says Black Android, did you get a port of team baked's rom?
[Nexus S Android Development] Viadanna:
I've attached the full kmsg in case you need.

Today while updating Google+ something odd (quite funny, actually) happened: the phone seemed to reboot, going to the ANDROID boot animation. But it didn't actually reboot, I didn't lose my adb shell.

Trying to update again, the same thing happened, and I saw that it didn't get to show the Google logo, went straight to ANDROID animation, again without losing adb shell.

Checked kmsg and didn't find anything, but I managed get a logcat of the odd 'reboot'. Turns out I cannot upgrade Plus for now, probably related to me running on ART.

I was looking to build from source to cherry-pick some cyanogen and slim features; I could build successfully with your android_device_samsung_crespo and google's kitkat source tree, but it didn't even get to the ANDROID animation after flashing, saying I was missing gles2 drivers. Do i have to manually add the drivers to the package?
[Nexus S Android Development] khalid_ham33d:
I am also running ART and my Google+ updated successfully... May be that's a problem with your GApps package... :)
[Nexus S Android Development] nelars:
Which gapps are you using? If you don't mind sharing.
[Nexus S Android Development] khalid_ham33d:
PA GApps... They are the best I've tried until now... They work flawlessly with ART... :)
[Nexus S Android Development] ghanchi2000:
Working like a charm ... grt rom ... thank you for your effort ... now i own latest software on my Nexus S
[Nexus S Android Development] keb00:
Nop, it's the colour of my nexus :p
[Nexus S Android Development] lvnatic:
Can anyone tell me how is this as a daily driver? Is dialer, SMS, camera and browser working?
[Nexus S Android Development] DarkShadow69:
It can be used as daily driver. Dialer, sms, camera are working. Also known bugs are in first post.

You'll get black screen on default browser but you can use other browsers like opera to avoid this.:)
[Nexus S Android Development] ethan_hines:
I know this was mentioned in the OP but the flashing black screen on web apps is annoying. Is there a patch? fix? workaround? Also noticed the final flash version (Version 11.1.115.81 ) does not work on 4.4. I know there's been a migration towards HTML5 but it's being picked up as quickly as HDDVD and the website I go to deals exclusively in flash video.
[Nexus S Android Development] DominikHolecek:
What about free RAM and gaming on this ROM? I Know that this is only the 2nd release, but I can't wait to stable builds, where will be everything smoother and improved... So I want to know if you see some RAM and speed improvements as Google promised. And I can't try this ROM myself too, because I haven't got this device... ;) I have a high-end device from Samsung but I have an old one, which can be compared with this one, too and I want to know if my Xperia Arc S will be able to fly with Android Kitkat again like on Gingerbread... So my other question: Is GB still better in games and speed than KitKat? :)
[Nexus S Android Development] jwee5467:
As far as I can tell, it is on par with previous versions for performance if not better. The memory management is amazing compared to any other 4.x versions so far. The only gripe i have is the battery usage by phone app keeping the device awake. Still testing this and figuring out a solution. Any help would be appreciated.
[Nexus S Android Development] ElmirBuljubasic:
You can add "ro.config.low_ram=true" to /system/build.prop for better RAM. (My SGS after reboot)
[Nexus S Android Development] leap_ahead:
[MENTION=2253579]cn.fyodor[/MENTION] try this for black screen on webview http://review.cyanogenmod.org/#/c/53284/
[Nexus S Android Development] mushan3420:
Google Dialer ported! Works well.

http://xdaforums.com/showthread.php?p=47474593
[Nexus S Android Development] cn.fyodor:
Did you install Wake lock detector app to get more information? It seems some resources were locked and being used by the Dialer app, NFC or GPS etc.

The function PixelFormatInfo was used by the old webkit. I don't know why they added it back and what it would fix. But I'm sure it does nothing with webview. First, NS never turned on the flag BOARD_HAVE_PIXEL_FORMAT_INFO; second, webkit has been totally replaced by chromium, there is no libwebkit.so in KitKat any more.
[Nexus S Android Development] khalid_ham33d:
Yup, it is... Working fine... :)
[Nexus S Android Development] steven676:
To add to this: I actually backported the new Chromium WebView to 4.3 -- the black squares still happen. That basically rules out everything except the PVR graphics drivers, the WebView and Chromium code, and Skia (which I had to backport as well to get Chromium to build) as potential sources of the problem.

As far as I can tell, the black squares happen when Chromium calls into eglCreateImageKHR() (in libEGL.so, but I think that just wraps the EGL blob provided by the PVR driver) and the resulting call fails. The puzzling part is that the call succeeds a lot of the time, and some time spent with the debugger doesn't reveal any pattern to which calls succeed and which ones fail. On tuna (Galaxy Nexus), you also have a message regarding the flags passed to the driver when locking a buffer not matching those used when creating the buffer -- I'm not clear as to whether that's a separate issue for tuna/OMAP4, or whether that's the root cause of the problem on all PowerVR devices and the tuna driver is just more verbose than the crespo one. (The flags decode to GRALLOC_USAGE_HW_TEXTURE for one and GRALLOC_USAGE_SW_READ_OFTEN|GRALLOC_USAGE_SW_WRITE_OFTEN for the other, but I haven't had any luck finding the point(s) in the code where these flags are set, either by searching through the source or by using the debugger.)
[Nexus S Android Development] Setting.Out:
May be a stupid question, but could you build it using the old drivers, libs and browser?..
[Nexus S Android Development] superng888:
i've installed 6.0.4.3 but still no go :confused:
[Nexus S Android Development] cn.fyodor:
You've done lots of crazy porting works. lol I also tried to revert some webkit commits in frameworks and build the old webkit library, but finally gave up because of too many compiling errors. Anyway they deserve a try and now ruled out everything but PVR drivers, thanks for all efforts. :P

One part of black square issue that I can't understand is, after I added some ALOGD into where EGL_BAD_PARAMETER error returned by eglCreateImageKHR() in libEGL.so, I got nothing but 12300 error (the code of EGL_BAD_PARAMETER) returned by libwebviewchromium.so. Then I lost the clue. I agree with you that libEGL.so is just a wrapper to EGL blobs. So the root cause is still in the proprieties which we can't debug. Also I think blobs in GN are nearly the same as in NS since both PVR drivers in their kernels have few difference. They didn't push too many codes into GN kernel after they stopped supporting NS. We are probably in the same boat.

I haven't investigated too much like you did. Sorry I can't give points on the passing flags in drivers. But the behavior of this issue gives me some hints. I open the Email app and touch one of subjects, swipe left and right slowly, then the issue would not happen and every texture shows as normal. If swipe a bit faster, black square happens immediately. It seems the GPU buffer was cleaned up so slowly that there is no more memory left for WebView to get the next buffer. As one chromium dev said in issue feedback, they never tested chromium with any PVR GPU. Seems we have to fix the bug ourselves for PVR. It's a bit disappointing esp. when we don't know where to start.
[Nexus S Android Development] jwee5467:
I did not. Apparently kitkat broke that app so that is a problem. I can see that my phone doesn't sleep or idle and the phone app is responsible for this according to android battery stats. Anyone else have a similar problem?
[Nexus S Android Development] steven676:
Using the old WebKit and WebViewClassic isn't a long-term solution in any case. The new WebKit is much more capable than the old one; while it's not possible for anyone to depend on those extra features right now, as time goes on, HTML5 app developers are going to start using those new features, and using WebViewClassic is going to break those apps. Also, unless we plan on identifying and backporting security fixes for WebKit (something which even stability-obsessed Linux distributions have given up on), the old WebKit is going to become an increasing security liability.

I haven't had any more luck finding a cause for that error in digging around the code -- I fear you're right about that being concealed in the blobs. (Side note: when the Valve guys started porting their 3D games to Linux, they were gearing up for the big runaround that happens when studios report driver problems to the graphics card vendors -- and were shocked when the Intel Linux guys told them "you know, our drivers are fully open-source, so you can look into them yourself"! Being able to delve into debugging the driver was apparently a great help to them.)

Actually, that suggests to me that it could be some sort of race condition in the PVR drivers -- perhaps when one eglCreateImageKHR() call comes in while some other request is still being handled, bad things happen?

Do you have a link to that discussion? I'd be interested to see what they say. That said, if you look through the Chromium code, it seems like half the GL rendering code consists of workarounds for GPU driver bugs, including PVR ones (usually referred to as "IMG" or "Imgtec" in the Chromium code). Also, we know Chrome 30 for Android (30.0.1599.92) works fine on PVR systems ... it might be worth running a diff between the Chromium 30 codebase and the Android fork in external/chromium_org to see if the bug was introduced by the Android team. That said, I suspect the real reason for the difference is that Chrome for Android and the Android Chromium-based WebView use the underlying code differently ... but I have no idea where that difference might lie or where to start looking for it. (It would be really helpful to hear from Chromium codebase experts here.)
[Nexus S Android Development] treesurf:
I seem to recall hearing that the GNex uses similar graphics to the the Nexus S. Are they having the same issue?
[Nexus S Android Development] Zahih:
[MENTION=2253579]cn.fyodor[/MENTION] & [MENTION=4353291]steven676[/MENTION]: Even I don't understand you guys talking about (lol... 'user only' viewpoint).

But it really excited when 2 great Devs working together to support kitkat in this 'old device'...

Thank U.. Thank U.. And Thank U...
[Nexus S Android Development] cn.fyodor:
Oh sorry, forgot that app has not been updated to work on 4.4. But still it's weird. I have no idea for now.

I don't know how the new WebView works on QCOM Adreno GPUs. Google made a work around for QCOM when releasing texture resources. I also tried to do the same thing for our GPU, but still got black square issue. If it's a race condition issue, I think other devices can't be survived. After searching a lot around, there seems no other similar reports except from PVR users. Or is their developing progress on KitKat still not reaching so far as we did? lol

The chromium issue was discussed here. It's indeed a bit old though, but our EGL blobs are deprecated as well. If we wanna look into the difference between android forked webview and chromium original one, there are probably a lot. I doubt we can find out the root cause in such a huge messing codes. :P I think it's a bit hasty that Google fully switched to chromium-based WebView, which seems still in early developing stage for Android.
[Nexus S Android Development] steven676:
The Qualcomms work fine (Nexus 4, Nexus 5, and Nexus 7 2013 are all Adrenos). Tegra 3 (Nexus 7 2012) and Mali T-604 (Nexus 10) should also be okay. In terms of broadly deployed GPUs used with Android, that pretty much just leaves the PowerVR 5 series ... That said, Samsung will have to confront this issue at some point (Exynos5410 uses a PowerVR GPU). (Of course, that does us no good if Samsung gets Imgtec to fix the driver bug(s), because we're never going to see an updated driver with the fix :( )

I was suggesting that it might be a race condition in the driver itself, not in Chromium -- threading bugs in GL drivers are not uncommon.

Old, but not nearly that old. Also, X11 (as used on ChromeOS) requires a different EGL implementation than SurfaceFlinger, so it's likely that that specific bug doesn't apply to us. Some other bugs in the Chromium bug tracker suggest that Galaxy Nexus was used by the automated test system for Android until recently, so I think Google expects (or expected at one point, at least) the code to work on PVR GPUs. (That said, I suspect the regression test is building Chrome instead of the Android WebView, and those are different products -- there's at least one patch in the Chromium tree regarding a GPU rendering bug that affects one but not the other.)

I agree, which is why I haven't done it yet :P I'm really not sure what other angles we can approach this problem from, though.
[Nexus S Android Development] cn.fyodor:
That's reasonable. I also think the PVR drivers in the kernel had some bugs unrevealed or unresolved by Google. But it might be Imgtec's duty to fix driver bugs, not Google.

Yesterday I was looking around in SurfaceFlinger.cpp. I found the native screen capture also calls eglCreateImageKHR() function with the same target but difference buffer source and NULL EGL attrs. This capture implementation was also firstly introduced in 4.4 probably for performance. As you know, screen capture never fails in our devices. The buffer used in screen capture was dequeued from the current window. I tried the KHR function with NULL attrs in chromium, but still no luck. So I think the possible bad parameter error could be only caused by the EGL buffer management. When the WebView requests buffer of EGL_CLIENT_BUFFER type, GLImageEGL::Initialize will be called. It's done by the case-switch code in gl_image_android.cc. But it seems difficult to trace the buffer usage in chromium. Did you try it? xD
[Nexus S Android Development] darkmentor25:
Snappier !!

RAM usage is below 260-280 MB

But webview is broken renders the new Email app and Google Now useless :(

Thanks devs for the awesome job !
[Nexus S Android Development] dabotsonline:
Just looking at your screenshot, [MENTION=4651263]darkmentor25[/MENTION] : how did you manage to get GoogleDialer working on the Nexus S?
[Nexus S Android Development] k-kuchen:
This was posted on the previous page:

http://xdaforums.com/showthread.php?t=2526844
[Nexus S Android Development] Setting.Out:
[MENTION=2253579]cn.fyodor[/MENTION] if I swap out all the webview related files for 4.3 files would that work as a temporary fix?
[Nexus S Android Development] V_tunes:
THX, it just looks like nexus s is alive. it's so smooth by now. cn.fyodor u r a chinese right ? because i am. Nice to see u here.
[Nexus S Android Development] velishka:
Very good ROM indeed. Running it from the day one, so far so good.

I tested bluetooth btw, works like a charm.

Are you planning MTP support? Can't speak for everyone here but for me personally mtp support will make it almost perfect
[Nexus S Android Development] leap_ahead:
flash marmite kernel my friend
[Nexus S Android Development] velishka:
I know and I tried but this one give be better perfomance for some reason.
[Nexus S Android Development] leap_ahead:
you delete libstagefright.omx.so from kernel zip ?
[Nexus S Android Development] cn.fyodor:
你好，：）

MTP driver in the Kernel was originally supported, just their usb triggers were missing. I don't enable it since Google did not do that for NS and MTP on Linux distribution makes too much pain. No Windows on my box for testing. Anyway I'll add the MTP part that should reside in ramdisk. So next time you can manually get it working with less pain. :P
[Nexus S Android Development] V_tunes:
i have a question, is that possible to remap the search button to "recent apps" function, cause you know google now is now fully in the Heaven Dynasty, i search with google, the method is designed for 3.x and 2.x but jelly bean.
[Nexus S Android Development] leap_ahead:
Webaudiores.apk is not working
[Nexus S Android Development] cn.fyodor:
Why remap Search button to Recent apps? Holding Home btn brings you to Recent apps. And Google now can easily be triggered anywhere by pressing the Search btn. The stock Search btn function is disabled until gapps are installed. I changed this behavior so that you can use the Search btn in search-supported apps, ie. search-in-app function. Just think it's more reasonable and doesn't need any changes so far. Actually I can't get the point. xD

Well this apk just contains audio resources for Webkit afaik.
[Nexus S Android Development] leap_ahead:
is not working ..this package can not parsing ..

I like the search in app !! thanks
[Nexus S Android Development] lagloose:
Absolutely right. IMHO this build should have original AOSP behaviour as far as possible. No 'special' programming and changes. But this is just my opinion. It's cn.fyodor's decision...
[Nexus S Android Development] velishka:
Agree.

Running for 4 days now. Can't be happier.

Also figured out my problem with marmite kernel. Turns out I needed CM version.
[Nexus S Android Development] sniperIT:
Seriously awesome ROM.

The memory management is the key here, it's silky smooth. Chrome is actually usable and doesn't turn the phone into a slideshow.

Although I do miss a few of the advanced features of CM 10.2, the only real thing that i miss is the gesture typing.

Other than that it's hard to say that there are any other changes to make.

I did have a few reboots when i was installing and I had an error, but it seems to be running just fine and I haven't had any huge issues. I may just do a reinstall for arguments sake but it looks good.

If I get the error again I'll post it.

EDIT: the message I got was "Warning: No file_contexts"

But the install completed.
[Nexus S Android Development] rho57:
Use google keyboard if you want gesture typing. If it isnt available on the Play Store, look for an apk on the net.

Sent from my Nexus S
[Nexus S Android Development] velishka:
First bug to report: Auto rotate doesn't work all the time. The only solution is restart. I had similar problem with some other rom (I don't remember which one) so it's very much the same.

I'm using marmite kernel at the moment.

Also, are we getting JSS15Q, i think it was pushed to aosp?
[Nexus S Android Development] cn.fyodor:
Hmm, next time when this bug comes up, please get the logcat or kernel dmesg via 'adb shell dmesg' for me. I haven't run into this issue so far. Afaik sensor HAL didn't change in 4.3. And the kernel version doesn't matter for auto rotation as well.

And yes, we certainly will get JSS15Q, which just pulls few security patches though.
[Nexus S Android Development] rho57:
Will there be future updates on this rom?
[Nexus S Android Development] leap_ahead:
one bug :FLash player not working for me after renistal rom
[Nexus S Android Development] mr.haqeem:
music fx crash evrytime i want to choose music effect.
[Nexus S Android Development] down4life:
Cant get GoogleDialer to work... Tried post on previous page, tried bank gappa googledialer, but no go...
[Nexus S Android Development] raducux:
Try PA gapps.
[Nexus S Android Development] down4life:
I'm using PA gapps, but when I want to flash GoogleDialer from N5, I have no signal...wierd:S
[Nexus S Android Development] DarkShadow69:
I was also having the same issue plus process.com.phone FC
[Nexus S Android Development] spider623:
Pa includes the dialer
[Nexus S Android Development] k-kuchen:
Did anybody try Devil Kernel with this ROM?
[Nexus S Android Development] CataHd:
Are there any significant changes in r1.1 that might help our device?
[Nexus S Android Development] jwee5467:
Breaks play store I think. Otherwise very snappy.
[Nexus S Android Development] cn.fyodor:
I'm so sorry for the late reply. I'm really very busy those days. Very excellent work and glad to see you found out where the context switches. Thank you Steven. I think it would be the right direction for working around PVR drivers. I totally agree with you that since we can't touch the driver, there is only one way to bypass its bugs. I just tried to disable GPU rendering in chromium, but WebView was broken, no web contents could be shown there. Or if disabling GPU acceleration, no effects and still black squares were shown. Your patch notifies the WebView not to directly map image buffer to the GPU, right? This switch had been hard-coded to be enabled in original chromium repo. So sounds impossible to bypass the GPU stuff. I think we can try Pixel Buffer Object to replace EGLImage since Android 4.3, Ref. If there are still buffer management bugs between chromium and EGL, PBO should also not be survived. But it may deserve a try.
[Nexus S Android Development] dabotsonline:
or even r1.2:

http://www.androidpolice.com/2013/1...s-and-aosp-are-already-up/#comment-1130740982
[Nexus S Android Development] Viadanna:
Looks like CM team got a workaround for EGL. Not sure how well it does, I won't be able to build for a few weeks.

https://github.com/CyanogenMod/android_device_samsung_crespo/commit/7c33d8e2ce1dd903cdd4eeb8efa92598ea49d547
[Nexus S Android Development] steven676:
I think these (or rather, the fixes they enable in core Android code) are already included in all the 4.4-based software releases out there for crespo.

Excellent news on this front: cdesai and klusark found a patch in the Chromium trunk which fixes the WebView rendering bug on PVR devices and backported it to the Chromium snapshot that's part of 4.4. (The fact that it's part of the mainline Chromium code also means that we shouldn't face this problem again when upgrading to future Android releases.)
[Nexus S Android Development] Dark_Eyes_:
Which means it's fixed?
[Nexus S Android Development] sikahr:
I can confirm that black boxes on webview is fixed with this code review.

I tested this on my Kindle Fire with same fix applied.
[Nexus S Android Development] leap_ahead:
good news !!! so [MENTION=2253579]cn.fyodor[/MENTION] we can now have a rom with this and app to usb storage????
[Nexus S Android Development] cn.fyodor:
Yeah, klusark has notified me about this patch. Wonderful work! Thank you, guys.

Definitely, and we'll also get 4.4_r1.2 updates with minor fixes. :P
[Nexus S Android Development] Dark_Eyes_:
Woohoo!

Just so every one knows... klusark is the maintainer for crespo at cm. I think we are very lucky to have him... That was a problem that inflicted a LOT of devices and it's the old crespo that fixed it. Thanks a lot to fyodor and Steven for there great work as well!

You guys made my day... Nay week!
[Nexus S Android Development] leap_ahead:
[MENTION=2253579]cn.fyodor[/MENTION] on new build you can fix superuser and bln pls ?
[Nexus S Android Development] k-kuchen:
What is wrong with BLN and superuser? Works for me