On 11/11/2022 1:45 AM, Daniel Vetter wrote:
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@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.
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.
AFAIK surfaceflinger allows apps to use this for cases beyond just
background fill -- an app, for example, can pass the hint for a plane
that only partially covers a screen and the driver would be expected to
fill just that ROI.
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.
FWIW, Simon mentioned in a separate reply that Wayland supports a 1x1 FB
support protocol [1] for a similar purpose as this RFC series. I can
also create an IGT test meanwhile showing an example of E2E usage.
Thanks,
Jessica
[1]
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/104
-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
