On Mon, Nov 7, 2022 at 1:32 PM Jessica Zhang <quic_jesszhan@xxxxxxxxxxx> wrote:
>
>
>
> On 11/7/2022 11:37 AM, Ville Syrjälä wrote:
> > On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zhang wrote:
> >> Introduce and add support for COLOR_FILL and COLOR_FILL_FORMAT
> >> properties. When the color fill value is set, and the framebuffer is set
> >> to NULL, memory fetch will be disabled.
> >
> > Thinking a bit more universally I wonder if there should be
> > some kind of enum property:
> >
> > enum plane_pixel_source {
> > FB,
> > COLOR,
> > LIVE_FOO,
> > LIVE_BAR,
> > ...
> > }
>
> Hi Ville,
>
> Makes sense -- this way, we'd also lay some groundwork for cases where
> drivers want to use other non-FB sources.
>
> >
> >> In addition, loosen the NULL FB checks within the atomic commit callstack
> >> to allow a NULL FB when color_fill is nonzero and add FB checks in
> >> methods where the FB was previously assumed to be non-NULL.
> >>
> >> Finally, have the DPU driver use drm_plane_state.color_fill and
> >> drm_plane_state.color_fill_format instead of dpu_plane_state.color_fill,
> >> and add extra checks in the DPU atomic commit callstack to account for a
> >> NULL FB in cases where color_fill is set.
> >>
> >> Some drivers support hardware that have optimizations for solid fill
> >> planes. This series aims to expose these capabilities to userspace as
> >> some compositors have a solid fill flag (ex. SOLID_COLOR in the Android
> >> hardware composer HAL) that can be set by apps like the Android Gears
> >> app.
> >>
> >> Userspace can set the color_fill value by setting COLOR_FILL_FORMAT to a
> >> DRM format, setting COLOR_FILL to a color fill value, and setting the
> >> framebuffer to NULL.
> >
> > Is there some real reason for the format property? Ie. why not
> > just do what was the plan for the crttc background color and
> > specify the color in full 16bpc format and just pick as many
> > msbs from that as the hw can use?
>
> The format property was added because we can't assume that all hardware
> will support/use the same color format for solid fill planes. Even for
> just MSM devices, the hardware supports different variations of RGB
> formats [1].
Sure, but the driver can convert the format into whatever the hw
wants. A 1x1 color conversion is not going to be problematic ;-)
BR,
-R
> Thanks,
>
> Jessica Zhang
>
> [1]
> https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c#L697
>
> >
> >>
> >> Jessica Zhang (3):
> >> drm: Introduce color fill properties for drm plane
> >> drm: Adjust atomic checks for solid fill color
> >> drm/msm/dpu: Use color_fill property for DPU planes
> >>
> >> drivers/gpu/drm/drm_atomic.c | 68 ++++++++++++-----------
> >> drivers/gpu/drm/drm_atomic_helper.c | 34 +++++++-----
> >> drivers/gpu/drm/drm_atomic_uapi.c | 8 +++
> >> drivers/gpu/drm/drm_blend.c | 38 +++++++++++++
> >> drivers/gpu/drm/drm_plane.c | 8 +--
> >> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 7 ++-
> >> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 66 ++++++++++++++--------
> >> include/drm/drm_atomic_helper.h | 5 +-
> >> include/drm/drm_blend.h | 2 +
> >> include/drm/drm_plane.h | 28 ++++++++++
> >> 10 files changed, 188 insertions(+), 76 deletions(-)
> >>
> >> --
> >> 2.38.0
> >
> > --
> > Ville Syrjälä
> > Intel
