drm_hwcomposer: Fixup Sean's HiSi dummy planner

The dummy HiSi Planner is careful to not try to emplace layers
that aren't HW_FB. However, in some cases we might have a single
layer to draw. In that case the dummy importer will pretend it
imported the buffer, and the planner will skip over it and not
emplace it. Since there were no errors and the layers_ count is
the same as the available planes, we won't force client
composition, and will try to do device composition for the
buffer we didn't really import.

This results in the drm layer going a bit wonky.

Thus, this patch tries to fix this by erroring out if we try to
plan only a single layer, but don't emplace anything. This
results in the CreateComposition() function failing, which will
force client rendering, making it work (with only minimal logcat
noise - only in the single layer case).

Change-Id: I563dbba3c2adce5617fae61cb0440368053e5bff
Signed-off-by: John Stultz <john.stultz@linaro.org>

drm_hwcomposer: Fix HiSi import fail log spam

hikey can only display layers which do not have gralloc usage HW_FB
(hint: that leaves just the client target layer). As such, there's no
benefit trying to import them since it'll just fail. So if we encounter
a layer such as this, fake the import (the release will be a noop since
gem_handles will be 0).

Also, as a belt-and-suspenders move, replace the greedy planner with one
that only displays (usage != HW_FB) to be doubly sure that we don't try
to display the no-op layers

Change-Id: I7bf88cfb7bda1dd5f47b741709619494431558a2
Signed-off-by: Sean Paul <seanpaul@chromium.org>

drm_hwcomposer: Reformat using clang-format-5.0

Run the new clang-format style over the codebase to make things
compatible.

Change-Id: I267d5070929aaa7965d58655da841402debdcb6c
Signed-off-by: Sean Paul <seanpaul@chromium.org>

drm_hwcomposer: Update clang-format to 5.0

Updating clang-format to 5.0 to get a bit more control over our
styling. Two things that will be beneficial:

- Alphabeticalize headers
- More control around line breaking, especially preferring

val = SomeFunction(arg1,
                   arg2);

vs:

val =
    SomeFunction(arg1, arg2);

It's still not perfect, but it seems greatly improved.

Signed-off-by: Sean Paul <seanpaul@chromium.org>

drm_hwcomposer: add scene flattening

Flattening of a scene is triggered if it doesn't change for a while.
As of now there is a separate thread which triggers flattening if the
scene did not change in last 60 vsyncs.

There are two options for flattening a scene:
* Serial, by using a writeback connector attached to the same crtc as
  the one driving the display. This happens only if possible_clones
  mask reports that the display encoder and writeback encoder could
  work simultaneously.
The steps for achieving this are:
1. Build a commit that enables writeback connector, we don't need to
   build a commit that contains the entire active_composition, just
   set the writeback specific properties a let the kernel duplicate
   the rest of the state.
2. Commit and wait for writeback_fence to fire.
3. Setup a composition with just one plane enabled.
4. Apply the composition if a new one has not been applied meanwhile.

* Concurrent, by comitting the scene to a new unused crtc (state !=
  DRM_MODE_CONNECTED) and getting the result back through a writeback
  connector.
The steps for achieving this are:
1. Copy layers from active composition.
2. Plan layers of copy on the unused crtc. This is realized by using a
   newly created DrmDisplayCompositor object.
3. Commit copy to the unsed crtc and get the result as a drmhwclayer.
4. Setup a composition with just one plane enabled. Re-importing the
   buffers might be needed since we might have been using a different
   dri node.
5. Apply the composition if a new one has not been applied while doing
   the flattening

Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>

drm_hwcomposer: Fix race in ApplyFrame

ApplyFrame holds the lock just when it swaps the value of
active_composition_, in a multithread context we could end up in a
situation where something is shown on the screen, but something else
is set in active_composition_. Fix it by holding the lock during
CommitFrame.

Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>

drm_hwcomposer: Handle writeback connectors

When writeback connectors are available assign them to displays, in
order to be able to use them for flattening of the current displayed
scene. The pipeline for each display will look like this:

CRTC ---- encoder ------------ display connector.
 |------- writeback enc ------ writeback connector.

However, the writeback connector will be later used/enabled only if
one of the following conditions are met:
 - Could be a clone of the display connector, as pointed by the
   possible_clones property.
 - The display_connector is disconnected, so we are safe to use it for
   flattening the scene that's already presented on another display.

Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>

drm_hwcomposer: Parse and store possible_clones information

drmModeEncoder has a field called possible_clones. It's a bit mask
which tells if the encoder could be simultaneously connected, to the
same CRTC, with the encoders specified in the possible_clones mask.

Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>

drm_hwcomposer: Add display field to Drmencoder

In the current implementation TryEncoderForDisplay just looks
at the crtc linked to the display, if that's not assigned to
a display it means the encoder could be used, otherwise iterate
to the list of possible_crtcs and find one which is not used.

This logic works fine when you have just one encoder connected to a
crtc but with two or more, like is the case when we attach a writeback
connector, we need to know if we already assigned the encoder to a
display.

Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>

drm_hwcomposer: Add writeback connector support

Writeback connector is a special case of connector, which can be
linked to a CRTC in order to get the result of the composition back to
a memory buffer. This had not been merged to the mainline kernel yet,
latest version of the kernel patches could be found here [1].

[1] https://lists.freedesktop.org/archives/dri-devel/2018-February/167703.html

Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
Reviewed-by: Sean Paul <seanpaul at chromium.org>

drm_hwcomposer: Purge drm_ from drmdisplaycompositor

Having DrmDevice as a member in DrmDisplayCompositor is redundant,
since that could be always retrieved by calling:
resource_manager_->GetDrmDevice(display_)

Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>

drm_hwcomposer: Pass resource manager to drmdisplaycompositor

Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>

drm_hwcomposer: Add resource manager support

Add a resource manager class that is responsible for detecting all
kms devices and allocates unique display numbers for every detected
display.

This is controlled by the value of hwc.drm.device property, if it ends
with a %, it will try to open minor devices until an error is detected.
E.g: /dev/dri/card%

Additionally, this will be used for finding an available writeback
connector that will be used for the flattening of the currently
displayed scene.

Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>

drm_hwcomposer: Rename DrmResources to DrmDevice

DrmDevice is a better name to reflect the fact that DrmResources/
DrmDevice can handle just one dri node.

Suggested here [1] by Sean Paul.
[1] https://lists.freedesktop.org/archives/dri-devel/2018-April/173290.html

Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>

drm_hwcomposer: Drop -Wno-unused-* build options and remove unused variables

This patch drops the -Wno-unused-* build options and removes
the currently unused variables that would keep things from
building.

Signed-off-by: John Stultz <john.stultz@linaro.org>

drm_hwcomposer: Really fail on CreateComposition failures

The current logic in Validate assumes that if CreateComposition()
fails, it was due to overlay planes as sets the avail_planes to 1.

With most multi-plane compositions, this will then cause the
avil_planes to be later decremented to zero (to reserve the client
composited plane), resulting in all the layers to be set as
client composited.

However, in the case where there is only one layer, such as with
the Android BootAnimation, if CreateComposition fails, we set
avail_planes to one, and since there is only one layer, we don't
decrement it further, resulting in the layer to be validated as
a Device rendered layer, as if CreateComposition succeeded.

This adds an extra flag we don't mix up a single layer failure
as a success.

On HiKey/HiKey960, this patch fixes the issue where the
BootAnimation wouldn't display.

Change-Id: I58bf5f332667a46e8e997d1743b73dd4a768657f
Signed-off-by: John Stultz <john.stultz@linaro.org>

drm_hwcomposer: Avoid filling the log with warnings when test compositions fail

We frequently test compositions that might fail due to various
reasons. On db820 we see:

 W HwcComposer: command 0x4010000 generated error 8
 E hwc-drm-display-compositor: Alpha is not supported on plane 29
 E hwc-drm-two: Failed to apply the frame composition ret=-22

over and over

So to avoid filling the log with errors when those test
compsitions don't work out, this patch tries to quiet down those
error messages when we are doing test compositions.

Change-Id: Iab19628bd7488c7d104e2c775310989bb59e140d
Signed-off-by: John Stultz <john.stultz@linaro.org>

drm_hwcomposer: platformhisi: Add support for importing DRM_FORMAT_YVU420 buffers

When trying to play fullscreen video, I started seeing import
errors, which were caused by us trying to call drmModeAddFB2()
with fmt DRM_FORMAT_YVU420 but only setting the a single set of
handle/pitch/offset values.

In the kernel, the framebuffer_check() function would then fail
with "no buffer object handle for plane 1" since we only passed
one plane in.

Thus this patch calculates and sets the pitch/offset values for
the separate planes in the single gem_handle buffer.

Many thanks to Stefan Schake and Rob Herring for helping me
understand some of the subtleties of image plans vs display
planes, etc.

Change-Id: I2d9bdfc66c504e6446a4f9c6287ab675201afa30
Signed-off-by: John Stultz <john.stultz@linaro.org>

drm_hwcomposer: platformdrmgeneric: Handle closing gem_handles if we have duplicate handles

In some cases some multi-plane bo's may have multiple
gem_handles/offsets/pitches set. And its possible to have
multiple planes that use the same gem_handle with different
offsets/pitches.

Thus, when closing the gem_handles, if we're not careful
we could close the same handle multiple times. So this
patch avoids this by taking some old code from the nv
importer:
https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/blob/aeccd89eaafec467cb9449cce5c64152a240c138/platformnv.cpp#L176

Many thanks to Stefan Schake for pointing me to that code.

Change-Id: Ifecd0f95de5ada5280a0af807005d0b0186a068c
Signed-off-by: John Stultz <john.stultz@linaro.org>

drm_hwcomposer: Set client composition buffer at the bottom.

Currently, we allocate layers to device composition from bottom to
top and save the last DrmPlane from the top to be used by the client
target buffer.

However, we don't know much about client layer, so information for
layers which we decided to set as ClientComposition, will be lost.

For example, in BlendMode case if we have the following scene, with 2
DrmPlanes available.

z0: LAYER0 AR24 BlendNone.
z1: LAYER1 AR24 BlendPremulti.
z2: LAYER2 AR24 BlendPremulti.

We decide:
z0: LAYER0 DeviceComposition
z1: LAYER1 ClientComposition
z2: LAYER2 ClientComposition

LAYER1+LAYER2 will be in client target buffer, but we don't know
nothing about the blending for client_target_layer. Which Android
actually expects to be still BlendPremulti. So, we are kind of stucked
we the default value which is BlendNone.

I think there are two ways to solve this issue:
1) This commit, allocate layers as DeviceComposition
from top to bottom and save the bottom for ClientComposition.
2) A smarter logic for detecting what should be the actual properties
of client_layer_target, but I still think it makes more sense to
actually have the client_layer_target at the bottom.

Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>

drm_hwcomposer: Support assigning planes in ValidateDisplay

In order to assign planes to layers in ValidateDisplay, testing
compositing with a DRM atomic modeset test is needed as PresentDisplay
is too late. This means most of PresentDisplay needs to be run from
ValidateDisplay, so refactor PresentDisplay to a common function adding
a test only option.

Signed-off-by: Rob Herring <robh@kernel.org>

drm_hwcomposer: remove separate_rects

As part of removing GL compositing, separate_rects.cpp is no long
needed. Use hwc_rect_t and hwc_frect_t in places instead of our own
class.

Signed-off-by: Rob Herring <robh@kernel.org>

drm_hwcomposer: Remove GL compositing support

The GL based compositing adds alot of complexity and was only ever well
tested on closed stacks. It also only supports GLES3.x and still relies
on sw_sync timeline which is now a debugfs feature. Those are just the
known issues.

Removing the GL compositor means everything related to squashing layers
and pre-compositing can be removed. The planner is left as it may be
useful when adding back support for overlay planes. With this change,
only a single plane is supported until ValidateDisplay learns to do
atomic modesetting test for overlay planes.

Tested-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Rob Herring <robh@kernel.org>

Revert "drm_hwcomposer: Cleanup gl precompositor init and provide uses_GL flag"

This reverts commit 3b0c69d3477d3601b1dbcb75fdd748254e297e7e.

Revert "drm_hwcomposer: Fall back to client compositon if the gl precompostior fails"

This reverts commit acc4dcf1787b9fc43c5748ce06e79f045e07a3ff.

drm_hwcomposer: Try to fix clang-format pipeline

The clang-format pipeline generates false negatives
sometimes, with:

$ git diff -U0 --no-color master...HEAD | clang-format-diff-3.5 -p 1 -style=file > format-fixup.patch
fatal: ambiguous argument 'master...HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:

as seen here:
https://gitlab.freedesktop.org/john.stultz/drm-hwcomposer/-/jobs/932

This tries to address the issue by explictly fetching
freedesktop/master and referencing FETHC_HEAD instead of master
which doesn't always exist.

Change-Id: I7a07d412eae164841427da90dfc7298697c5e783
Reviewed-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>

drm_hwcomposer: Remove gralloc from generic code

Clean up direct gralloc usage from generic code.
Because of gralloc0/gralloc1 difference, it should
be only used by platform* part.

Signed-off-by: Andrii Chepurnyi <andrii_chepurnyi@epam.com>

drm_hwcomposer: Use GraphicBufferMapper for copy buffer handle

Due to gralloc0/gralloc1 API incompatibility(register/unregister
vs retain/release) it is preferred to use generic
GraphicBufferMapper API for copy buffer handle. It will use
an appropriate adapter for the present version of gralloc.
For the reference: hardware/interfaces/graphics/mapper

Change-Id: Ia4740ed3b2ffd43fa3c107eb22d792eaabd4df40
Signed-off-by: Andrii Chepurnyi <andrii_chepurnyi@epam.com>

drm_hwcomposer: Ignore context in clang-format-diff

Signed-off-by: Stefan Schake <stschake@gmail.com>

drm_hwcomposer: vsyncworker: Fix deadlock on exit path

vsyncworker::Routine assumes that when -EINTR is returned by
WaitForSignalOrExitLocked the lock as been released, which is not
true, so it hangs if a vsyncworker is never enabled and Exit is
called.

Fixed by releasing lock in vsynworker::Routine on all code paths.

Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>

drm_hwcomposer: Add pass/fail CI step for clang format-diff

Signed-off-by: Stefan Schake <stschake@gmail.com>

drm_hwcomposer: Add README.md
Although we had CONTRIBUTING.md, gitlab didn't really highlight it. So I tried putting this info in the wiki, but that was equally hard to discover. _then_ I thought gitlab pages was the right way to go, but no.

Turns out README.md will be harvested by gitlab and shown on the project's frontpage \o/

Signed-off-by: Sean Paul <seanpaul@chromium.org>

drm_hwcomposer: Make sure we check for new 16bit alpha value

In commit 025d0a65 ("Use 16 bit value for plane alpha"),
the alpha value was bumped to a 16bit value.

Unfortunately in drmdisplaycompositor.cpp we are still
comparing it against a 8bit 0xff value, which now fails
causing the display to not start.

So fix this comparing to the 16bit 0xffff value.

With this change the display starts up again.

Change-Id: Ic796b16fb57ae7cea58b5c66c456a58e3fb57ba5
Signed-off-by: John Stultz <john.stultz@linaro.org>

drm_hwcomposer: Use -Werror in external/drm_hwcomposer

* Suppress non-critical warnings.

I'm submitting this patch to try to align aosp/master
with the upstream fdo/master branch.

Bug: 66996870
Change-Id: I48e87526e408980c90e8a45e134f95da7a89a19d
Signed-off-by: John Stultz <john.stultz@linaro.org>

drm_hwcomposer: License NOTICE file and metadata from AOSP

This is a forward ported patch from the AOSP/master
branch which adds the Apache2 license notice and
a empty MODULE_LICENCE_APACHE2 file.

I'm submitting these to try to align aosp/master
with upstream fdo/master

BUG:67772237
Change-Id: I65396852e1b64d2052232b38740e6ede20e81776
Signed-off-by: John Stultz <john.stultz@linaro.org>

drm_hwcomposer: Use 16 bit value for plane alpha

The upstream version of the alpha property uses 16 bits to make it future
proof. Since HWC2 already passes in a float expand our internal
representation instead of just shifting for DRM.

Signed-off-by: Stefan Schake <stschake@gmail.com>

drm_hwcomposer: Remove unused init from HWC1 layer

The HWC1 code isn't being compiled anymore.

Signed-off-by: Stefan Schake <stschake@gmail.com>

drm_hwcomposer: Remove NVIDIA importer header

Commit 0f7487f drm_hwcomposer: remove NVIDIA importer removed most of
the implementation, but not the platformnv.h header file. Remove this
header now.

Cc: John Stultz <john.stultz@linaro.org>
Cc: Rob Herring <rob.herring@linaro.org>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Robert Foss <robert.foss@collabora.com>
Acked-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Alistair Strachan <astrachan@google.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>

drm_hwcomposer: Add platform backend for minigbm

This adds support for the chromiumos (not AOSP) version of minigbm. Like
hisi, the gralloc handle is not the same as the common libdrm handle
(just yet), so we do need a separate backend for now.

Tested with a pending change to the 'cuttlefish' android virtual device
in AOSP with its custom gralloc switched to minigbm.

Cc: John Stultz <john.stultz@linaro.org>
Cc: Rob Herring <rob.herring@linaro.org>
Cc: Sean Paul <seanpaul@google.com>
Cc: Greg Hartman <ghartman@google.com>
Tested-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Alistair Strachan <astrachan@google.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>

drm_hwcomposer: Drop obsolete drm_gralloc include path

In commit d12274d, "drm_hwcomposer: Rework platformdrmgeneric.cpp
to use libdrm's gralloc handle", the use of drm_gralloc was removed.

Cc: John Stultz <john.stultz@linaro.org>
Cc: Rob Herring <rob.herring@linaro.org>
Cc: Sean Paul <seanpaul@google.com>
Cc: Robert Foss <robert.foss@collabora.com>
Cc: Stefan Schake <stschake@gmail.com>
Acked-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Alistair Strachan <astrachan@google.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>

drm_hwcomposer: Mark tests as vendor, fix build

After commit 94bb596, the tests for drm_hwcomposer no longer build,
because the build system detects that they are linking other vendor
modules (but installing themselves elsewhere).

This change also adds the libhardware include path explicitly, as the
implicit include of hardware/libhardware/include is going away.

Cc: John Stultz <john.stultz@linaro.org>
Cc: Rob Herring <rob.herring@linaro.org>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Sean Paul <seanpaul@google.com>
Cc: Robert Foss <robert.foss@collabora.com>
Acked-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Alistair Strachan <astrachan@google.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>

drm_hwcomposer: Fall back to client compositon if the gl precompostior fails

If the gl precompositor isn't being used, we cannot accept
every layer as a device composited layer.

Thus this patch adds some extra logic in the validate function
to fall back to client side compositing if the gl precompositor
did not initialize properly.

This does force everything to a single plane even if we have
a few available, but a deeper rework of the validate step
planning is needed before we can reliably make use of them.

Credit to Rob Herring, who's single plane patch was what this
was originally based on.

Cc: Marissa Wall <marissaw@google.com>
Cc: Sean Paul <seanpaul@google.com>
Cc: Dmitry Shmidt <dimitrysh@google.com>
Cc: Robert Foss <robert.foss@collabora.com>
Cc: Matt Szczesiak <matt.szczesiak@arm.com>
Cc: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: David Hanna <david.hanna11@gmail.com>
Cc: Rob Herring <rob.herring@linaro.org>
Cc: Alexandru-Cosmin Gheorghe <Alexandru-Cosmin.Gheorghe@arm.com>
Cc: Alistair Strachan <astrachan@google.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>

drm_hwcomposer: Cleanup gl precompositor init and provide uses_GL flag

The drm_hwcomposer has its own GL pre-compositor which is used
to squish layers when there are more layers then planes on the
display hardware. In many ways this duplicates the client-side
GL compositing that is done in SurfaceFlinger, but in theory can
be more highly optimized for the hardware.

Unfortunately, due to these optimizations, the drm_hwcomposer's
pre-compositor becomes somewhat hardware specific (originally
targeting nvidia hardware, I believe).

So on some hardware, the gl precompositor may not actually
initialize due to hardware missing features, or the hardware
supporting different shader APIs.

Rather then try to rework the drm_hwcomposers precompositor
to be more generic, I instead suggest that when the
precompositor fails to initialize, we simply fall back to the
already more widely compatible client compositor in
SurfaceFlinger.

Thus, this patch cleans up some of the precompositor
initialization, which didn't handle failures well.

Cc: Marissa Wall <marissaw@google.com>
Cc: Sean Paul <seanpaul@google.com>
Cc: Dmitry Shmidt <dimitrysh@google.com>
Cc: Robert Foss <robert.foss@collabora.com>
Cc: Matt Szczesiak <matt.szczesiak@arm.com>
Cc: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: David Hanna <david.hanna11@gmail.com>
Cc: Rob Herring <rob.herring@linaro.org>
Cc: Alexandru-Cosmin Gheorghe <Alexandru-Cosmin.Gheorghe@arm.com>
Cc: Alistair Strachan <astrachan@google.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>

drm_hwcomposer: Use log/log.h instead of cutils/log.h

When enabling Treble, Android builds are complaining about using
cutils/log.h so instead use log/log.h

Cc: Marissa Wall <marissaw@google.com>
Cc: Sean Paul <seanpaul@google.com>
Cc: Dmitry Shmidt <dimitrysh@google.com>
Cc: Robert Foss <robert.foss@collabora.com>
Cc: Matt Szczesiak <matt.szczesiak@arm.com>
Cc: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: David Hanna <david.hanna11@gmail.com>
Cc: Rob Herring <rob.herring@linaro.org>
Cc: Alexandru-Cosmin Gheorghe <Alexandru-Cosmin.Gheorghe@arm.com>
Cc: Alistair Strachan <astrachan@google.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>

drm_hwcomposer: Andorid.mk : Mark libdrmhwc_utils as vendor module

To allow drm_hwcomposer to build with Treble, set
the libdrmhwc_utils library as a vendor module.

Cc: Marissa Wall <marissaw@google.com>
Cc: Sean Paul <seanpaul@google.com>
Cc: Dmitry Shmidt <dimitrysh@google.com>
Cc: Robert Foss <robert.foss@collabora.com>
Cc: Matt Szczesiak <matt.szczesiak@arm.com>
Cc: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: David Hanna <david.hanna11@gmail.com>
Cc: Rob Herring <rob.herring@linaro.org>
Cc: Alexandru-Cosmin Gheorghe <Alexandru-Cosmin.Gheorghe@arm.com>
Cc: Alistair Strachan <astrachan@google.com>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
[jstultz: commit message tweaks]
Signed-off-by: John Stultz <john.stultz@linaro.org>

drm_hwcomposer: drmeventlistener: Set nl_pid to 0

By setting nl_pid to 0, we let the kernel to assign a port for us.
In the current implementation there is no way we could create more
than one instance for drmeventlistener.

Acked-by: Robert Foss <robert.foss@collabora.com>
Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>

drm_hwcomposer: vsyncworker: Fix uninitialized enabled_ field

Acked-by: Robert Foss <robert.foss@collabora.com>
Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>

drm_hwcomposer: Rework platformdrmgeneric.cpp to use libdrm's gralloc handle

Rework the platformdrmgeneric buffer importer to use the libdrm
generic gralloc handle definition.

This is just to get the drm_hwcomposer project building in AOSP
along with the libdrm freedesktop/master branch. Similar changes
may also be needed to gbm_gralloc and other projects not used
in AOSP.

Mostly just sending this out for review feedback.

Cc: Robert Foss <robert.foss@collabora.com>
Cc: Rob Herring <rob.herring@linaro.org>
Cc: Sean Paul <seanpaul@google.com>
Cc: Stefan Schake <stschake@gmail.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Robert Foss <robert.foss@collabora.com>

Delete CONTRIBUTING, migrated information to the gitlab wiki

drm_hwcomposer: Add platformhisi buffer importer for hikey and hikey960

This allows for importing buffers allocated from the
hikey and hikey960 gralloc implementations.

Cc: Marissa Wall <marissaw@google.com>
Cc: Sean Paul <seanpaul@google.com>
Cc: Dmitry Shmidt <dimitrysh@google.com>
Cc: Robert Foss <robert.foss@collabora.com>
Cc: Matt Szczesiak <matt.szczesiak@arm.com>
Cc: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: David Hanna <david.hanna11@gmail.com>
Cc: Rob Herring <rob.herring@linaro.org>
Cc: Alexandru-Cosmin Gheorghe <Alexandru-Cosmin.Gheorghe@arm.com>
Cc: Alistair Strachan <astrachan@google.com>
Acked-by: Robert Foss <robert.foss@collabora.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>

drm_hwcomposer: Enable and refactor Separate Rects test

Plumb through the existing test based on known sample data for the
Separate Rect algorithm via Android's NATIVE_TEST harness.

Signed-off-by: Rhys Kidd <rhyskidd@gmail.com>
Signed-off-by: Robert Foss <robert.foss@collabora.com>

drm_hwcomposer: Fix comment on worker_test

Reflect the boolean logic of the accompanying code, which is run after
Worker.InitWorker() has completed in test setup.

Signed-off-by: Rhys Kidd <rhyskidd@gmail.com>
Signed-off-by: Robert Foss <robert.foss@collabora.com>

drm_hwcomposer: fix check for valid fence fd for in fences

The check for a valid fence fd is inverted, so we're failing to pass
IN_FENCE_FD's to the kernel when we have a valid fence.

Reported-by: Alexandru-Cosmin Gheorghe <Alexandru-Cosmin.Gheorghe@arm.com>
Reviewed-by: Robert Foss <robert.foss@collabora.com>
Signed-off-by: Rob Herring <robh@kernel.org>

drm_hwcomposer: Make sure we set the active state when doing modesets

In trying to use drm_hwcomposer with HiKey/HiKey960 boards, I
found that the crtc wouldn't intitalize and the atomic commit
calls were failing.

I initially chased this down to following check in the kernel
drm_atomic_crtc_check() function failing:

 if (state->event && !state->active && !crtc->state->active) {
     DRM_DEBUG_ATOMIC("[CRTC:%d:%s] requesting event but off\n",
                      crtc->base.id, crtc->name);
     return -EINVAL;
 }

Where because a fence was submitted state->event was set, but
the crtc state was not active. This results in the atomic commit
to fail and no mode to be set.

After hacking around this in the kernel, Sean Paul helped me
understand that it was the kernel complaining about the crtc
state being provided in the atomic commit which did not have the
active flag set.

Thus, the proper fix is to make sure when we do the modesetting
that we also set the crtc state active flag in property set.

With this change, the kernel no longer rejects the atomic commit
and the crtc initializes properly.

Cc: Marissa Wall <marissaw@google.com>
Cc: Sean Paul <seanpaul@google.com>
Cc: Dmitry Shmidt <dimitrysh@google.com>
Cc: Robert Foss <robert.foss@collabora.com>
Cc: Matt Szczesiak <matt.szczesiak@arm.com>
Cc: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: David Hanna <david.hanna11@gmail.com>
Cc: Rob Herring <rob.herring@linaro.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>

drm_hwcomposer: Update external connectors list

DVID, DVII and VGA are required by discrete and integrated GPUs.

Signed-off-by: Mauro Rossi <issor.oruam@gmail.com>

drm_hwcomposer: fix warnings on unused variables and parameters

AOSP master now builds by default with -Werror, so fix all the warnings.
All the warnings are related to unused variables and parameters.

Reviewed-by: Robert Foss <robert.foss@collabora.com>
Signed-off-by: Rob Herring <robh@kernel.org>

drm_hwcomposer: Add HDMI connector as a valid type

Accept DRM_MODE_CONNECTOR_HDMIA connector type.

Look for primary DrmConnector amongst external connectors
after looking for primary amongst internal ones first.

Signed-off-by: Robert Foss <robert.foss@collabora.com>
Signed-off-by: Rob Herring <robh@kernel.org>

drm_hwcomposer: correct handling of DRM_MODE_ROTATE_0

If the rotation property is supported for a plane, then the rotation
value must be non-zero. For the case of 0 degree rotation,
DRM_MODE_ROTATE_0 needs to be set.

Signed-off-by: Rob Herring <robh@kernel.org>

drm_hwcomposer: remove unnecessary external includes

Linking to libraries will add necessary include paths, so we don't need to
list them explicitly.

Still need libsync for sw_sync.h until this dependency is removed.

Tested-by: Chih-Wei Huang <cwhuang@linux.org.tw>
Reviewed-by: Chih-Wei Huang <cwhuang@linux.org.tw>
Signed-off-by: Rob Herring <robh@kernel.org>

drm_hwcomposer: make sure primary plane is allocated for squash

There are instances where the primary plane may have been disabled, look
through disabled planes as well to find primary plane to use for squash.

Signed-off-by: Adrian Salido <salidoa@google.com>
Reviewed-by: Robert Foss <robert.foss@collabora.com>

drm_hwcomposer: fix return values for ValidateDisplay

According to the API documentation, if we've set num_types, then the
return value should be HWC2::Error::HasChanges.

Signed-off-by: Rob Herring <robh@kernel.org>

drm_hwcomposer: remove NVIDIA importer

There's no opensource implementation for the NVIDIA gralloc implementation,
so remove it as it is not testable.

As all of the gralloc perform() operations are specific to it, they can be
removed, too.

Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Robert Foss <robert.foss@collabora.com>

platformdrmgeneric: get the gralloc usage directly from the handle

There's no point in using a gralloc perform() op to retrieve the usage as
it is already stored in the handle like width, height, format, etc. So just
copy it to the hwc_drm_bo_t and get it directly.

Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Robert Foss <robert.foss@collabora.com>
Tested-by: Robert Foss <robert.foss@collabora.com>

drm_hwcomposer: use upstream DRM_MODE_{ROTATE, REFLECT} defines

The DRM_REFLECT_* and DRM_ROTATE_* defines were not upstream, but now
they are. Convert to using the upstream version which are defined as a
bit mask rather than a bit position.

Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Robert Foss <robert.foss@collabora.com>

drm_hwcomposer: Remove threading

Since HWC2 doesn't require the use of threads to implement correct
synchronization, remove some of these threads.

Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Robert Foss <robert.foss@collabora.com>

drm_hwcomposer: Add out-fence support

Add support for out-fences through the OUT_FENCE_PTR property.
Out-fences signal when their associated buffer may be read by a device.

Signed-off-by: Robert Foss <robert.foss@collabora.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>

drm_hwcomposer: Add crtc() fetcher to DrmResources

This is a fetcher for getting the vector of DrmCrtc objects
in DrmResources.

Signed-off-by: Robert Foss <robert.foss@collabora.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>

drm_hwcomposer: Add FENCE_OUT_PTR property to DrmCrtc

Add support for handling the FENCE_OUT_PTR property to DrmCrtc

Signed-off-by: Robert Foss <robert.foss@collabora.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>

drm_hwcomposer: Submit in-fence to DRM

Add support for in-fences through the IN_FENCE_FD property. In-fences signal
when their associated buffer may be read by DRM/KMS.

Signed-off-by: Robert Foss <robert.foss@collabora.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>

drm_hwcomposer: Add support for IN_FENCE_FD property to DrmPlane

Add support for the IN_FENCE_FD property to DrmPlane.

Signed-off-by: Robert Foss <robert.foss@collabora.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>

drm_hwcomposer: move library to /vendor

As part of Treble project in Android O, all the device specific files have
to be located in a separate vendor partition. This is done by setting
LOCAL_PROPRIETARY_MODULE (the name is misleading). This change will not
break existing platforms without a vendor partition as it will just move
files to /system/vendor.

Signed-off-by: Rob Herring <robh@kernel.org>

drm_hwcomposer: Add CONTRIBUTING file

Some basic guidelines for contributions could come in handy.

These are copied from IGT and modified to be suitable.

Signed-off-by: Robert Foss <robert.foss@collabora.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>

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.

Signed-off-by: Adrian Salido <salidoa@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>

drm_hwcomposer: Remove OWNERS

Where we're going, we don't need no stickin' OWNERS.

Now that drm_hwcomposer is hosted on fdo, we're going to support the
de-centralised committer model.

Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Robert Foss <robert.foss@collabora.com>

drm_hwcomposer: fix typo in formats switch statement

Change-Id: I71e116fff098860a2aecf587298e7696d4bef012

drm_hwcomposer: enumerate additional formats for tegra downscale limits

There are additional formats that can be provided and are not handled.

Bug: 36731060
Change-Id: I9f1356762df71e38402ad01f96a650adf2a3cbdc
Signed-off-by: Adrian Salido <salidoa@google.com>

drm_hwcomposer: skip layers with non-premult blending

Tegra driver assumes that all layers with alpha component have premult
alpha. This can cause issues if blending is different since the alpha
component is supposed to be ignored in that case.

Fixes: 62401826
Test: share location in hangouts and drag around map

Change-Id: Iff870697f7efbf5d075a5925d63a8f0f672ee725
Signed-off-by: Adrian Salido <salidoa@google.com>

drm_hwcomposer: add checks for tegra hardware limitation

Current approach is to allow atomic_check figure out any issues with
composition strategy and fallback to squash if there the atomic_check
fails. This leads to issues when there's a protected content as it
cannot be handled in squash.

Adding a new provisioning stage to check for hardware limitations and
address them early so a proper fall back can be in place.

Bug: 36731060
Change-Id: I6482953044bcea9c9a655f28672927b32ac57097

drm_hwcomposer: Add Marissa and remove Haixia

Adding Marissa to OWNERS to get her listed on reviews.

While I'm in here, remove Haixia from OWNERS.

Change-Id: I6e07a686796c1d0cf3539be9bbdfc2b46dfb9938
Signed-off-by: Sean Paul <seanpaul@chromium.org>

Merge "drm_hwcomposer: Add support for GetColorModes & SetCursorPosition"

drm_hwcomposer: avoid potential race condition between worker init and exit

Protect worker initialization and exit with lock in case Exit is called
in different thread.

Change-Id: Ibddfce192deeea9d33575de8abf859fdca5f74ed
Signed-off-by: Adrian Salido <salidoa@google.com>

drm_hwcomposer: refactor Worker

Make use of standard library mutex and conditions which simplifies use
of condition variables and benefits from things like scoped locking.

Also add tests to make sure it runs as expected.

Change-Id: Iaf92e17e1f6757dce490eddee61f84cb1f953b0c

drm_hwcomposer: Add support for GetColorModes & SetCursorPosition

For now we just return HAL_COLOR_MODE_NATIVE and store cursor
position.

BUG=None.
TEST=None.

Change-Id: Id6a7e157dbd9fc41fc53c0e33a6eb523632b9b7a
Signed-off-by: Kalyan Kondapally <kalyan.kondapally@intel.com>

drm_hwcomposer: Partially implement HWC2 API

Implement the HWC2 API for drm_hwcomposer. There are still
a few TODOs sprinkled around, the biggest of which is virtual
display support.

Signed-off-by: Sean Paul <seanpaul@chromium.org>
Change-Id: Ib3d48dabce1941b341d5a966d767baab8db1db10
Signed-off-by: Robert Foss <robert.foss@collabora.com>

drm_hwcomposer: Initial stub HWC2

This patch adds the HWC2 interface to drm_hwc, and stubs out all
functionality.

Change-Id: I65b09e7266e887dd184c0c345016d5a768f6349a
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Robert Foss <robert.foss@collabora.com>

drm_hwcomposer: Move eglCreateImageKHR into Importer

Since NV has a "special" nonstandard way to get an EGLImage from a
handle, move this into Importer where the other NV specialness is
abstracted.  For the platformdrmgeneric case, use the dmabuf EGL
Extension.

Change-Id: I5353f4c95f55174df55ba92931cdc9a9eab80dca
Signed-off-by: Robert Foss <robert.foss@collabora.com>

Merge "drm_hwcomposer: Move some utilities out of hwcomposer.cpp"

Merge "drm_hwcomposer: Remove source_damage from DrmHwcLayer"

Merge "drm_hwcomposer: Break out of sync_wait loop on success"

Merge "drm_hwcomposer: Harvest min/max resolutions from drm"

Merge "drm_hwcomposer: Don't pass hwc_procs_t to VsyncWorker"

Merge "drm_hwcomposer: Clean up error conditions"

drm_hwcomposer: fix pre comp regions during protected playback

During protected video playback an issue could happen when there are layers
below the protected video surface. The current logic in protected plane
provisioning logic includes all layers below the protected layer in precomp
plane in order to draw holes in these. However, when there are other layers in
place, in particular one that has blending (ex. PREMULT). For example:

Layers: count=3
  [0] blending[a=255]=NONE display_frame[x/y/w/h]=0/125/2560/1438
  [1] protected blending[a=255]=NONE display_frame[x/y/w/h]=0/181/2560/1438
  [2] blending[a=255]=PREMULT display_frame[x/y/w/h]=0/0/2560/1800
Planes: count=3
  [0] plane=17 type=LAYER source_layer=1
  [1] plane=22 type=LAYER source_layer=2
  [2] plane=23 type=PRECOMP source_layer=0
Squash Regions: count=0
Pre-Comp Regions: count=0

In this case, layer[0] is below protected surface (layer[1]). This causes
issues because precomp plane is setup to be on the highest z-order all the
time, and any time it isn't it expects any layers with higher z-order will
obscure some contents of the precomp layer. But in this case the layer on top
(layer[2]) has blending enabled (PREMULT) and is transparent so expectation is
that layer[0] is also rendered and blended with layer[2].

By merging any layer that is of higher z-order (layer[2] in example) to precomp
plane, all these layers can be handled during pre composition.

Bug: 36879178
Change-Id: I9b63b37fef0ae828c4a781e0d1da264d8a3d7a76

drm_hwcomposer: Use correct DRM event context version

Explicitly declare which DRM event context version we want to use,
rather than just the latest one libdrm supports. New versions may change
semantics, or extend the structure, in ways we're unaware of.

Stick with version 2, which is the version that introduced
page_flip_handler.

Change-Id: I71e33f787b2b724596f8289d95311730f7aff8ff
Signed-off-by: Daniel Stone <daniels@collabora.com>

drm_hwcomposer: Move some utilities out of hwcomposer.cpp

There are some utility functions in hwcomposer.cpp that will
be useful for hwc2. Move them into hwcutils.cpp so they can
be used when hwcomposer.cpp is not compiled.

Change-Id: I66a332e3e6afc4dc64217a528db50d5adbe02ef6
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Robert Foss <robert.foss@collabora.com>

drm_hwcomposer: Remove source_damage from DrmHwcLayer

We don't use it, so get rid of it.

Change-Id: I63fc6bd06c0bfd4e7ad8315856e8f2372133624e
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Robert Foss <robert.foss@collabora.com>

drm_hwcomposer: Break out of sync_wait loop on success

Don't call sync_wait kAcquireWaitTries times if it returns successfully.

Change-Id: Iebdc2229966bfce4aaf35a07ef59aef405e301c6
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Robert Foss <robert.foss@collabora.com>

drm_hwcomposer: Harvest min/max resolutions from drm

Store the minimum and maximum resolutions from drm in DrmResources

BUG=None
TEST=None

Change-Id: I21b9a3fc5f220585295733cc754fe0f6df0abae9
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Robert Foss <robert.foss@collabora.com>

drm_hwcomposer: Don't pass hwc_procs_t to VsyncWorker

Introduce a new class to limit the hwc_procs_t callback
structure scope to hwcomposer.cpp

Change-Id: I68ec62e7947ca87702b3d6d0169ae850cfbf5d85
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Robert Foss <robert.foss@collabora.com>

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>