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