On Thu, 9 Feb 2023 15:10:38 +0200 Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > On Thu, Feb 09, 2023 at 01:58:55PM +0200, Pekka Paalanen wrote: > > On Wed, 8 Feb 2023 23:10:16 +0200 > > Ville Syrjala <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > > > > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > > > Add a new immutable plane property by which a plane can advertise > > > a handful of recommended plane sizes. This would be mostly exposed > > > by cursor planes as a slightly more capable replacement for > > > the DRM_CAP_CURSOR_WIDTH/HEIGHT caps, which can only declare > > > a one size fits all limit for the whole device. > > > > > > Currently eg. amdgpu/i915/nouveau just advertize the max cursor > > > size via the cursor size caps. But always using the max sized > > > cursor can waste a surprising amount of power, so a better > > > stragey is desirable. > > > > > > Most other drivers don't specify any cursor size at all, in > > > which case the ioctl code just claims that 64x64 is a great > > > choice. Whether that is actually true is debatable. > > > > > > A poll of various compositor developers informs us that > > > blindly probing with setcursor/atomic ioctl to determine > > > suitable cursor sizes is not acceptable, thus the > > > introduction of the new property to supplant the cursor > > > size caps. The compositor will now be free to select a > > > more optimal cursor size from the short list of options. > > > > > > Note that the reported sizes (either via the property or the > > > caps) make no claims about things such as plane scaling. So > > > these things should only really be consulted for simple > > > "cursor like" use cases. > > > > > > v2: Try to add some docs > > > > > > Cc: Simon Ser <contact@xxxxxxxxxxx> > > > Cc: Jonas Ådahl <jadahl@xxxxxxxxxx> > > > Cc: Daniel Stone <daniel@xxxxxxxxxxxxx> > > > Cc: Pekka Paalanen <pekka.paalanen@xxxxxxxxxxxxx> > > > Acked-by: Harry Wentland <harry.wentland@xxxxxxx> > > > Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > --- > > > drivers/gpu/drm/drm_mode_config.c | 7 +++++ > > > drivers/gpu/drm/drm_plane.c | 48 +++++++++++++++++++++++++++++++ > > > include/drm/drm_mode_config.h | 5 ++++ > > > include/drm/drm_plane.h | 4 +++ > > > include/uapi/drm/drm_mode.h | 11 +++++++ > > > 5 files changed, 75 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c > > > index 87eb591fe9b5..21860f94a18c 100644 > > > --- a/drivers/gpu/drm/drm_mode_config.c > > > +++ b/drivers/gpu/drm/drm_mode_config.c > > > @@ -374,6 +374,13 @@ static int drm_mode_create_standard_properties(struct drm_device *dev) > > > return -ENOMEM; > > > dev->mode_config.modifiers_property = prop; > > > > > > + prop = drm_property_create(dev, > > > + DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB, > > > + "SIZE_HINTS", 0); > > > + if (!prop) > > > + return -ENOMEM; > > > + dev->mode_config.size_hints_property = prop; > > > + > > > return 0; > > > } > > > > > > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c > > > index 24e7998d1731..ae51b1f83755 100644 > > > --- a/drivers/gpu/drm/drm_plane.c > > > +++ b/drivers/gpu/drm/drm_plane.c > > > @@ -140,6 +140,21 @@ > > > * DRM_FORMAT_MOD_LINEAR. Before linux kernel release v5.1 there have been > > > * various bugs in this area with inconsistencies between the capability > > > * flag and per-plane properties. > > > + * > > > + * SIZE_HINTS: > > > + * Blob property which contains the set of recommended plane size > > > + * which can used for simple "cursor like" use cases (eg. no scaling). > > > + * Using these hints frees userspace from extensive probing of > > > + * supported plane sizes through atomic/setcursor ioctls. > > > + * > > > + * For optimal usage userspace should pick the smallest size > > > + * that satisfies its own requirements. > > > + * > > > + * The blob contains an array of struct drm_plane_size_hint. > > > + * > > > + * Drivers should only attach this property to planes that > > > + * support a very limited set of sizes (eg. cursor planes > > > + * on typical hardware). > > > > Hi Ville, > > > > sounds good. Maybe a minor nit about "typical hardware". Would e.g. > > "legacy PC hardware" be more accurate? > > "legacy" doesn't feel quite right for current and upcoming hardware. It's an example, not everything. Although, I didn't expect current and upcoming hardware to keep such limitations either but to move towards universal rather than specialized planes. Maybe just drop the whole "(eg. ...)"? Thanks, pq
Attachment:
pgpFB5HfpyuMM.pgp
Description: OpenPGP digital signature
