[Freedreno] [RFC PATCH 1/3] drm: Introduce color fill properties for drm plane

[Daniel Vetter]

On Wed, Nov 09, 2022 at 05:44:37PM -0800, Jessica Zhang wrote:
> 
> 
> On 11/9/2022 5:59 AM, Daniel Vetter wrote:
> > On Wed, Nov 09, 2022 at 04:53:45PM +0300, Dmitry Baryshkov wrote:
> > > On 09/11/2022 16:52, Daniel Vetter wrote:
> > > > On Tue, Nov 08, 2022 at 06:25:29PM +0000, Simon Ser wrote:
> > > > > On Saturday, October 29th, 2022 at 13:23, Dmitry Baryshkov <dmitry.baryshkov at linaro.org> wrote:
> > > > > 
> > > > > > On 29/10/2022 01:59, Jessica Zhang wrote:
> > > > > > 
> > > > > > > Add support for COLOR_FILL and COLOR_FILL_FORMAT properties for
> > > > > > > drm_plane. In addition, add support for setting and getting the values
> > > > > > > of these properties.
> > > > > > > 
> > > > > > > COLOR_FILL represents the color fill of a plane while COLOR_FILL_FORMAT
> > > > > > > represents the format of the color fill. Userspace can set enable solid
> > > > > > > fill on a plane by assigning COLOR_FILL to a uint64_t value, assigning
> > > > > > > the COLOR_FILL_FORMAT property to a uint32_t value, and setting the
> > > > > > > framebuffer to NULL.
> > > > > > 
> > > > > > I suppose that COLOR_FILL should override framebuffer rather than
> > > > > > requiring that FB is set to NULL. In other words, if color_filL_format
> > > > > > is non-zero, it would make sense to ignore the FB. Then one can use the
> > > > > > color_fill_format property to quickly switch between filled plane and
> > > > > > FB-backed one.
> > > > > 
> > > > > That would be inconsistent with the rest of the KMS uAPI. For instance,
> > > > > the kernel will error out if CRTC has active=0 but a connector is still
> > > > > linked to the CRTC. IOW, the current uAPI errors out if the KMS state
> > > > > is inconsistent.
> > > > 
> > > > So if the use-case here really is to solid-fill a plane (and not just
> > > > provide a background color for the crtc overall), then I guess we could
> > > > also extend addfb to make that happen. We've talked in the past about
> > > > propertery-fying framebuffer objects, and that would sort out this uapi
> > > > wart. And I agree the color fill vs PLANE_ID issue is a bit ugly at least.
> > > > 
> > > > But if the use-cases are all background color then just doing the crtc
> > > > background color would be tons simpler (and likely also easier to support
> > > > for more hardware).
> > > 
> > > No. The hardware supports multiple color-filled planes, which do not have to
> > > cover the whole CRTC.
> > 
> > The use case here means the userspace use-case. What the hw can do on any
> > given chip kinda doesnt matter, which is why I'm asking. KMD uapi is not
> > meant to reflect 100% exactly what a specific chip can do, but instead:
> > - provide features userspace actually needs. If you want per-plane fill,
> >    you need userspace that makes use of per-plane fill, and if all you have
> >    is crtc background, then that's it.
> 
> Hey Daniel,
> 
> The userspace use case we're trying to support is the Android HWC SOLID_FILL
> hint here [1], which is specifying per-plane fill.

Does surfaceflinger actually use this for more than background fills? Yes
I'm annoying, but if we can simplify the kernel driver implementation
burden by asking compositors to do the math and simplify things, then I
think we should.

We also need an open source implementation for this that works and is
tested end-to-end. There's the drm_hwc project, but last time I've checked
there's really not much happpening there unfortunately.
-Daniel

> 
> Thanks,
> 
> Jessica Zhang
> 
> [1] https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/master/graphics/composer/aidl/android/hardware/graphics/composer3/Composition.aidl#52
> 
> > - we should create uapi with an eye towards what's actually possible on a
> >    reasonable set of drivers and hw. Sometimes that means a slightly more
> >    restricted set so that it's possible to implement in more places,
> >    especially if that restricted feature set still gets the job done for
> >    userspace.
> > 
> > Cheers, Daniel
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch