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@xxxxxxxxxx> 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.
--
With best wishes
Dmitry
