Age | Commit message (Collapse) | Author |
|
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>
|
|
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>
|
|
This reverts commit 3b0c69d3477d3601b1dbcb75fdd748254e297e7e.
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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
|
|
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>
|
|
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>
|
|
SquashFrame previously didn't run if there was only one overlay
layer in the layer stack. This would cause false failures when
the incoming composition was composed of one or more layers with
a precomposition or squash layer.
To fix this, count all layers which are not disabled, and only
skip squashing if there is just one content layer.
BUG=b/29122961
TEST=Tested on smaug with vertical multi-window YouTube
Change-Id: Icb175b7701928136730442a39c4717a780d34cfd
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
If we drop a frame while compositing, free the active composition.
Assume a frame pipeline of A->B->A. If we drop frame B, it will become
the active composition, which means the fences for A will not be released,
causing us to block A on A --> DEADLOCK.
BUG=b/29122961
TEST=Tested on smaug, no longer hangs
Change-Id: I98817bb361f1d0669395ddac5d96cf4f19d4b26a
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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>
|
|
BUG=None
TEST=Compiles
Change-Id: Ie95aad60b225784c36d411ec16a34ff32ea8acc6
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
BUG=None
TEST=Compiles
Change-Id: I8a003dc14828ed0c10fd161b00d1bc1c5069431f
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
drm_hwcomposer is currently using preliminary version of the atomic API.
The final version merged upstream is slightly different. Convert it to the
upstream API.
The most significant change is positive return values for
drmModeAtomicAddProperty are not a failure, so we need to test for
negative return values instead of non-zero.
BUG=none
TEST=Tested with 4.4 kernel on virtio-gpu and freedreno
Change-Id: I0b1f4bcd7766a3053a484f55e01c8b2ba56d716d
Signed-off-by: Rob Herring <robh@kernel.org>
|
|
Increase the fence wait value each time by a factor of 2.
Bug: chrome-os-partner:48289
Test: Run apps and see no frame drops
Change-Id: I9b7b910e5a8c9d287ea69b13dca0d4c1194ac86c
Signed-off-by: David Ung <davidu@nvidia.com>
|
|
Previously this was not called for compositions which were known to
fail the atomic test. Unfortunately this left the composition in a
state which could not be processed by SquashFrame (only one layer and
source_layer was still set to kSourceSquash).
So call PrepareFrame() on every composition so SquashFrame stays happy.
Change-Id: I976e344ce4970370d9ca4307c2f2c45025199b64
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
Previously, we would only test the first frame when the geometry
changed. However, if SF sent us the same composition with different
FBs, we could end up sending invalid frames to the kernel.
This change saves the result of the atomic_test between geometry
changes so we avoid using hw composition for all invalid frames.
Bug: 25866352
Test: Tested on smaug, observed squashes between geometry changes
Change-Id: I3b5d9e83a870481bf2e6869900eafaf0ca66a0d5
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
Do not check the composition with kernel for every frame. We are currently
using synchronous atomic ioctl calls, so all test-only calls are serialized
with the actual commits.
BUG=25866352
TEST=same test procedure as crosbug.com/p/47206
Change-Id: Ia423243c279fc677ff6213115a8f20efa40c235e
|
|
The correct blending mode for the GL output is actually premult, because
regardless of the original layer blending mode, the result RGB components
are always pre-multiplied with alpha already.
This prevents the result of a SquashAll() from getting multiplied by
alpha twice.
BUG=25838542
TEST=verify the blinking is fixed on the status bar icons
Change-Id: Ie5bbc53110c342576b81818da6069cba201db609
|
|
into mnc-dr-dev
|
|
|
|
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>
|
|
Before we send a composition to the frame worker and display, run it
through the kernel to test whether it can be put on hardware. If the
kernel rejects the composition, use the squashing code to flatten it
on one layer and send the result to the frame worker.
Bug: 25379136
Test: Tested on smaug, frames were squashed, fun was had
Change-Id: Icac3c034d0eb4c0becbdc0f8ace1de75ab8ae2b8
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
Split the SquashAll function into SquashAll and SquashFrame. This
will allow us to squash arbitrary compositions without using the
active composition or applying it to the screen.
Bug: 25379136
Test: Tested on smaug
Change-Id: I1767f731e14f36540151556ce07373848b604030
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
Allow the caller of CommitFrame to run the commit in "test only" mode
which will send the frame to the kernel, but won't actually change any
registers.
Bug: 25379136
Test: Tested on smaug
Change-Id: I831b5f17d433bc60d9f107689feb1d7672c100a9
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
Instead of creating the mode blob right before doing the modeset,
create it as soon as the modeset is queued. This will allow us to
use the blob for both atomic test as well as commit.
In addition to keeping the blob around, store the blob's id while
the mode is active so we don't need to look it up when/if the next
modeset comes in.
Bug: 25379136
Test: Tested on smaug
Change-Id: I60e6f83310ea0601388bb31b63d25c6fd7b8fc4d
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
This complicates returning layers to the active composition on failure. They
will not go back in the correct order and this will confuse all subsequent
attempts to use the active composition.
Change-Id: Iab6fae7b4a88f97206bac08237d574ff1bfd802f
|
|
DrmDisplayCompositor::SquashAll is triggered after a constant timeout in
DrmCompositorWorker::Routine. It will not be triggered more than one time
between genuine hwc_set calls. SquashAll has no effect if there are protected
layers, only one layer, or any errors. On success, SquashAll produces a new
DrmDisplayComposition that owns the layers in the planes of the active
composition and makes that the new active composition. SquashAll has no effect
on SquashState.
Change-Id: I975edb21847dcf2d93245f92a6e53a4e366c6a3b
|
|
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
|
|
It is spelled "separate", not "seperate".
Change-Id: Id92d12aba42989a8a72e4596d425b2a9eea4e5ec
|
|
The DrmDisplayCompositor::CommitFrame() has been moved to a separate
worker thread so it's helpful to add it to systrace.
Change-Id: I82031f56ddc0587266f9a213208134f045f66b9a
|
|
We are currently using synchronous (blocking) atomic modeset calls
which unnecessarily delays GL.
BUG=25126188
TEST=check timestamp of SignalPreCompDone relative to hwc_set
Change-Id: Iba70c1c9591e467c1627516af123a43206da99fd
|
|
Change-Id: Ifd4feaa0de303ddfd519d4415ab31d2a72f26022
|
|
|
|
By a stroke of luck, the fall through case had a break statement.
Change-Id: I29cb1206d114f31ec58a603cd9dcb986764d8344
|