From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 10D97C433DF for ; Fri, 7 Aug 2020 13:06:44 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D9151221E2 for ; Fri, 7 Aug 2020 13:06:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="S1+fV7EB" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D9151221E2 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 5CA6E6E126; Fri, 7 Aug 2020 13:06:43 +0000 (UTC) Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2BABA6E126 for ; Fri, 7 Aug 2020 13:06:42 +0000 (UTC) Received: by mail-wr1-x443.google.com with SMTP id y3so1623208wrl.4 for ; Fri, 07 Aug 2020 06:06:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=j8M8x6OwnaxmfcKbmGaUp2UjGTHEUKREthEAoBKePPU=; b=S1+fV7EBUeuuNcvqZf4hc+Saw/mwtBty+p4fo1/qoOikpRpu+zZD5CwtOdat7tDIvA R6Qc+mApXEFCyVYdXVpPBW/t6bDatcqblH6t6qRTA1e5X9kr0oBllpwSCyypCO/ICvCf UtPGBRUb3kj7VvEfIjaM8E29TXYJtMfsPY/y8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=j8M8x6OwnaxmfcKbmGaUp2UjGTHEUKREthEAoBKePPU=; b=nYwuy0ntGzwstx6RDABsAUG7i6MBXhcum3AAszgFFyvFxG07gBiihMJf917HvZJx+2 bHnOyV6yK44/jOJqwzksWJCMnmWVKzxuFtdTvZEMBhx0/dArl7qsmuCINSG0muY1adEw fbBsQCI8o0UEOoRyvNLBg8NGPednJeR+YkeMIDTajoIx3DinyCdcRxetzC1b4j3j7aYM 8Lv8TfGybzmNdsA5oI4OycKUj8OTfB+eo6V7kRxqzpVQygYRCMb7yedYmeqNQH/rQBwx gbRFu3b5e52Gnz7GlE1twsQ+3yecicjTymamHHZ/j3MHGjl/LxabJURhajXFm2fRDnun jziA== X-Gm-Message-State: AOAM533c9AZE6dAh+3h1INdjg1CUGFgJaXICcezQz21iGX4CndHQUVn+ WQDY3NE8dzANQLj9/bLPMs2+5w== X-Google-Smtp-Source: ABdhPJz4U0SFMKbuRetEQEZzDCRUPNGX4AS0HvGB5qXE08aSw3VbH+TXGrTMaRoGSJlbrHwwkJhR0Q== X-Received: by 2002:adf:f207:: with SMTP id p7mr12860387wro.292.1596805600727; Fri, 07 Aug 2020 06:06:40 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id y17sm11063196wrh.63.2020.08.07.06.06.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Aug 2020 06:06:38 -0700 (PDT) Date: Fri, 7 Aug 2020 15:06:36 +0200 From: Daniel Vetter To: Pekka Paalanen Subject: Re: [PATCH] drm: drivers may provide multiple primary planes per CRTC Message-ID: <20200807130636.GD2352366@phenom.ffwll.local> References: <20200807090706.GA2352366@phenom.ffwll.local> <20200807123802.6058baca@eldfell> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200807123802.6058baca@eldfell> X-Operating-System: Linux phenom 5.7.0-1-amd64 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: dri-devel@lists.freedesktop.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, Aug 07, 2020 at 12:38:02PM +0300, Pekka Paalanen wrote: > On Fri, 7 Aug 2020 11:07:06 +0200 > Daniel Vetter wrote: > > > On Thu, Aug 06, 2020 at 10:33:31AM +0000, Simon Ser wrote: > > > Some drivers may expose primary planes compatible with multiple CRTCs. > > > Make this clear in the docs: the current wording may be misunderstood as > > > "exactly one primary plane per CRTC". > > > > > > Signed-off-by: Simon Ser > > > Cc: Daniel Vetter > > > --- > > > drivers/gpu/drm/drm_plane.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c > > > index b7b90b3a2e38..108a922e8c23 100644 > > > --- a/drivers/gpu/drm/drm_plane.c > > > +++ b/drivers/gpu/drm/drm_plane.c > > > @@ -49,8 +49,8 @@ > > > * &struct drm_plane (possibly as part of a larger structure) and registers it > > > * with a call to drm_universal_plane_init(). > > > * > > > - * Cursor and overlay planes are optional. All drivers should provide one > > > - * primary plane per CRTC to avoid surprising userspace too much. See enum > > > + * Cursor and overlay planes are optional. All drivers should provide at least > > > + * one primary plane per CRTC to avoid surprising userspace too much. See enum > > > > I think that's even more confusing, since this reads like there could be > > multiple primary planes for a specific CRTC. That's not the case, there' > > only one pointer going from drm_crtc->primary to a drm_plane in the > > kernel. > > There could be multiple primary planes *usable* for a specific CRTC but > just one used at a time, right? I'm not sure what you mean here, the crtc->primary link is invariant over the lifetime of a driver load. You can't pick a different one, that's set at driver init before drm_dev_register (and hence before userspace ever sees anything). > > The problem is that userspace doesn't have a drm_property to read this > > pointer, and needs to guess. > > > > I thought the rule is: > > > > Nth primary plane (or cursor) is the primary plane for the Nth crtc. > > Enumaration with increasing drm kms object ids. > > Why is that needed? With universal planes, I thought > drmModePlane::possible_crtcs bitmask is trustworthy? Yes it should be. > In the legacy KMS UAPI you can't even pick your primary plane, because > it's implied in drmModeSetCrtc(), right? Yup, I thought this all was so userspace knows which plane is the implied one for legacy ioctls. Which does somewhat matter, since page_flip ioctl has more features than atomic (target frame and async mode). > > And I guess we should explain that on some hw any plane (including primary > > ones, since that's only a sw construct) can be freely assinged to crtc. > > > > Yes it's probably the most gloriously bonkers uapi we've come up with. > > Might be so bad that a libdrm helper to look up the primary plane for a > > crtc (or it's cursor plane if it exists) would be in order :-) > > I'm not sure I see the bonkers there. Userspace has to guess which primary plane is for which crtc, at least if the possible_crtc mask has more than one bit set. Which can happen. -Daniel > > > Thanks, > pq > > > > > Cheers, Daniel > > > > > > > * drm_plane_type for a more in-depth discussion of these special uapi-relevant > > > * plane types. Special planes are associated with their CRTC by calling > > > * drm_crtc_init_with_planes(). > > > -- > > > 2.28.0 > > > > > > > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel