On Tue, Apr 24, 2018 at 3:34 AM, Stefan Schake <stschake@xxxxxxxxx> wrote:
> On Tue, Apr 24, 2018 at 10:09 AM, Alexandru-Cosmin Gheorghe
> <Alexandru-Cosmin.Gheorghe@xxxxxxx> wrote:
>> On Mon, Apr 23, 2018 at 05:06:44PM -0700, John Stultz wrote:
>>> @@ -695,6 +704,15 @@ HWC2::Error DrmHwcTwo::HwcDisplay::ValidateDisplay(uint32_t *num_types,
>>> layer.set_validated_type(HWC2::Composition::Client);
>>> ++*num_types;
>>> break;
>>> + case HWC2::Composition::Device:
>>> + if (!compositor_.uses_GL() && !avail_planes) {
>>
>> Something is not entirely correct here, you can't assume just because
>> you have planes available they can be used.
>> E.g Layer has rotation, but the plane doesn't support it.
>> This part is handled by the planning part in presentDisplay which
>> falls back on GPU.
Ah. Thanks for the correction here!
This is part of the disconnect I have been having with the
drm_hwcomposer logic. The plan/validate step doesn't really do either,
instead it defers all the checking/planning to the set/present step.
But unfortunately it seems if we want to use the surfaceflinger gl
composer, we need to mark the layers as client rendered in the
validate function.
>> I think the easiest and safe way is to just fallback to
>> Composition::Client whenever the GLCompositor failed to initialize.
>>
>
> I agree, this would only work out for the single plane case where you end
> up using client composition for everything.
True, but maybe as a first step we simply fall back on the
glcompositor, just so we have something displaying in that case (right
now nothing gets displayed).
> In the spirit of DRM what we would probably want is to atomic test a
> composition, and if that fails we can still fallback to client or GL
> compositor depending on its availability. And then in a far far away
> future we might even do a few iterations simplifying our composition until
> it atomic tests correctly so we can still offload some "simple" parts
> like the cursor.
This sounds reasonable. I suspect it will take some heavier rework of
the drm_hwcomposer to move such logic to the validate step.
Marissa/Sean: Any objections here? Doing more planning in the validate
step sounds like it aligns closer to the HWC2 interface goals, but I
don't want to have to relearn-the-hard-way any lessons that resulted
in the current mode of accept it all and sort it in present.
In the meantime I'll drop the flawed plane/layer allocation from this
patch and resend.
thanks
-john
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
