ARM engineers at Mali Developer Center have confirmed a bug in current version of Nexus 10 video driver.
Bug causes incorrect rendering to to external rendertarget if device is not in default orientation.
Bug is filed and confirmed by ARM here: http://forums.arm.com/index.php?/to...et-works-only-in-landscape/page__gopid__41612
I've also added an issue to Google bug tracker. Please support this issue by starring it here: http://code.google.com/p/android/issues/detail?id=57391 . The more stars it has the more chances for Google to pay attention to it and to include a fix in next firmware update.
You can see that bug has detailed steps to reproduce and test APK attached, so everyone can test it.
As I stated, bug is already tested and confirmed by ARM engineers so please go and star issue #57391 to make Nexus10 less buggy!
Related
Hello everyone,
I'm the developer of the Tiny Graphics Engine ("Tigre").Two days ago I recived a HD2 test sample and now i discovered a general problem with opengl that affects ALL OPEN GL Applications, no matter if the graphics patch is installed or not. The problem is the following: if sense is enabled and you start any opengl application it works fine. If you terminate and restart the application multiple times, it will crash and you cannot start any opengl app anymore without softresetting. I investigated a bit and found the problem: While creating the EGL context the EGL_BAD_ALLOC error occurs. I'm pretty sure my EGL setup is fine, because a) it work for about 5-7 times b) on the touch hd the error doesn't occur and all other opengl apps i tested have the same issue.
So, does anyone has the same problem, any idea or solution?
PS: its the original 1.66 Rom
I found the solution, just don't terminate the display. Not proper, but seems to work, also with silvermoon and all other opengl apps.
bro, please develope interesting opengl 2.0 game ya
Im working on a game called TrailRacer3D, of course it is powered by my engine that will support opengl 2 soon, so there will be such effects and I hop to show some more screenshots and infos soon The attached snapshot shows the menu, more detailed infos as soon as I'm ready...
Phippu said:
Im working on a game called TrailRacer3D, of course it is powered by my engine that will support opengl 2 soon, so there will be such effects and I hop to show some more screenshots and infos soon The attached snapshot shows the menu, more detailed infos as soon as I'm ready...
Click to expand...
Click to collapse
good luck with your game
Thank you, maybe I'll need some beta testers in 2-3 weeks
I installed Evil_Alex_Unleashed ver 1.0 on my 501 and it mostly works great. I do however have problems with OpenGL:
Some Games freeze (Ritide GP, Beach Buggy)
Some Games just crash (Clouds & Sheep, Google Maps)
Rebooting the tablet often fixes the problem, but only for a limited time.
I can PM a logcat of such a crash, but don't want to post it (may contain other information).
The developers of Clouds & Sheep reckon that in their case OpenGL is crashing, potentially due to a driver problem. Can't say with certainty whether the other apps also crash because of OpenGL or due to some other problem, but it does seem likely. I did not have those problems with HC.
Does anybody else have those problems (Evil_Alex or stock ICS)? Is there a fix?
This is a well known problem. AFAIK it is caused by a memory leak in OpenGLES in graphic driver for ICS/JB. This also breaks Chrome browser after some time.
follow-up questions
yaworski said:
This is a well known problem. AFAIK it is caused by a memory leak in OpenGLES in graphic driver for ICS/JB. This also breaks Chrome browser after some time.
Click to expand...
Click to collapse
Thanks. Some follow-up questions:
Is this a problem specific to Evil_Alex, the Iconia 501, or any ICS/JB device?
Where can I find more info on this problem?
Is there a work-around or fix for the problem (e.g. give the driver more memory, use a different driver, ...)?
Does this problem affect everybody, or just some tablets?
Cheers,
Carsten
@ich23: I'm not sure but it seems it affects at least all ICS/JB based firmwares for Tegra2 based Acer tablets. I don't know if other Tegra2 devices are affected too as I don't follow threads on forums for those devices.
We're developing live wallpaper with OpenGL ES 2.0 on Nexus 10.
Live wallpaper uses 2 small (128x128) external framebuffers to make ping-pong rendering between them to blur image.
While this works perfectly fine on any device (even on aged Motorola Milestone) there is a strange issue with Nexus 10. This works only if device is in landscape orientation. If device is rotated in any other position (90, 180 or 270 degrees) framebuffers has only clear color. I've set glClearColor to red so it is clearly visible that these framebuffers are cleared but nothing is rendered into them.
I've tested it on Tegra 2, Tegra 3, Adreno 200, Adreno 320, 2 PowerVR GPUs and it works just fine.
This looks like some weird driver bug, but might also be some specifics of Mali driver. That's why I ask you to test app and confirm or decline this misbehavior on your devices.
You can download test APK here: https://dl.dropboxusercontent.com/u/7197208/LiveWallpaperAnimTest.apk It is a live wallpaper app, install it and select 'Test' live wallpaper (has an icon with rose).
As you can see, in default landscape orientation you will see some 'bloom' effect around bird which is implemented by ping-pong rendering between 2 framebuffers. In any other device orientation it doesn't work and fills FB with clear color (red).
If you confirm this issue and you are registered on Mali Developer Center you can reply to this thread to drag more attention to it: http://forums.arm.com/index.php?/to...xternal-rendertarget-works-only-in-landscape/
Also I've posted a related question on StackOverflow (with code samples), filed a bug to Google Code and Mali Developer Center:
http://stackoverflow.com/questions/...external-rendertarget-works-only-in-landscape
http://code.google.com/p/android/issues/detail?id=57391
http://forums.arm.com/index.php?/to...xternal-rendertarget-works-only-in-landscape/
By confirming issue on Google Play or Mali Developer Center you will draw attention of Android developers, making it possible for them to pay attention for this issue and release a fix.
Hey,
I didnt know where i should Post my Bug Report so if its the wrong section dont hold back to tell me.
I'm currently using my Galaxy S2 for daily use and after flashing some Kitkat Roms Omni is in my opinion the most stable rom and with Nova + ART a damn fast Rom, so thank you very much for supporting my Device.
I dont know whats happening the last weeks but it all began with an Opendelta Issue, i wiped all Data / Factory Reset via TWRP and flashed the Rom completely new and OpenDelta still didnt work, it just said every day its all up2date. Now after a couple of days it is working again, dont know if it was a Server Issue or something else - at the official Omni Page no one post News so i have always to guess whats happening
Currently i found 2 Bugs, if you want to call someone you open up the Dialer and then the Button for the Numbers but after clicking it, theres nothing(Screenshot is attached). You have to go back and try it again then the Numbers are there. The second Problem is that there is no Zoom in the AOSP Camera App if you record a Video. My currently workaround is the Google Camera App, there all is working fine. Also there are some Issues with Apollo , freezing , doesnt update the Song DB etc. , dont know why its so popular - its horrible. Replaced it also with a 3rd party App - Omich/Rocket Player.
The last Problem is that not everywhere in the Settings the correct language is used, if you need some translation help im sure many users would like to help(including me) but that is in my opinion nothing critical .
...and sorry if my Text was hard to read, its not my native language but im working on it :silly:
Regards
Per the FAQ, this is not the place to put bug reports.
However, I9100 hasn't been maintained in a long time, so filing a bug report will be a waste of time. Support for this device is currently going to be dropped with Android 5.0, and if it receives 4.4 bugfixes, that'll have to come from a new maintainer as none of the former maintainers have time/motivation for the Exynos 4210 devices these days.
Some of the issues you describe with Apollo aren't Apollo issues, but the result of a very deep-down core bug that has a side effect of screwing up storage access. This bug has been known for nearly a year (there's a big thread disucssing it somewhere around here...) and still no one has found a fix for the root cause. In fact, it's one of the #1 reasons the device is getting dropped for L. (It will absolutely not receive nightlies unless someone finds and corrects the root cause.)
Hey,
Thank you for your response. :good:
I reported the Bug on jira and there is a workaround for the Dialer Bug: Setting The Animator Scale higher than 0.
The Drivers are the problem right?
pfxandroid said:
Hey,
Thank you for your response. :good:
I reported the Bug on jira and there is a workaround for the Dialer Bug: Setting The Animator Scale higher than 0.
The Drivers are the problem right?
Click to expand...
Click to collapse
Well, there are three things you listed:
1) Dialer stuff - probably some sort of odd HDPI issue and/or graphics subsystem stuff. The Exynos4 graphics subsystem is why many developers don't want to ever touch the platform again.
2) Zoom in video - What resolution was Google Camera? Zoom has NEVER been available for 1080p resolutions on the Exynos 4210 family, not even stock firmware will zoom in 1080p
3) The storage issues are a symptom of a deep-down kernel bug that no one has found the root cause of. This is the #1 reason the device is getting dropped for 5.0 - there is no chance even if a new maintainer steps up that nightlies will resume until someone tracks down the root cause of this one. http://forum.xda-developers.com/showthread.php?t=2612329 has more discussion (warning: It's long...)
Building AOSP roms using Sony's github source is usually a pleasure in that most things just work. Modem files are not included by default as they have to be extracted from each device type, but can be found on "the internet" without much issue.
When building recent AOSP systems from Sony repos (6.0.1, 7.0 and 7.1) on Rhine and Shinano platforms using said modem files, one however encounters a wakelock problem with a telephony component. When checking in more detail, it looks like ProxyController is causing a problem. Upon further inspection, people with more skills than me have concluded that our RIL responds incorrectly to a "RIL_REQUEST_GET_RADIO_CAPABILITY" request.
Suggested solutions include changing (hacking? ) the base telephony framework and adding some special case overlay for us (e.g. https://github.com/SonyLOS/android_device_sony_rhine-common/pull/1)
Armed with this knowledge (and some qualcomm proprietary sources found on "the internet"), one can instead choose to hack the offending binary blobs. Turns out that disabling a RIL feature check in the qcril_qmi_nas_get_radio_capability function fixes our issue! This corresponds to flipping one bit in the two blobs. I am only in possession of a single Rhine device (amami), but since the same problem is present using the identical blobs on Shinano as well, I would guess that flipping that bit fixes the issue for those devices too.
I have attached the (slightly) modified blobs here and would appreciate if someone with a Shinano device could confirm that it fixes the issue for them as well!
Update: New binaries from blob drop 10 modified accordingly and attached.
ergoen said:
Building AOSP roms using Sony's github source is usually a pleasure in that most things just work. Modem files are not included by default as they have to be extracted from each device type, but can be found on "the internet" without much issue.
When building recent AOSP systems from Sony repos (6.0.1, 7.0 and 7.1) on Rhine and Shinano platforms using said modem files, one however encounters a wakelock problem with a telephony component. When checking in more detail, it looks like ProxyController is causing a problem. Upon further inspection, people with more skills than me have concluded that our RIL responds incorrectly to a "RIL_REQUEST_GET_RADIO_CAPABILITY" request.
Suggested solutions include changing (hacking? ) the base telephony framework and adding some special case overlay for us (e.g. https://github.com/SonyLOS/android_device_sony_rhine-common/pull/1)
Armed with this knowledge (and some qualcomm proprietary sources found on "the internet"), one can instead choose to hack the offending binary blobs. Turns out that disabling a RIL feature check in the qcril_qmi_nas_get_radio_capability function fixes our issue! This corresponds to flipping one bit in the two blobs. I am only in possession of a single Rhine device (amami), but since the same problem is present using the identical blobs on Shinano as well, I would guess that flipping that bit fixes the issue for those devices too.
I have attached the (slightly) modified blobs here and would appreciate if someone with a Shinano device could confirm that it fixes the issue for them as well!
Click to expand...
Click to collapse
Don't really know anything about this stuff, but I'm wondering if what you're working on might potentially be used to help out our out dated camera blobs, (Z1c Rhine)...
levone1 said:
Don't really know anything about this stuff, but I'm wondering if what you're working on might potentially be used to help out our out dated camera blobs, (Z1c Rhine)...
Click to expand...
Click to collapse
That is unfortunately much more difficult, for two reasons: The sony binaries differ alot from the (rather old) leaked qualcomm sources, so it is difficult to understand what is going on and we don't actually know what the problem is, just the symptoms.
ergoen said:
Building AOSP roms using Sony's github source is usually a pleasure in that most things just work. Modem files are not included by default as they have to be extracted from each device type, but can be found on "the internet" without much issue.
When building recent AOSP systems from Sony repos (6.0.1, 7.0 and 7.1) on Rhine and Shinano platforms using said modem files, one however encounters a wakelock problem with a telephony component. When checking in more detail, it looks like ProxyController is causing a problem. Upon further inspection, people with more skills than me have concluded that our RIL responds incorrectly to a "RIL_REQUEST_GET_RADIO_CAPABILITY" request.
Suggested solutions include changing (hacking? ) the base telephony framework and adding some special case overlay for us (e.g. https://github.com/SonyLOS/android_device_sony_rhine-common/pull/1)
Armed with this knowledge (and some qualcomm proprietary sources found on "the internet"), one can instead choose to hack the offending binary blobs. Turns out that disabling a RIL feature check in the qcril_qmi_nas_get_radio_capability function fixes our issue! This corresponds to flipping one bit in the two blobs. I am only in possession of a single Rhine device (amami), but since the same problem is present using the identical blobs on Shinano as well, I would guess that flipping that bit fixes the issue for those devices too.
I have attached the (slightly) modified blobs here and would appreciate if someone with a Shinano device could confirm that it fixes the issue for them as well!
Update: New binaries from blob drop 10 modified accordingly and attached.
Click to expand...
Click to collapse
Hi I know your post is pretty old now but we have a issue that seems to be the same as this one.
Our device is the Sony L1 which has a MediaTek soc. https://github.com/PineDevelopment
Your link to github.com/SonyLOS/android_device_sony_rhine-common/pull/1 is dead so wondered if you happen to have a record of the fix or could offer some help or insight into this issue and why it seems to affect Sony devices.
Thanks :fingers-crossed:
.