This will allow eglGetDisplay(int) to work on both 32-bit
and 64-bit systems when EGL_DEFAULT_DISPLAY is passed as
a parameter.
Change-Id: I0d7e9ca5410b0dd893eacc02aac40956908e4f25
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
EGL classes in frameworks/base have to be updated to support
64-bit platforms. Key changes in the EGL classes include
[x] EGLObjectHandle class - EGLObjectHandle class has two public
methods (constructor and getHandle) that assume handles are
32-bit. They have not been changed. Instead, two new hidden
methods (EGLObjectHandle(long) and getNativeHandle) have been
added.
[x] EG14 class - Two public methods eglGetDisplay and
eglCreatePbufferFromClientBuffer assume that handles are 32-bit.
They have been changed to throw unsupported operation exception
on non 32-bit machines. Two new methods eglGetDisplay(long)
and eglCreatePbufferFromClientBuffer(...long buffer..) have
been added to support 64-bit handles.
To allow the above changes in frameworks/base EGL classes,
corresponding code generation mechanism in frameworks/native has
been updated.
Change-Id: I5d0a62e10c20ccf05f610d6608b8dfb6414b5116
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Patch from Takeshi Aimi with commit-id f9337377 changed
core/jni/android_opengl_EGL14.cpp in the frameworks/base.
However the corresponding code snippet in frameworks/
native was not updated. This patch addresses the issue.
Change-Id: I40bcc43d36d7ab4e0db4a73556a4f7480c7431c1
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
this means they only have access to the consumer end of
the interface. we had a lot of code that assumed consumers
where holding a BufferQueue (i.e.: both ends), so most of
this change is untangling in fix that
Bug: 9265647
Change-Id: Ic2e2596ee14c7535f51bf26d9a897a0fc036d22c
Initially populated with EGL_ANDROID_presentation_time (moved from the
EGL14 class) and the ES-relevant parts of EGL_KHR_create_context.
Bug: 8678160
Change-Id: Ifed2ee3da264ca701ae1f4b309a0758f7fcc3acc
- it looks like UserId has been renamed to UserHandle in the
framework.
- also for some reason I don't understand glgen didn't seem
to be up to date with respect to the generated bindings in the tree.
It's like the bindings were generated with a more recent version of
glgen (maybe it was never checked in). So we fix that here.
Change-Id: Ie49522ebf67fcab9213246b4d93500e37a3cbc05
The C++ class names don't match what the classes do, so rename
ISurfaceTexture to IGraphicBufferProducer, and SurfaceTexture to
GLConsumer.
Bug 7736700
Change-Id: Ia03e468888025b5cae3c0ee1995434515dbea387
