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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 31 Jul 2024 at 11:48, Murthy, Arun R <arun.r.murthy@xxxxxxxxx> wrote:
>
> > -----Original Message-----
> > From: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx>
> > Sent: Wednesday, July 31, 2024 2:04 PM
> > To: Murthy, Arun R <arun.r.murthy@xxxxxxxxx>
> > Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx; intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> > 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@xxxxxxxxx>
> > wrote:
> > >
> > > > -----Original Message-----
> > > > From: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx>
> > > > Sent: Tuesday, July 30, 2024 4:21 AM
> > > > To: Murthy, Arun R <arun.r.murthy@xxxxxxxxx>
> > > > Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx; intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> > > > 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




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux