We need these pixel formats for exynos 4

Revert "get rid of HAL pixelformats 5551 and 4444"

This reverts commit c2414bb0989763641ca57cf72c11ef6d86565a23.

Change-Id: I84ab07cf40e0aab226ba3a144f82b62320bf7de3
exynos4: ui: define USAGE_HW_FIMC1 to support gralloc

Source:
http://git.insignal.co.kr/samsung/exynos/android/platform/frameworks/native/commit/?h=exynos-jb&id=5179fef67cadaa10d72cfe6764629565bc9a1e4e

Change-Id: Id194446eb332869f677dfb7e94c73aa3f52ee4b0
GraphicBuffer: exynos4: set FIMC1 usage bit on samsung specific formats

Change-Id: Ia8cde7e594f8be464ef15eaae453872ee5aa2768
libui: exynos4: apply FIMC usage flag on format HAL_PIXEL_FORMAT_YCbCr_420_SP_TILED

Change-Id: I8a98e593cb60d0843e83a5e431142410e26d82e7
exynos4: getphys implementation on buffermanager for samsung omx

Change-Id: Iee665f56aaf601479d796703db983ca5fce9c5c3
ui: exynos4: getphys is common

Change-Id: I1dc9c2ced0700072e7c30c8435676873b10c7026
Revert "Revert "Compatibility work around for bad graphics driver dependency.""

This reverts commit 38b657265ccc5ae45bd7860a68b0d9373b47a2f3.

Change-Id: If350d73839f1ed5e01af4299d44837e619d14d66
Rework BOARD_EGL_NEEDS_LEGACY_FB implementation

The problem with the window format boils down to a circular
dependency that makes service startup hang, so skip a round of
queues-to-window-composer to avoid it but keep using regular
Surface objects as windows, instead of replacing them with
native windows.

Change-Id: I6fed0fe04928df370c298c68ac1eb6d5b5cfb214
DisplayDevice: Backwards compatibility with old EGL

From 4.1 to 4.2, the display subsystem was reworked to
use SurfaceTextureClient/BufferQueue instead of
FramebufferNativeWindow for the framebuffer itself.

Unfortunately, some legacy EGL libraries make assumptions
that any framebuffer device will be FramebufferNativeWindow.

These EGL libraries will fail when used in 4.2 as if the
framebuffer is not FramebufferNativeWindow, they will
try to dequeue more than one buffer at a time, which
will cause a hang of the graphics subsystem.

This allows use of FramebufferNativeWindow to keep
legacy EGL implementations happy.  Confirmed EGL
implementations that need this include but are
not limited to:

Set BOARD_EGL_NEEDS_LEGACY_FB to use

Tegra2/3 ICS EGL
Mali400 ICS EGL (Allwinner A10)
Mali400 Jellybean (4.1) EGL (Samsung Exynos4)

Original implementation by OndraOrg of XDA:
http://forum.xda-developers.com/showpost.php?p=34469675&postcount=19

Change-Id: I74005cf6753b3c9bfb4c1e32fb641f5167787917
hax: Split the exynos4/tegra legacy code paths

They hang up at different places, and require different fixes.
Tested on t3 and e4

Change-Id: I46257a7e9e6b6e093a5cb92eaaaef4bdd0435a12
exynos4: getphys implementation on buffermanager for samsung omx

Change-Id: Iee665f56aaf601479d796703db983ca5fce9c5c3

Conflicts:
	include/media/hardware/HardwareAPI.h
	include/ui/GraphicBufferMapper.h
	libs/ui/GraphicBufferMapper.cpp
exynos4: ui: define USAGE_HW_FIMC1 to support gralloc

Source:
http://git.insignal.co.kr/samsung/exynos/android/platform/frameworks/native/commit/?h=exynos-jb&id=5179fef67cadaa10d72cfe6764629565bc9a1e4e

Change-Id: Id194446eb332869f677dfb7e94c73aa3f52ee4b0
libgui: Add ICS/MR0-compatible client::createSurface constructors

Change-Id: Ia5b04d93320c65ac32a92cbd93daa6a64e6cee1c
installd: Delete cache properly for devices using datadata partition

The java side already checks /data/data for free space but installd
still checks /data causing it to never reap the cache (because it
thinks that enough free space is available.)

Change-Id: I736af6ff7ea0c8ae07900168f6b8ac2f7a4dbe0b
surfaceflinger: Reimplement hwrotation

Change-Id: Ia26bb36b5b6de132af49c272c4472ad2703afbda
ui: exynos4: getphys is common

Change-Id: I1dc9c2ced0700072e7c30c8435676873b10c7026

Conflicts:
	include/ui/GraphicBufferMapper.h
	libs/ui/GraphicBufferMapper.cpp
GraphicBuffer: exynos4: set FIMC1 usage bit on samsung specific formats

Change-Id: Ia8cde7e594f8be464ef15eaae453872ee5aa2768

Conflicts:
	libs/ui/GraphicBufferAllocator.cpp
libui: exynos4: apply FIMC usage flag on format HAL_PIXEL_FORMAT_YCbCr_420_SP_TILED

Change-Id: I8a98e593cb60d0843e83a5e431142410e26d82e7
Sensor: Add RotationVectorSensor2

(ported from 4.1)

Some ICS apps (namely, Google Maps) expects a rotation vector to be
available. Newer devices, this is provided by either Android's
sensor fusion (requires Gyro) or by hardware sensor fusion (MPL).

Older devices will lack this virtual sensor and compass in Google
Maps will not work. To fix this, we can provide our own rotation
vector sensor by converting the values from the orientation sensor.
(They are basically the same information in different formats.)

Thanks to Unhelpful for the help with related math.

Change-Id: I39489b3a5ce7c7d890768614357f32cc491bd6d9

Conflicts:
	services/sensorservice/SensorService.cpp
surfaceflinger: odd hw rotation (90/270) patch for swapping width/height

This patch works in addition to the following commit
re-implementing ro.sf.hwrotation:
https://github.com/CyanogenMod/android_frameworks_native/commit/7d283431efffc4402cb1a6cacf5da64729c883bb

When using values of 90 and 270 for ro.sf.hwrotation the
LCD width and height also need to be swapped to display properly.

NOTE: This patch does not fix the initial startup of bootanimation

Change-Id: Iab9de66348967a378dd73a41bc96d632f750386c
Signed-off-by: Hashcode <hashcode0f@gmail.com>