Received: by 2002:a05:6358:700f:b0:131:369:b2a3 with SMTP id 15csp3658409rwo; Fri, 4 Aug 2023 08:03:12 -0700 (PDT) X-Google-Smtp-Source: AGHT+IF8FtoamlhZahyrj1JgNRBUtA6s6AaPd24lCopj2TLv6T4Ggk4nEqspXkvNBo3FwQGsvkdY X-Received: by 2002:a17:907:2cea:b0:994:1844:c7d1 with SMTP id hz10-20020a1709072cea00b009941844c7d1mr1506217ejc.13.1691161391715; Fri, 04 Aug 2023 08:03:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691161391; cv=none; d=google.com; s=arc-20160816; b=XFrnbuUyijD+E3zIqpAb0cpafBaveA3K6/IVBNv2Ltbt9UpNFO3zxEgSuvlYlMBJeZ dJcfZX99j+40UK8eOMDHUjGhLkEwi8E6VzjD3TQYwS+yC2NbQQoGevTM3kNKP1WOvF4D tgIxdGUgLzVtbPUj2HGlL3hB9Bcww/2Tvc1BzlwgTXrzP9Ei6eoC2cQizJ/D/JSDsKny 6qJrMtjf0nk8oGXkVFo7GD2IheYH0n1r3/vfE9V5/qcp2HvxXCFXBcUYNxrMUOVQSAON 9CwGJ3hFC8a+zUQzB+6gFxadrluIopnVUbpWS2tZXDiDSE6nGeRjSYB5JV4kQG/1OLS0 c0FA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=KHLJDOJiwUWkkuzywwWoYlPRzSI59IdgN9uUprOdvS4=; fh=disKuJONKwRFdalfYapJhlq73i7sioYHn97yZsl7T+Q=; b=eCgujhjtZE5PS3pQMbJMTLYOz+u7OjvGEpwrivCywzeZFnr05fP6RZRvOLOIm1eGvR rtuZNwSc796W/uUq3KDB91WWWFjWEr4MRnkEiN4l2Ya75pj5jBqjBGYdnu1WTlrIOYCF /QCcNXN5Cn5YPBvO+KmFGHaeBytDWJ5SPzZ5D6Ui6xNeaW2o6yTqWjEJnIVCUpIM7uul 0WGmg8w16UwrEX+r/FWBPftzXE2naZ0+90BcTR5BSHmezyndVgjNl1NGEkXkuwz3rZso m7GEiC2bkLHpFugCnbUWfWnVV9s9DP0rt3wl/zLBNtU9rMepOeYbSaj45FkPVcqjK5DQ +VYQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=Z7qvBF+9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h9-20020a17090619c900b0098e78ff1a8fsi1803325ejd.358.2023.08.04.08.02.36; Fri, 04 Aug 2023 08:03:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=Z7qvBF+9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229522AbjHDN2I (ORCPT + 99 others); Fri, 4 Aug 2023 09:28:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38900 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230063AbjHDN1v (ORCPT ); Fri, 4 Aug 2023 09:27:51 -0400 Received: from mail-yw1-x112d.google.com (mail-yw1-x112d.google.com [IPv6:2607:f8b0:4864:20::112d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CBE2C198C for ; Fri, 4 Aug 2023 06:27:27 -0700 (PDT) Received: by mail-yw1-x112d.google.com with SMTP id 00721157ae682-5861116fd74so23098487b3.0 for ; Fri, 04 Aug 2023 06:27:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1691155646; x=1691760446; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KHLJDOJiwUWkkuzywwWoYlPRzSI59IdgN9uUprOdvS4=; b=Z7qvBF+9IToP1e/q3P9hlS+7O0IXRwa0ARz/Io+MFpJjfNDc7FrMMbOotL2DIhd/ap 9ztcUB2AmlIP19tIK6wdNj8Fm76cgX/HdQL2fk32fogcS10I3f8bUbJ8koCBaJEiNSLx poRdXzMtO61sl9mKrxuLijV3ylKjadz3e60/KUWFU2VyAgb5gkuZN5dZZ+3PRoZh1sRr WNv5oCC80xRnmIRszdQxqiDaTbZNvonCFk+0K6E/l7yzyCFaP3y6HM43hUzjAKe/3iby c6PcYLzXLszErwpOXmrBSX7XUFsnOb7FLCsVNQAsomZ3ePfNgdVljv1BcoLZkfHsgN5H kZyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691155646; x=1691760446; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KHLJDOJiwUWkkuzywwWoYlPRzSI59IdgN9uUprOdvS4=; b=cCcIIWkZ9OSJ7+UhyrDzI2/gCtHxlttgw7xMAYn1+sCnOJ+ptL/ITbpIFNHUDSpKnS Bf3PcW2ap6RLuJJw56y2aQBvvhXAhKjNwRWNTo4M49Z3GYljKi3uuHi6SrsE5SLH4HKD KqUkh51npBO6vMDweCub/IuhKSWaxOTbxTNSUbysAVJaWBNO9P06ORcla5CwcUfD/dZM vZSVcI9FgMYtD21IQ5J2bi0BmM7qBHAwo33xdql+1xwpe2cI9dY73DYBTEdQ/ElMGoqo ttX+zbRawvEnNXngepzVTE/drD7gDOLVVgYdVBgiEu3CYDN/J7YQMLggqBJG4v10OWPz iJOw== X-Gm-Message-State: AOJu0YwmQDmG7d96SQ3iS9d3ra6l/tU3zm7aGMwKj7ni2BrAXNDhlcfF Y/zDrQ7mEx5J5+PVQAGWydKmcu4WjqfYlJcUwUKQSw== X-Received: by 2002:a25:ae94:0:b0:d3b:e659:5331 with SMTP id b20-20020a25ae94000000b00d3be6595331mr1539504ybj.58.1691155646088; Fri, 04 Aug 2023 06:27:26 -0700 (PDT) MIME-Version: 1.0 References: <20230728-solid-fill-v5-0-053dbefa909c@quicinc.com> <20230728-solid-fill-v5-2-053dbefa909c@quicinc.com> In-Reply-To: <20230728-solid-fill-v5-2-053dbefa909c@quicinc.com> From: Dmitry Baryshkov Date: Fri, 4 Aug 2023 16:27:15 +0300 Message-ID: Subject: Re: [PATCH RFC v5 02/10] drm: Introduce solid fill DRM plane property To: Jessica Zhang Cc: Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , Rob Clark , Sean Paul , Marijn Suijten , quic_abhinavk@quicinc.com, ppaalanen@gmail.com, contact@emersion.fr, laurent.pinchart@ideasonboard.com, sebastian.wick@redhat.com, ville.syrjala@linux.intel.com, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org, wayland-devel@lists.freedesktop.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 28 Jul 2023 at 20:03, Jessica Zhang wrote: > > Document and add support for solid_fill property to drm_plane. In > addition, add support for setting and getting the values for solid_fill. > > To enable solid fill planes, userspace must assign a property blob to > the "solid_fill" plane property containing the following information: > > struct drm_mode_solid_fill { > u32 version; > u32 r, g, b; > }; > > Signed-off-by: Jessica Zhang > --- > drivers/gpu/drm/drm_atomic_state_helper.c | 9 +++++ > drivers/gpu/drm/drm_atomic_uapi.c | 55 +++++++++++++++++++++++++++++++ > drivers/gpu/drm/drm_blend.c | 30 +++++++++++++++++ > include/drm/drm_blend.h | 1 + > include/drm/drm_plane.h | 35 ++++++++++++++++++++ > include/uapi/drm/drm_mode.h | 24 ++++++++++++++ > 6 files changed, 154 insertions(+) > [skipped most of the patch] > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h > index 43691058d28f..53c8efa5ad7f 100644 > --- a/include/uapi/drm/drm_mode.h > +++ b/include/uapi/drm/drm_mode.h > @@ -259,6 +259,30 @@ struct drm_mode_modeinfo { > char name[DRM_DISPLAY_MODE_LEN]; > }; > > +/** > + * struct drm_mode_solid_fill - User info for solid fill planes > + * > + * This is the userspace API solid fill information structure. > + * > + * Userspace can enable solid fill planes by assigning the plane "solid_fill" > + * property to a blob containing a single drm_mode_solid_fill struct populated with an RGB323232 > + * color and setting the pixel source to "SOLID_FILL". > + * > + * For information on the plane property, see drm_plane_create_solid_fill_property() > + * > + * @version: Version of the blob. Currently, there is only support for version == 1 > + * @r: Red color value of single pixel > + * @g: Green color value of single pixel > + * @b: Blue color value of single pixel > + */ > +struct drm_mode_solid_fill { > + __u32 version; > + __u32 r; > + __u32 g; > + __u32 b; Another thought about the drm_mode_solid_fill uABI. I still think we should add alpha here. The reason is the following: It is true that we have drm_plane_state::alpha and the plane's "alpha" property. However it is documented as "the plane-wide opacity [...] It can be combined with pixel alpha. The pixel values in the framebuffers are expected to not be pre-multiplied by the global alpha associated to the plane.". I can imagine a use case, when a user might want to enable plane-wide opacity, set "pixel blend mode" to "Coverage" and then switch between partially opaque framebuffer and partially opaque solid-fill without touching the plane's alpha value. -- With best wishes Dmitry