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
|