History log of /external/drm_hwcomposer/drmdisplaycomposition.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
e64acba60e031af0b0a9617b8415008e744b4a40 22-Sep-2017 Adrian Salido <salidoa@google.com> drm_hwcomposer: reorder source layers according to zorder am: 228ca6d118 am: 4b54b81847 am: 1ad48d0662 am: 2bd0f1d90e
am: b9cdd87a8c

Change-Id: Ida63f3d63416c07facf168d7dd3168df807d4aa4
b9cdd87a8c4b30ae1c8f98c22a5a2cb92c0ec876 22-Sep-2017 Adrian Salido <salidoa@google.com> drm_hwcomposer: reorder source layers according to zorder am: 228ca6d118 am: 4b54b81847 am: 1ad48d0662
am: 2bd0f1d90e

Change-Id: I4cae74eacdb01c8b65c70e9dc0c0041f3502f648
228ca6d1182a350e68242e1837c32d258fb17fee 22-Sep-2017 Adrian Salido <salidoa@google.com> drm_hwcomposer: reorder source layers according to zorder

Precomp layers may be added to the back at different points which may
cause elements to be unsorted. Make sure that these are sorted after
provisioning planes to ensure right composition based on zorder.

Bug: 65587393
Change-Id: Ica6d12093818341eaeca6c63735c558511679f7b
Signed-off-by: Adrian Salido <salidoa@google.com>
/external/drm_hwcomposer/drmdisplaycomposition.cpp
9cc83934f92aab292f16213c1b716e8ecfcb5875 22-Aug-2017 Adrian Salido <salidoa@google.com> DO NOT MERGE: revert HWC2 changes

The changes are causing some issues with multi-window use cases.

Fixes: 64491794
Test: test gmail compose in multi-window + show taps enabled

Change-Id: I0b0a3f351ed48f81db89a71c78bf17bab8cb2acf
Signed-off-by: Adrian Salido <salidoa@google.com>
/external/drm_hwcomposer/drmdisplaycomposition.cpp
8600e347e14b42872b1c2762d51b27102ddc40f9 28-Feb-2017 Sean Paul <seanpaul@chromium.org> drm_hwcomposer: Clean up error conditions

Clean up error checking for some failure cases.

BUG=None
TEST=Tested on Qemu+drm_hwcomposer

Change-Id: I98bca1aef09060b5a023375dce564252a6073b96
Signed-off-by: Robert Foss <robert.foss@collabora.com>
/external/drm_hwcomposer/drmdisplaycomposition.cpp
aa18d918e24d63b650791fe021f41761d8a33d3b 12-May-2016 Sean Paul <seanpaul@chromium.org> drm_hwcomposer: Use Planner interface to provision planes

Use the new Planner interface to handle the layer->plane mapping.
This allows us to simplify the Plan() function by offloading the
plane provisioning to the platform specific code.

BUG=b/28117135
TEST=Tested on ryu with a variety of window layouts/workloads

Signed-off-by: Sean Paul <seanpaul@chromium.org>
Change-Id: I75a0c5d87a9096e7a83ecbc848c75fee42ee1131
/external/drm_hwcomposer/drmdisplaycomposition.cpp
4f4ef69e539c8f0c7352f12247b7551936736d04 04-May-2016 Sean Paul <seanpaul@chromium.org> drm_hwcomposer: Don't use Plan() in SquashAll

Simplify the SquashAll() function by generating the composition
without using Plan(). This allows us to specify exactly what we
want on the screen without involving the normal plane provisioning
code.

BUG=b/28117135
TEST=Tested on ryu, squashing still works

Signed-off-by: Sean Paul <seanpaul@chromium.org>
Change-Id: Ieec9c323941e2a80252b33d14563c4d218d38dfb
/external/drm_hwcomposer/drmdisplaycomposition.cpp
3960cddcd115201392efc6ada9a939e20769732d 10-May-2016 Sean Paul <seanpaul@chromium.org> drm_hwcomposer: Move SeparateLayers into a member function

Instead of passing a bunch of member data to a static function, make
SeparateLayers a member of DrmDisplayComposition. This will be simplified
further once the Planner interface is implemented.

BUG=b/28117135
TEST=Tested on ryu

Signed-off-by: Sean Paul <seanpaul@chromium.org>
Change-Id: Ia4e15aa20b6dc14b044ee1dec7b5fce514278be7
/external/drm_hwcomposer/drmdisplaycomposition.cpp
bbe39db91385424991ce86f333cc6c2ebe871a66 11-May-2016 Sean Paul <seanpaul@chromium.org> drm_hwcomposer: Move DrmCompositionPlaneType into DrmCompositionPlane

Now that DrmCompositionPlane is classified, move the type into it
as a subclass.

BUG=b/28117135
TEST=Tested on ryu

Signed-off-by: Sean Paul <seanpaul@chromium.org>
Change-Id: I774f477e75b3a2e2916c5d98931730dac46d3877
/external/drm_hwcomposer/drmdisplaycomposition.cpp
ca699be0bcc162c8748abb63cd4f7158733b1466 11-May-2016 Sean Paul <seanpaul@chromium.org> drm_hwcomposer: Use a vector for composition source_layers

Instead of a 1:1 mapping of layer:plane, use a vector to store
source layers for a composition plane. This will allow us to
represent squash compositions more easily by adding all source
layers to the vector.

This should also facilitate hardware which allows multiple fbs per plane.

BUG=b/28117135
TEST=Tested on ryu

Signed-off-by: Sean Paul <seanpaul@chromium.org>
Change-Id: I5d4bfc6e9da022eaab047f948cc874d6a8a25746
/external/drm_hwcomposer/drmdisplaycomposition.cpp
39b3784628eb4169b46e71b30c98daf83c93bb8e 11-May-2016 Sean Paul <seanpaul@chromium.org> drm_hwcomposer: Add type to DrmCompositionPlane

Instead of encoding the plane/composition type in source_layer,
move it to its own explicit type. This will allow us to expand
source_layer to include more than one layer.

BUG=b/28117135
TEST=compiles and runs on smaug

Change-Id: I19b1ed8e395347bbefb0fb6a0ab02d6ac0e5c1c1
Signed-off-by: Sean Paul <seanpaul@chromium.org>
/external/drm_hwcomposer/drmdisplaycomposition.cpp
f1d2579822fcce9bfff996d8bd95d81136459b59 10-May-2016 Sean Paul <seanpaul@chromium.org> drm_hwcomposer: Fix protected layer hole punch

The old code didn't dereference the layer index from the
bitmask which caused it to subtract layers it shouldn't
have. In order to do this right, we need to look at the
layer index corresponding to the bit in the id_set to
ensure we're excluding the correct layers.

BUG=None
TEST=Precomposition doesn't draw over dedicated layers

Change-Id: I8531e1ef3b2beb4674041145e2b38ce4b3dbe346
Signed-off-by: Sean Paul <seanpaul@chromium.org>
/external/drm_hwcomposer/drmdisplaycomposition.cpp
8a628b9d22f778fcb4dc445d677f6f028667c885 18-Apr-2016 Sean Paul <seanpaul@chromium.org> drm_hwcomposer: Don't composite over protected layers

This patch changes two things with respect to protected layers:

1- It provisions the HW plane in the correct position. ie: if
the background layer is slated for a HW plane, it will be
placed on the primary layer and the protected layer will be
placed on top of it.
2- It punches a hole through the precomposite and squash layers
such that when they are placed on top of the protected layer,
they do not obstruct it.

BUG=b/27502957
TEST=Tested on smaug with multi-window with a variety of different
layouts and visible layers

Change-Id: Ie30939f2bb750dbe3faa558ddb094b677f41f45e
Signed-off-by: Sean Paul <seanpaul@chromium.org>
/external/drm_hwcomposer/drmdisplaycomposition.cpp
04b47ea435834b4373d57dae6485986b9f0918ae 20-Nov-2015 Sean Paul <seanpaul@chromium.org> drm_hwcomposer: Allow for multiple transforms at once

Because sometimes one just ain't enough, allow more than
one transform at a time.

Bug: chrome-os-partner:46710
Test: Tested with the CTS Verifier "Camera Orientation" test

Change-Id: Ie5f9bbbc7c89964feafc78150e18512861c85b69
Signed-off-by: Sean Paul <seanpaul@chromium.org>
/external/drm_hwcomposer/drmdisplaycomposition.cpp
cb1cfc866b47c480a9fa84f6edcc5239ac99d277 14-Nov-2015 Zach Reizner <zachr@google.com> drm_hwcomposer: avoid creating release fences for invalid OutputFd

This change also adds a check for OutputFd to see if it is valid.

Change-Id: If992d523c707cc5e6e660de721938a26f27477d8
/external/drm_hwcomposer/drmdisplaycomposition.cpp
db81fce67419d82d828eebec25e57284e90dd93a 28-Oct-2015 Zach Reizner <zachr@google.com> drm_hwcomposer: always put protected layers on hardware planes

Protected layers will not work inside of the GLWorker, so we are forced to put
them into planes directly.

Because we can now receive display contents which can never be properly
composited (e.g. 4 protected layers on hardware with only 3 planes), some
compromises had to be made for the composition planning algorithm. First all
protected layers are given a plane. Then the remaining planes are used by the
remaining layers, pre-composite buffer, and squash buffer. In the case where
there are too few planes for both a pre-composite buffer and squash buffer,
everything gets pushed into the pre-composite buffer and the squash buffer
will not be composited onto the screen. Another major limitation is that any
unprotected layers appearing behind a protected layer will actually appear on
top of that protected layer.

BUG=chrome-os-partner:43674
TEST=run protected content with lots of other layers

Change-Id: I94620d93f68ca14dc1966422dc89035ab84e3ff4
/external/drm_hwcomposer/drmdisplaycomposition.cpp
aa2f4a5eec7f4117b9487a415739634007254822 02-Nov-2015 Haixia Shi <hshi@chromium.org> drm_hwcomposer: fix spelling of "separate".

It is spelled "separate", not "seperate".

Change-Id: Id92d12aba42989a8a72e4596d425b2a9eea4e5ec
/external/drm_hwcomposer/drmdisplaycomposition.cpp
5757e82631820372382d3369c54cc3a1ffef812f 17-Oct-2015 Zach Reizner <zachr@google.com> drm_hwcomposer: implement squashing

Change-Id: Ifd4feaa0de303ddfd519d4415ab31d2a72f26022
/external/drm_hwcomposer/drmdisplaycomposition.cpp
fd6dc339551e5aa041daec7abffc3ff8eaeca138 14-Oct-2015 Zach Reizner <zachr@google.com> drm_hwcomposer: reimplement Dump for DrmDisplayCompositor

Also fixes hwc_dump sometimes failing to null terminate its output buffer.

TEST=dumpsys SurfaceFlinger

Change-Id: Ibf93cfd496a07a9375d78a8b239c2c7876aff986
/external/drm_hwcomposer/drmdisplaycomposition.cpp
92f8e6399c0829c6ba6db77d5ea1bbd22f510bb1 13-Oct-2015 Zach Reizner <zachr@google.com> drm_hwcomposer: ground work for squashing

This patch rearranges things to make squashing possible.
The high-level changes:
- A new Plan phase that happens in QueueComposition. This is where the
overlay allocation is moved to. It's also the only safe time that
the composition can try to plan squashing. This is because squashing
depends on the exact ordering of compositions.
- GLWorker now renders regions rather than layers. A region in this case is
a clipping rectange and set of layers that are to be rendered in that
rectangle. This is always what GLWorker did in the end, but now the work
to seperate layers into regions is done externally. This was changed
because the output of SquashState is a list of stable regions that need to
be put through GLWorker

The Plan methods of the Compositions are responsible for updating per-display
SquashState and for allocation regions/layers to squashing, pre-composition, or
hardware overlay. Because of the drastic changes to how composition planning
works, it was necessary to bundle it with the GLWorker change.

This change also includes plenty of other refactorings that were deemed to
be too painful to try and seperate into another change.

Change-Id: Ie7bfe077067e936a0862a07cbe87b525eab8d4f8
/external/drm_hwcomposer/drmdisplaycomposition.cpp
573554106db499d323bea12ff00363b1816f8c8a 19-Sep-2015 Sean Paul <seanpaul@chromium.org> drm_hwcomposer: Process modesets via compositor

This patch queues modeset in the compositor for application on
the next frame. This allows us to perform the modeset atomically
with the first frame that comes in after the mode is changed.

Change-Id: I6bb9edd17bbdd6dbee5c0474f2e43599781cc7a7
Signed-off-by: Sean Paul <seanpaul@chromium.org>
/external/drm_hwcomposer/drmdisplaycomposition.cpp
4a253659cef3d82bfb0b25b3ff4c7b073d7a0460 11-Sep-2015 Zach Reizner <zachr@google.com> drm_hwcomposer: implement the safe handling of layers

This is a sweeping change to discard our usage of struct hwc_layer_t outside
hwcomposer.cpp. That was a dangerous struct that was a source of many of our
errors. Replacing it with safer RAII-style classes reduces the amount and
complexity of our code.

Change-Id: I580cafdf89bd1e7e6583f3073858b8e78e6018ba
/external/drm_hwcomposer/drmdisplaycomposition.cpp
bdc67bffcffaa838836b1111f6dcf07cba5ff134 21-Sep-2015 Sean Paul <seanpaul@chromium.org> drm_hwcomposer: Plumb frame number through display composition

Having frame number in the composition is very useful for
debugging transient issues, plumb it through the drm compositor
stack.

Change-Id: Ibc7555c89bea79c580b3201b11db4ced6360efb9
Signed-off-by: Sean Paul <seanpaul@chromium.org>
/external/drm_hwcomposer/drmdisplaycomposition.cpp
2143d3bc9da37525cacd432cd51b6e4f459c47a2 04-Sep-2015 Sean Paul <seanpaul@chromium.org> drm_hwcomposer: Allow NULL crtcs in display composition

In cases where we have displays which do not have a mode,
the crtc will be NULL. This shouldn't fail the composition
initialization.

Change-Id: I1a6acb72cd3f614b5a7c854ba61be1539efa4bea
Signed-off-by: Sean Paul <seanpaul@chromium.org>
/external/drm_hwcomposer/drmdisplaycomposition.cpp
3c32ca686cfb7bc7384e6c675610b5898d4c7ba0 25-Aug-2015 Stéphane Marchesin <marcheu@chromium.org> drm_hwcomposer: Allow layer transforms

They are very much valid now. I think this is just leftover?

BUG=chrome-os-partner:42717
TEST=test rotation, it doesn't lock up

Change-Id: I4cd96ae91c91452ef2be3cb3b07c123ce38ed576
/external/drm_hwcomposer/drmdisplaycomposition.cpp
098070590ae648ede5f2ef846298de178ccd3637 13-Aug-2015 Zach Reizner <zachr@google.com> drm_hwcomposer: enhance stability using various wrapper classes

This commit contains a lot of churn because it changes code to use automatic
resource lifetimes as much as possible. As more things get changed, this is
essential to maintaining stability.

In addition, this change changes how layers are passed through the compositor
API. Before each layer was passed down one at a time. Now they are passed in
all at once. This is simpler for the implementation because it makes errors
more atomic and makes decisions easier for the compositors.

Change-Id: Ic3e6b5d0089fb1631ea256adcce9910ed8f38366
/external/drm_hwcomposer/drmdisplaycomposition.cpp
b44fd10aef978ff4f77258803f86d76244349333 08-Aug-2015 Zach Reizner <zachr@google.com> drm_hwcomposer: duplicate buffer_handles before hwc_set returns

This is needed because SF will sometimes release buffer_handles before GL gets
to using them for composition.

Change-Id: I01db0975cc82d6b59bf4f9521a24071baf89c38a
/external/drm_hwcomposer/drmdisplaycomposition.cpp
46ddd45e334b61e15a86cc333cc35e8cb64fc0b8 30-Jul-2015 Zach Reizner <zachr@google.com> drm_hwcomposer: fix buffer leak when using the GL compositor inside DrmDisplayCompositor

Change-Id: Id3a6deea9fc0f97640b34dacb25d36f3793f2d4e
/external/drm_hwcomposer/drmdisplaycomposition.cpp
713a6788528d4cc4cd477b2f546c8b922beb6dde 01-Aug-2015 Zach Reizner <zachr@google.com> Revert "Revert "drm_hwcomposer: have DrmDisplayCompositor do its own OpenGL composition""

This reverts commit cbe9c01336e23a63259db65d22d63d6a697b8813.
/external/drm_hwcomposer/drmdisplaycomposition.cpp
cbe9c01336e23a63259db65d22d63d6a697b8813 30-Jul-2015 Puneet Kumar <puneetster@google.com> Revert "drm_hwcomposer: have DrmDisplayCompositor do its own OpenGL composition"

This reverts commit 2317bb19d8663efc31e6fcd8cf7fd2a73577253d.

For now until we figure out a more stable SF/hwc

Change-Id: Ia5ca089610a487bf036a1ddd5fb62e504e02ad98
/external/drm_hwcomposer/drmdisplaycomposition.cpp
2317bb19d8663efc31e6fcd8cf7fd2a73577253d 16-Jul-2015 Zach Reizner <zachr@google.com> drm_hwcomposer: have DrmDisplayCompositor do its own OpenGL composition

To accomplish this a few things changed:
- DrmComposition::GetRemainingLayers always returns the number of planes needed
- DrmComposition::AddLayer succeeds even if no DrmPlane was found for it
- DrmDisplayComposition::AddLayer has overload that imports the given buffer
- GLWorkerCompositor has a function to finish its composite before returning

Put together this change makes DrmComposition always accepts all layers given to
it even if it means some of those layers are assigned a NULL DrmPlane. The
DrmDisplayCompositor will scan its given layers for any that are missing planes.
In such a case, a DrmPlane is stolen from the last layer to receive a plane.
Then all layers in the DrmDisplayComposition that have no planes (including the
one stolen from) are composited synchronously using a GLWorkerCompositor and a
new layer is generated from the results. That layer is added to the
DrmDisplayComposition using the new import AddLayer function and the stolen
DrmPlane. DrmDisplayCompostior then continues as usual.

Change-Id: Ia6477c210c8f1307a4e537bec46889110d79ca18
/external/drm_hwcomposer/drmdisplaycomposition.cpp
ece04894ab2d2fc3d5001a9e50a242b2d3f765da 17-Jul-2015 Zach Reizner <zachr@google.com> drm_hwcomposer: make sure all fences are released for DrmDisplayComposition

This change will release the layers passed back to SurfaceFlinger even on an
error in the compositor thread.

Change-Id: I22f622855c8c953a058b4a08d0af1ae427e4cbbd
/external/drm_hwcomposer/drmdisplaycomposition.cpp
1c4c32635df1f45bbcf63c8c1a76207ca90402e5 14-Jul-2015 Sean Paul <seanpaul@chromium.org> drm_hwcomposer: Add rotation support for hw planes

This patch adds support for transformed layers by using the
rotation property on drm planes.

Bug: chrome-os-partner:42093
Test: On smaug using
adb shell content insert --uri content://settings/system --bind name:s:user_rotation --bind value:i:<R>

Change-Id: I86bb8ef2f77b5d046a5fddd57db4b87070b5801f
Signed-off-by: Sean Paul <seanpaul@chromium.org>
/external/drm_hwcomposer/drmdisplaycomposition.cpp
2e46fbd90b1aae158ec0437f564dd610e7392f7a 09-Jul-2015 Sean Paul <seanpaul@chromium.org> drm_hwcomposer: Disable unused planes

Right before queuing up a composition, go through the
list of unused planes and add disable markers such
that they don't remain active when the new frame is
posted.

BUG=chrome-os-parter:42311
TEST=Tested on smaug, turned on/off bunch of times, no dup icons

Change-Id: Ic2e5e210873efb6dc41fd43682fe00db33c2a28e
Signed-off-by: Sean Paul <seanpaul@chromium.org>
/external/drm_hwcomposer/drmdisplaycomposition.cpp
db7a17d28ca48f81be3091e99564e47fa0503e9e 25-Jun-2015 Sean Paul <seanpaul@chromium.org> drm_hwcomposer: Process DPMS requests through compositor

This patch changes the behavior of DPMS in hwcomposer from
applying asynchronously/immediately, to queuing in the
compositor and being processed in order. This is desirable
for a couple of reasons:
1- It ensures all frames set before set_power_mode are
shown on the screen before it turns off
2- We make sure we don't rmfb a framebuffer that is
currently applied to a disabled crtc.

The second reason above can cause the display to turn back
off once it's on since the fb will dereference to zero in
the kernel and it will disable the pipe without notifying
us.

Change-Id: I2aab9ee0353b12fecced46766ed2dbb64f0aef4b
Signed-off-by: Sean Paul <seanpaul@chromium.org>
/external/drm_hwcomposer/drmdisplaycomposition.cpp
acb2a4494e79f0026f8615acc561257276a71062 25-Jun-2015 Sean Paul <seanpaul@chromium.org> drm_hwcomposer: Add composition type to DrmComposition

This allows us to have different types of compositions. This will
enable injection of non-frame related compositions such as dpms
and mode.

Change-Id: Ia62421c114c0c6bebccef3ce6ae936366b6aafe2
Signed-off-by: Sean Paul <seanpaul@chromium.org>
/external/drm_hwcomposer/drmdisplaycomposition.cpp
98e73c89a683a92f44c99fb8dc85e51bdda243ba 24-Jun-2015 Sean Paul <seanpaul@chromium.org> drm_hwcomposer: Split the drm compositor into per-display threads

This patch splits out the current single drm compositor with
per-display compositors, each with their own thread.

The per-display compositors are hidden behind a singleton
drm compositor. This allows us to maintain a whole-world view
of all displays involved in a frame. This becomes useful if
we start switching up crtcs/encoders for the displays.
This also allows us to issue one DrmComposition when the
frame is being assembled.

The single DrmComposition handles the plane allocation (since they
might switch between displays), and contains per-display compositions
which are used to store the layer->plane/crtc information for each
frame. The display compositors use the per-display compositions to
display the frame on their output.

Each display compositor receives a shared pointer to the frame's
DrmComposition on QueueComposition. As a result, both the composition,
and the per-display compositions, live for as long as any one
display is still using it. While this is sub-optimal (since a display
might never update again), this is probably fine for now.

Finally, splitting things up per-display will allow us to inject
non-compositing jobs into the composite queue. An example would be
turning the display off, or setting the mode. This ensures that all
frames in the composite queue are displayed before the mode changes
or the display is disabled.

Signed-off-by: Sean Paul <seanpaul@chromium.org>
Change-Id: I8a233ea64710b238f70acbcde1f6d771e297b069
/external/drm_hwcomposer/drmdisplaycomposition.cpp