libhwcomposer: Log and dump app layers of screen frames

Log a frame-by-frame succession of HWComposer layers' data and write
their buffers, if any, into raw or png files based on system property
values.

Change-Id: Icceccf5fff5ab4d78dbc6c28c11210b8837ddfd9
display: Clean up binder interface

The current binder implementation is inflexible when it comes to
adding new input/output parameters. It also needs a lot of
boilerplate code written when adding a simple enable/disable type
command.

Instead, let clients specify the parcels they want to pass and
unparcel them at the end points only.
Please note that it is assumed that all commands coming in
need the same permission checks. If this is no longer the case,
some commands need to be split out on the receiver end in
IQService.cpp.
This change also simplifies the code end clients need to write.
They should be able to include QServiceUtils and call a single
function to set the binder up and make the call.

Change-Id: I4db66f2427ecf16d7a6264462ae85815217a16b1
qdutils: Add display config to qdutils

This API is meant for system level users that need to get/set
various display attributes that are normally not available via
the regular Android framework channels.
Initially the APIs exposed are to check HDMI status, get display
attributes and set HSIC data.
Only physically connected displays are supported for now.

Change-Id: Ia783ce2ab0c4599a54c992171e01e2f0504550dc
hwc: Calculate viewframe from layers display frame information.

Calculate view frame of  each display from the displayframe of all
the application layers.

Change-Id: I9ba4076b7b4419bd3559417fad28b4e1de6acff3
hwc: Add binder interface to get the visibleRegion

- This binder interface can be used by clients to know the
  active visible region for a display(pri/ext/virt)
- When external orientation is used, return the destFrame of
  the FrameBuffer layer, as its the viewFrame

Change-Id: I7cfd149c76c16b9a3031103c89b1932d44bcbecd
hwc: Reset layer-to-rotator map and fences on configuration failure

When a rotator or mdp configuration for a display fails, reset the
layer-to-rotator mappings for that display and reset the release
fences for the rotator objects used for that display.

Note: The rotator itself is offline and not tied to any mixer. It is
from the mappings that we deduce which rotator object was used for
layers of which display. Also we don't delete rotator objects held
for a specific display, since during stability runs, failures could
repeat each round and we end up allocating and deallocating memory
unnecessarily. The rotator objects will be deleted automatically
when not required anymore.

Change-Id: I9a67f02574be30be3b96b3575f60530cb1c89e10
hwc: Update rotator object handling in error cases

Earlier, on configuration errors, we simply drained the fences held
by current rotator objects and went to GPU comp. The rotator objects
were deleted in the subsequent rounds, if they remained unused.

If we don't use GPU comp on failure but use other strategies, then we
need to mark the rotator objects for a display for reuse, so that
other strategies can use them.

Also any failure resets on overlay or rotator need to happen from
functions that call configuration helpers rather than the  helper
themselves. Leaving cleanup to black-box helpers is not desirable.

Change-Id: I59b5b1bb774b82ee85a037e934c9d2d023db30af
display: Various cleanups, fix legacy camera heap

 * Add explicit support for camera heap, if requested
 * Bring in line with kk_2.7
 * Don't push to MM heap for NO_IOMMU for display buffers

Change-Id: I30a8280099aa82e9b3e9754a4a68ad6a81f705f7
Fix bad merge

Change-Id: Ida74be0b228106604eab8926d86f0fb71c434d84