[PATCH] RFC: drm/drm_plane: Expose the plane capability and interoperability

[Dmitry Baryshkov]

On Wed, 31 Jul 2024 at 11:48, Murthy, Arun R <arun.r.murthy at intel.com> wrote:
>
> > -----Original Message-----
> > From: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
> > Sent: Wednesday, July 31, 2024 2:04 PM
> > To: Murthy, Arun R <arun.r.murthy at intel.com>
> > Cc: dri-devel at lists.freedesktop.org; intel-gfx at lists.freedesktop.org
> > Subject: Re: [PATCH] RFC: drm/drm_plane: Expose the plane capability and
> > interoperability
> >
> > On Tue, 30 Jul 2024 at 07:07, Murthy, Arun R <arun.r.murthy at intel.com>
> > wrote:
> > >
> > > > -----Original Message-----
> > > > From: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
> > > > Sent: Tuesday, July 30, 2024 4:21 AM
> > > > To: Murthy, Arun R <arun.r.murthy at intel.com>
> > > > Cc: dri-devel at lists.freedesktop.org; intel-gfx at lists.freedesktop.org
> > > > Subject: Re: [PATCH] RFC: drm/drm_plane: Expose the plane capability
> > > > and interoperability
> >
> > Please fix your email client.
> >
> Sorry for that. Sure will fix it.
>
> > > >
> > > > On Mon, Jul 29, 2024 at 04:59:14AM GMT, Murthy, Arun R wrote:
> > > > > Gentle Reminder!
> > > > > Any comments?
> > > >
> > > > First of all, the format is underdocumented. Second, there is a
> > > > usual requirement for new uAPI: please provide a pointer to IGT
> > > > patch and to the userspace utilising the property.
> > > There are some discussions on using this in UMD.
> > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29618#note_2
> > > 487123
> >
> > It should be a MR rather than "some discussion". And IGT patchset too, please.
> There is no IGT patch yet.
> >
> > Regarding the patch itself. It is completely underdocumented. There is no way
> > for me to understand which of these caps should e.g. be set for the drm/msm
> > planes.
>
> I have explained it in the patch header. There are certain plane restrictions.
> For example, certain pixel formats are not supported in async flip. If this is known to the compositor ahead, then compositor sending a flip with this unsupported formats leads to a flip failure. In order to overcome this if the KMD sends the list of supported pixel formats, compositor can verify for the same and then send the flip request.
> This can be achieved in two options. The options are listed below in the patch header and expected some review comments or suggestion as to which option to use!

It is impossible to understand what your options / capabilities
_actually_ mean. I browsed through the patch and I still don't
understand how to select which options apply to DRM_FORMAT_MOD_QCOM_*

-- 
With best wishes
Dmitry