Merge commit '425324e97bba75cd69bb6c81de6248529540e6fe'
* commit '425324e97bba75cd69bb6c81de6248529540e6fe':
Fix failure to open AVRCP input device due to EPERM.
Sleep for 100us and try to open the input device again if it fails, with a
maximum of 10 attempts.
We need the retry logic because setting permissions on a new input device is
racy. The init process watches for new input device (via uevent) and sets the
permission on them in devices.c:make_device(). However at the same time
EventHub.cpp watches for new input devices from the system_server process, and
immediately tries to open them. I can't see a simple way to avoid this race
condition.
As best as I can tell this race condition has always exisited.
There must have been some timing change that happened recently that causes us
to hit this race condition much more often. See repro notes in referenced bug.
Bug: 2375632
Surface::validate() could sometimes dereference a null pointer before checking it wasn't null.
This will prevent the application to crash when given bad parameters or used incorrectly.
However, the bug above probably has another cause.
we lost the concept of vertical stride when moving video playback to EGLImage.
Here we bring it back in a somewhat hacky-way that will work only for the
softgl/mdp backend.
Use EGLImageKHR instead of copybit directly.
We now have the basis to use streaming YUV textures (well, in fact
we already are). When/if we use the GPU instead of the MDP we'll
need to make sure it supports the appropriate YUV format.
Also make sure we compile if EGL_ANDROID_image_native_buffer is not supported
when running out of memory, a null handle is returned but the error code may not be set.
In that case we need to return NO_MEMORY instead of NO_ERROR, so that the calling code
won't try to dereference the null pointer.
This also fixes [2152536] ANR in browser
When SF is enqueuing buffers faster than SF dequeues them.
The update flag in SF is not counted and under some situations SF will only
dequeue the first buffer. The state at this point is not technically
corrupted, it's valid, but just delayed by one buffer.
In the case of the Browser ANR, because the last enqueued buffer was delayed
the resizing of the current buffer couldn't happen.
The system would always fall back onto its feet if anything -else- in
tried to draw, because the "late" buffer would be picked up then.
A window is created and the browser is about to render into it the
very first time, at that point it does an IPC to SF to request a new
buffer. Meanwhile, the window manager removes that window from the
list and the shared memory block it uses is marked as invalid.
However, at that point, another window is created and is given the
same index (that just go freed), but a different identity and resets
the "invalid" bit in the shared block. When we go back to the buffer
allocation code, we're stuck because the surface we're allocating for
is gone and we don't detect it's invalid because the invalid bit has
been reset.
It is not sufficient to check for the invalid bit, I should
also check that identities match.
When EGLImage extension is not available, SurfaceFlinger will fallback to using
glTexImage2D and glTexSubImage2D instead, which requires 50% more memory and an
extra copy. However this code path has never been exercised and had some bugs
which this patch fix.
Mainly the scale factor wasn't computed right when falling back on glDrawElements.
We also fallback to this mode of operation if a buffer doesn't have the adequate
usage bits for EGLImage usage.
This changes only code that is currently not executed. Some refactoring was needed to
keep the change clean. This doesn't change anything functionaly.
The ANR is caused by SurfaceFlinger waiting for buffers of a removed surface to become availlable.
When it is removed from the current list, a Surface is marked as NO_INIT, which causes SF to return
immediately in the above case. For some reason, the surface here wasn't marked as NO_INIT.
This change makes the code more robust by always (irregadless or errors) setting the NO_INIT status
in all code paths where a surface is removed from the list.
Additionaly added more information in the logs, should this happen again.
a new method, compostionComplete() is added to the framebuffer hal, it is used by surfaceflinger to signal the driver that the composition is complete, BEFORE it releases its client. This gives a chance to the driver to
Take 2. We needed to check that the usage flags are "good enough" as opposed to "the same".
This reverts commit 8f17a762fe9e9f31e4e86cb60ff2bfb6b10fdee6.
Appears to have been broken by:
commit 9779b221e999583ff89e0dfc40e56398737adbb3
Author: Mathias Agopian <mathias@google.com>
Date: Mon Sep 7 16:32:45 2009 -0700
fix [2068105] implement queueBuffer/lockBuffer/dequeueBuffer properly
For some reason we don't like to have "-lpthread" globally -- it's a no-op
on device builds, but required for many host tools and all sim binaries --
so adding the use of pthread calls requires adding the library explicitly.
Rewrote SurfaceFlinger's buffer management from the ground-up.
The design now support an arbitrary number of buffers per surface, however the current implementation is limited to four. Currently only 2 buffers are used in practice.
The main new feature is to be able to dequeue all buffers at once (very important when there are only two).
A client can dequeue all buffers until there are none available, it can lock all buffers except the last one that is used for composition. The client will block then, until a new buffer is enqueued.
The current implementation requires that buffers are locked in the same order they are dequeued and enqueued in the same order they are locked. Only one buffer can be locked at a time.
eg. Allowed sequence: DQ, DQ, LOCK, Q, LOCK, Q
eg. Forbidden sequence: DQ, DQ, LOCK, LOCK, Q, Q
This addresses a few parts of the bug:
- There was a small issue in the window manager where we could show a window
too early before the transition animation starts, which was introduced
by the recent wallpaper work. This was the cause of the flicker when
starting the dialer for the first time.
- There was a much larger problem that has existing forever where moving
an application token to the front or back was not synchronized with the
application animation transaction. This was the cause of the flicker
when hanging up (now that the in-call screen moves to the back instead
of closing and we always have a wallpaper visible). The approach to
solving this is to have the window manager go ahead and move the app
tokens (it must in order to keep in sync with the activity manager), but
to delay the actual window movement: perform the movement to front when
the animation starts, and to back when it ends. Actually, when the
animation ends, we just go and completely rebuild the window list to
ensure it is correct, because there can be ways people can add windows
while in this intermediate state where they could end up at the wrong
place once we do the delayed movement to the front or back. And it is
simply reasuring to know that every time we finish a full app transition,
we re-evaluate the world and put everything in its proper place.
Also included in this change are a few little tweaks to the input system,
to perform better logging, and completely ignore input devices that do not
have any of our input classes. There is also a little cleanup of evaluating
configuration changes to not do more work than needed when an input
devices appears or disappears, and to only log a config change message when
the config is truly changing.
Change-Id: Ifb2db77f8867435121722a6abeb946ec7c3ea9d3
what happened is that the efective pixel format is calculated by SF but Surface nevew had access to it directly.
in particular this caused query(FORMAT) to return the requested format instead of the effective format.
This change makes SurfaceHolder.setType(GPU) obsolete (it's now ignored).
Added an API to android_native_window_t to allow extending the functionality without ever breaking binary compatibility. This is used to implement the new set_usage() API. This API needs to be called by software renderers because the default is to use usage flags suitable for h/w.
* changes:
update most gl tests to use EGLUtils
added two EGL helpers for selecting a config matching a certain pixelformat or native window type
added NATIVE_WINDOW_FORMAT attribute to android_native_window_t
The major things going on here:
- The MotionEvent API is now extended to included "pointer ID" information, for
applications to keep track of individual fingers as they move up and down.
PointerLocation has been updated to take advantage of this.
- The input system now has logic to generate MotionEvents with the new ID
information, synthesizing an identifier as new points are down and trying to
keep pointer ids consistent across events by looking at the distance between
the last and next set of pointers.
- We now support the new multitouch driver protocol, and will use that instead
of the old one if it is available. We do NOT use any finger id information
coming from the driver, but always synthesize pointer ids in user space.
(This is simply because we don't yet have a driver reporting this information
from which to base an implementation on.)
- Increase maximum number of fingers to 10. This code has only been used
with a driver that reports up to 2, so no idea how more will actually work.
- Oh and the input system can now detect and report physical DPAD devices.
there was several issues:
- when a surface was made non-current, the last frame wasn't shown and the buffer could stay locked
- when a surface was made current the 2nd time, it would not dequeue a new buffer
now, queue/dequeue are done when the surface is made current.
for this to work, a new query() hook had to be added on android_native_window_t, it allows to retrieve some attributes of a window (currently only width and height).
This will be used to avoid unnecessarily listening to data from sensors
that function as event devices.
Signed-off-by: Mike Lockwood <lockwood@android.com>
The kernel can now publish a property describing the layout of virtual
hardware buttons on the touchscreen. These outside of the display
area (outside of the absolute x and y controller range the driver
reports), and when the user presses on them a key event will be
generated rather than a touch event.
This also includes a number of tweaks to the absolute controller
processing to make things work better on the new screens. For
example, we now reject down events outside of the display area.
Still left to be done is the ability to cancel a key down event,
so the user can slide up from the virtual keys to the touch screen
without causing a virtual key to execute.
Merge commit 'c7396025e59524e7ef639fd86fc23123939ee91c'
* commit 'c7396025e59524e7ef639fd86fc23123939ee91c':
Return CAMERA_ERROR_SERVER_DIED to camera app when camera service dies (bug 1956726)
Merge commit 'c44989d6c7bcc761fb37f54fd37aac2070ba8e5e'
* commit 'c44989d6c7bcc761fb37f54fd37aac2070ba8e5e':
move ui/Time.cpp to core/jni, since this is the only place it is used
Merge commit '3d7b8d1aa6a362292f56defbe8fb2d5653f79282'
* commit '3d7b8d1aa6a362292f56defbe8fb2d5653f79282':
Use a ref-counted callback interface for Camera.
This allows the camera service to hang onto the callback interface
until all callbacks have been processed. This prevents problems
where pending callbacks in binder worker threads are processed
after the Java camera object and its associated native resources
have been released.
Bug 1884362
- return "const" objects for overloaded operators to disallow constructs like: (a+b) = c;
- don't return references to non-static members, it's not always safe.
- Point.cpp was empty, so get rid of it
- make sure that all binder Bn classes define a ctor and dtor in their respective library.
This avoids duplication of the ctor/dtor in libraries where these objects are instantiated.
This is also cleaner, should we want these ctor/dtor to do something one day.
- same change as above for some Bp classes and various other non-binder classes
- moved the definition of CHECK_INTERFACE() in IInterface.h instead of having it everywhere.
- improved the CHECK_INTERFACE() macro so it calls a single method in Parcel, instead of inlining its code everywhere
- IBinder::getInterfaceDescriptor() now returns a "const String16&" instead of String16, which saves calls to String16 and ~String16
- implemented a cache for BpBinder::getInterfaceDescriptor(), since this does an IPC. HOWEVER, this method never seems to be called.
The cache makes BpBinder bigger, so we need to figure out if we need this method at all.
This is the second half of bug 1837832. Modifies the camera client
and camera service to use the new binder interface. Removes the
old binder interface. There will be one more part to this change
to surface the undefined callbacks to the Java layer so that
partners can implement new features without having to touch the
stack.
This is the first step in a multi-step change to move from the old
specific callbacks to a generic callback. This will allow future
flexibility in the interface without requiring binder rewrites.
Bug 1837832
- Currently the lock/unlock path is naive and is done for each drawing operation (glDrawElements and glDrawArrays). this should be improved eventually.
- factor all the lock/unlock code in SurfaceBuffer.
- fixed "showupdate" so it works even when we don't have preserving eglSwapBuffers().
- improved the situation with the dirty-region and fixed a problem that caused GL apps to not update.
- make use of LightRefBase() where needed, instead of duplicating its implementation
- add LightRefBase::getStrongCount()
- renamed EGLNativeWindowSurface.cpp to FramebufferNativeWindow.cpp
- disabled copybits test, since it clashes with the new gralloc api
- Camera/Video will be fixed later when we rework the overlay apis
Add a factory method that creates a Camera object from a remote client
Next:
The changes in authordriver.cpp and android_camera_input.cpp will come.
and the constructor for Camera object will be removed.
The WindowManager side of Surface.java holds a SurfaceControl, while the client-side holds a Surface. When the client is in the system process, Surface.java holds both (which is a problem we'll try to fix later).
SurfaceControl is used for controling the geometry of the surface (for the WM), while Surface is used to access the buffers (for SF's clients).
SurfaceFlingerClient now uses the SurfaceID instead of Surface*.
Currently Surface still has the SurfaceControl API and is implemented by calling into SurfaceControl.
To deal with Java's lack of destructors and delayed garbage collection, we used to duplicate Surface.cpp objects in some case; this caused some issues because Surface is supposed to be reference-counted and unique.
