Merge commit '8395b4625b96f2133e2e4f595fdc69fbe222e4fc' into gingerbread-plus-aosp
* commit '8395b4625b96f2133e2e4f595fdc69fbe222e4fc':
fix [2931513] Add support for setting the orientation of an ANativeWindow
This change makes the camera HAL interface take an ANativeWindow interface from
which all the camera preview buffers will be allocated. The framework code
running in application processes now passes a Surface object rather than an
ISurface to the camera server via Binder when setting the preview surface. The
camera server then forwards that Surface object (which implements the
ANativeWindow interface) to the camera HAL, which uses it to communicate with
SurfaceFlinger to allocate the camera preview buffers.
Change-Id: Ie438f721559cd7de5e4f848a26d96360dda07b5f
commit 35cc68814a9537c31fde146e171e7b0bbdfe211e
Author: Andreas Huber <andih@google.com>
Date: Mon Aug 16 08:48:42 2010 -0700
Only enable support for yuv to yuv conversion on passion, where it's available, use the slower yuv->rgb565 path everywhere else.
commit d8ac5a8814103e60d11d2acf61997fc31a1dc58d
Author: Andreas Huber <andih@google.com>
Date: Fri Aug 13 13:56:44 2010 -0700
The software renderer takes over all rendering, converting from yuv to yuv if possible and rgb565 otherwise.
commit 684972074b74318bdcb826ed9b5b0864d2d2e273
Author: Andreas Huber <andih@google.com>
Date: Fri Aug 13 09:34:35 2010 -0700
A first shot at supporting the new rendering APIs.
Change-Id: Iea9b32856da46950501f1a700f616b5feac710fd
Merge commit '26bcc7b44238ea54105ef5a6020fa5c37bb33f03' into gingerbread-plus-aosp
* commit '26bcc7b44238ea54105ef5a6020fa5c37bb33f03':
revert hwcomposer HAL changes. DO NOT MERGE.
Merge commit '6a73368be44f45a80cc4b65dc57b9ff529cb2d89' into gingerbread-plus-aosp
* commit '6a73368be44f45a80cc4b65dc57b9ff529cb2d89':
fix a typo that prevented glTexImage2D codepath to work
Merge commit 'b7d1be01ae44428b947823fc48c1c126dcaa9732' into gingerbread-plus-aosp
* commit 'b7d1be01ae44428b947823fc48c1c126dcaa9732':
Fix a couple issues with the new hwcomposer HAL
- we now clear the framebuffer upon request from the HAL
- the HAL list size could get out of sync with reality
- there was also an issue where sometime we could run past the list
Change-Id: Ic3a34314aed24181f2d8cc787096af83c046ef27
Merge commit '90dc48b17f673b7e334e3254ea633450f994226c' into gingerbread-plus-aosp
* commit '90dc48b17f673b7e334e3254ea633450f994226c':
call into hwcomposer HAL when present
Merge commit '24d7050ca605804efd5fde03f0d0d8d1d052c247' into gingerbread-plus-aosp
* commit '24d7050ca605804efd5fde03f0d0d8d1d052c247':
don't handle the transparent region of a layer in draw()
Merge commit '8e7515d9c938f5addd08d97bccfccfa976e76c11' into gingerbread-plus-aosp
* commit '8e7515d9c938f5addd08d97bccfccfa976e76c11':
get rid of our LayerVector implementation
Merge commit '025822a03a09337ec382e708c5a798fe805109ed' into gingerbread-plus-aosp
* commit '025822a03a09337ec382e708c5a798fe805109ed':
keep a list of visible sorted surfaces
this is already taken into consideration in computeVisibleRegion
and therefore not needed at draw time.
Change-Id: I3fc7336d22f1147dfcd3a20fd71bf79b946d971f
Merge commit 'bc881e66d15181494fdd5d0ece83e20ef325453b' into gingerbread-plus-aosp
* commit 'bc881e66d15181494fdd5d0ece83e20ef325453b':
frameworks/base: Swap width and height of temporary buffer only with
orientation change
Current code swaps the width and height by assuming that aspect
ratio of the buffer width and height will be same as that of the
layout clip width and height. That is not always true.
Change the check to orientation change.
Change-Id: Ie387f3a7369025427484e4173cbde7a08df2b9d7
this situation happened when the last buffer needed to be resized
(or allocated, the first time). the assumption was that the buffer
was in use by SF itself as the current buffer (obviously, this
assumption made no sense when the buffer had never been allocated, btw).
the system would wait until some other buffer became the "front" buffer.
we fix this problem by entirely removing the requirement that the
buffer being resized cannot be the front buffer. instead, we just
allocate a new buffer and replace the front buffer by the new one.
the downside is that this uses more memory (an extra buffer) for a
brief amount of time while the old buffer is being reallocated and
before it has actually been replaced.
Change-Id: I022e4621209474ceb1c671b23deb4188eaaa7285
moved surfaceflinger, audioflinger, cameraservice
all native services should now reside in this location.
Change-Id: Icd7336f7289db35df9c8c1857a5122bb8a6f1c86
moved surfaceflinger, audioflinger, cameraservice
all native services should now reside in this location.
Change-Id: Iee42b83dd2a94c3bf5107ab0895fe2dfcd5337a8
