- June 25, 2013 at 12:11 pm #31312
I have discovered an issue with Android on a Galaxy Nexus (maguro) that appears to be related to be related to the graphics drivers, my main problem arose when using a modified AOSP ROM but the same issue can be reproduced using the stock image. The issue is related to creating secondary displays, which are a new feature in Android 4.2. I am getting many (i.e. 600 lines per second) errors like the following out of logcat:
06-14 11:09:37.273 128 150 E IMGSRV : :0: gralloc_module_map: Cannot map buffer ID=222 before register (0x0)
06-14 11:09:37.273 128 150 E IMGSRV : :0: MapBufferObtainParams: Mapping buffer failed
06-14 11:09:37.273 128 150 E IMGSRV : :0: WSEGL_GetDrawableParameters: Failed to obtain buffer parameters
06-14 11:09:37.273 128 150 E IMGSRV : :0: KEGLRecreateDrawable: Couldn’t create a drawable
06-14 11:09:37.273 128 150 E IMGSRV : :0: KEGLGetDrawableParameters: Can’t recreate drawable
06-14 11:09:37.273 128 150 E IMGSRV : :0: GLESMakeCurrentGC: Invalid drawable – what do we do?
The issue can be reproduced as follows:
1) Flash your Galaxy Nexus with factory image yakju JDQ39
2) Turn on developer mode
3a) Repeatedly change the ‘Simulate secondary displays’ property in Developer options to add and remove OverlayDisplayDevices
3b) Meanwhile, watch the overlay image, which will eventually freeze, and the logcat will produce the above errors
Has anyone seen anything like this before? Any possibility of a fix?
I have asked this question on the android-platform group, but no-one was able to help me. Thanks,
JoelJune 25, 2013 at 2:05 pm #37499
I’ve been able to reproduce the logcat output on a Galaxy Nexus with build JDQ39. I’ve switched the overlay mode many times, but I’m not experiencing a freeze. Is the freeze 100% reproducable for you?
JoeJune 25, 2013 at 3:19 pm #37500
Thanks for looking into it.
In my experience those logcat errors are always accompanied by the overlay display freezing. Note that it’s only the overlay that freezes, not the main display. Hence it’s not that obvious when you’re just viewing the developer options menu. I imagine you’ve noticed that it can recover when you remove the overlay and create a new one.
JoelJune 25, 2013 at 4:12 pm #37501
It’s quite slow to update as I swipe around the application launcher. I still can’t see a freeze though.
I’m using the “1280×720 tvdpi and 1920×1080 xhdpi” option while scrolling around.
Are you only seeing the problem with one of these overlay modes? Are you only seeing the issue when the overlay is used and a particular application has focus?
JoeJune 25, 2013 at 5:06 pm #37502
I’ve just been staying on the Developer Options menu and changing the Simulate Secondary Displays option pretty much randomly until the issue arises. Usually I do this test with no other apps started.
JoelJuly 2, 2013 at 3:29 pm #37503
I’ll try a few more times. Without being able to reliably reproduce the issue though, it will be difficult to progress any further.
Have you identified this problem by chance, or is it a blocking issue for a project you’re working on?
JoeJuly 2, 2013 at 4:16 pm #37504
It’s blocking a project I’m working on. My code is working very well on Nexus 4 (mako), and this arose when attempting to build the same AOSP source (with the different ‘vendor’ files as usual) for Galaxy Nexus. It was only after encountering issues from my AOSP image that I investigated further and discovered that the errors reported above could be produced using the stock ROM also. At the moment it’s not clear how I can even work around the issue since my code can’t tell the difference between this issue and when there’s nothing changing on the screen.
I should think I could give you an AOSP patch which reproduced the issue reliably (just by adding and removing secondary displays automatically) if I knew the problem would definitely be investigated further?
JoelJuly 3, 2013 at 2:21 pm #37505
In your custom build, are you only seeing the issue when you use the ‘Simulate secondary displays’ developer option?
Operating System issues like this are handled by our graphics driver team. This team only provide support to PowerVR Graphics customers who licence our graphics driver package.
The team I’m part of (PowerVR Graphics Developer Technology) provide free support for application level issues. I’ll try to help you as much as I can, but I’m not sure how much more I’ll be able to do 🙁
JoeJuly 4, 2013 at 9:30 am #37506
In my custom build, I am seeing the issue when using a new type of secondary display that I am developing. My changes only affect the pure AOSP code rather than anything device specific, and work reliably on Nexus 4. However I will soon be distributing my code to various device manufacturers among our customers, some of whom will probably be using PowerVR GPUs, and I wanted to have a fix for them if they encountered this issue. Perhaps newer GPU models will not have this issue, in which case it’s not a major problem, but if our customers do see similar issues then I’ll be sure to point them to your graphics driver team!
Please let me know if the graphics driver team do look into it – since it’s an issue reproducible with the stock AOSP ROM for a device that remains a major development device, maybe they’ll consider it worth investigating even without Samsung raising it as an issue themselves.