[RFC PATCH 0/3] Support for Solid Fill Planes

[Jessica Zhang]

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].

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