Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 08 Aug 2023 04:07:36 +0300
From:   Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
To:     Jessica Zhang <quic_jesszhan@quicinc.com>
CC:     Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
        Maxime Ripard <mripard@kernel.org>,
        Thomas Zimmermann <tzimmermann@suse.de>,
        David Airlie <airlied@gmail.com>,
        Daniel Vetter <daniel@ffwll.ch>,
        Rob Clark <robdclark@gmail.com>, Sean Paul <sean@poorly.run>,
        Marijn Suijten <marijn.suijten@somainline.org>,
        quic_abhinavk@quicinc.com, ppaalanen@gmail.com,
        contact@emersion.fr, laurent.pinchart@ideasonboard.com,
        sebastian.wick@redhat.com, ville.syrjala@linux.intel.com,
        dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
        linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org,
        wayland-devel@lists.freedesktop.org
Subject: Re: [PATCH RFC v5 02/10] drm: Introduce solid fill DRM plane property
User-Agent: K-9 Mail for Android
In-Reply-To: <26b4bb91-8786-c7cf-a821-eb2b881a42ab@quicinc.com>
References: <20230728-solid-fill-v5-0-053dbefa909c@quicinc.com> <20230728-solid-fill-v5-2-053dbefa909c@quicinc.com> <CAA8EJpq=pbDoYc9wqKKrX+RahXp8zWTPFqVqA=S-0TkWXXJUjQ@mail.gmail.com> <26b4bb91-8786-c7cf-a821-eb2b881a42ab@quicinc.com>
Message-ID: <656526F6-C123-4A5A-9E62-6ED092474113@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk


On 8 August 2023 00:41:07 GMT+03:00, Jessica Zhang <quic_jesszhan@quicinc=
=2Ecom> wrote:
>
>
>On 8/4/2023 6:27 AM, Dmitry Baryshkov wrote:
>> On Fri, 28 Jul 2023 at 20:03, Jessica Zhang <quic_jesszhan@quicinc=2Eco=
m> wrote:
>>>=20
>>> Document and add support for solid_fill property to drm_plane=2E In
>>> addition, add support for setting and getting the values for solid_fil=
l=2E
>>>=20
>>> To enable solid fill planes, userspace must assign a property blob to
>>> the "solid_fill" plane property containing the following information:
>>>=20
>>> struct drm_mode_solid_fill {
>>>          u32 version;
>>>          u32 r, g, b;
>>> };
>>>=20
>>> Signed-off-by: Jessica Zhang <quic_jesszhan@quicinc=2Ecom>
>>> ---
>>>   drivers/gpu/drm/drm_atomic_state_helper=2Ec |  9 +++++
>>>   drivers/gpu/drm/drm_atomic_uapi=2Ec         | 55 +++++++++++++++++++=
++++++++++++
>>>   drivers/gpu/drm/drm_blend=2Ec               | 30 +++++++++++++++++
>>>   include/drm/drm_blend=2Eh                   |  1 +
>>>   include/drm/drm_plane=2Eh                   | 35 +++++++++++++++++++=
+
>>>   include/uapi/drm/drm_mode=2Eh               | 24 ++++++++++++++
>>>   6 files changed, 154 insertions(+)
>>>=20
>>=20
>> [skipped most of the patch]
>>=20
>>> diff --git a/include/uapi/drm/drm_mode=2Eh b/include/uapi/drm/drm_mode=
=2Eh
>>> index 43691058d28f=2E=2E53c8efa5ad7f 100644
>>> --- a/include/uapi/drm/drm_mode=2Eh
>>> +++ b/include/uapi/drm/drm_mode=2Eh
>>> @@ -259,6 +259,30 @@ struct drm_mode_modeinfo {
>>>          char name[DRM_DISPLAY_MODE_LEN];
>>>   };
>>>=20
>>> +/**
>>> + * struct drm_mode_solid_fill - User info for solid fill planes
>>> + *
>>> + * This is the userspace API solid fill information structure=2E
>>> + *
>>> + * Userspace can enable solid fill planes by assigning the plane "sol=
id_fill"
>>> + * property to a blob containing a single drm_mode_solid_fill struct =
populated with an RGB323232
>>> + * color and setting the pixel source to "SOLID_FILL"=2E
>>> + *
>>> + * For information on the plane property, see drm_plane_create_solid_=
fill_property()
>>> + *
>>> + * @version: Version of the blob=2E Currently, there is only support =
for version =3D=3D 1
>>> + * @r: Red color value of single pixel
>>> + * @g: Green color value of single pixel
>>> + * @b: Blue color value of single pixel
>>> + */
>>> +struct drm_mode_solid_fill {
>>> +       __u32 version;
>>> +       __u32 r;
>>> +       __u32 g;
>>> +       __u32 b;
>>=20
>> Another thought about the drm_mode_solid_fill uABI=2E I still think we
>> should add alpha here=2E The reason is the following:
>>=20
>> It is true that we have  drm_plane_state::alpha and the plane's
>> "alpha" property=2E However it is documented as "the plane-wide opacity
>> [=2E=2E=2E] It can be combined with pixel alpha=2E The pixel values in =
the
>> framebuffers are expected to not be pre-multiplied by the global alpha
>> associated to the plane=2E"=2E
>>=20
>> I can imagine a use case, when a user might want to enable plane-wide
>> opacity, set "pixel blend mode" to "Coverage" and then switch between
>> partially opaque framebuffer and partially opaque solid-fill without
>> touching the plane's alpha value=2E
>
>Hi Dmitry,
>
>I don't really agree that adding a solid fill alpha would be a good idea=
=2E Since the intent behind solid fill is to have a single color for the en=
tire plane, I think it makes more sense to have solid fill rely on the glob=
al plane alpha=2E
>
>As stated in earlier discussions, I think having both a solid_fill=2Ealph=
a and a plane_state=2Ealpha would be redundant and serve to confuse the use=
r as to which one to set=2E

That depends on the blending mode: in Coverage mode one has independent pl=
ane and contents alpha values=2E And I consider alpha value to be a part of=
 the colour in the rgba/bgra modes=2E


>
>Thanks,
>
>Jessica Zhang
>
>>=20
>> --=20
>> With best wishes
>> Dmitry

--=20
With best wishes
Dmitry