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=-4.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no 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 8E15BC2B9F4 for ; Mon, 14 Jun 2021 14:49:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 733C86128B for ; Mon, 14 Jun 2021 14:49:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232869AbhFNOvh (ORCPT ); Mon, 14 Jun 2021 10:51:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60702 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233110AbhFNOve (ORCPT ); Mon, 14 Jun 2021 10:51:34 -0400 Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AEC8CC061574 for ; Mon, 14 Jun 2021 07:49:19 -0700 (PDT) Received: by mail-lf1-x142.google.com with SMTP id v22so21598719lfa.3 for ; Mon, 14 Jun 2021 07:49:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version; bh=Y92uEa6Ng6L8nssFn3ifSjrubFH60zO3GKp2+iBw/qQ=; b=GY4N4KkKAumGPOM/b/0lzSXi40kXMP8bzKjynpVYem+oVqmCdpSKbfmVrji7/lNJe5 VjpMMTX4fTeFbKN+BtJ8mgLEYSyYTaqODwAevMYF9BUtcOj9jc8djW9Yrt3foTB568p2 wQPgZQntGN5ZZnFXN27gDHTgIwaAT0APKPyrGlEhYtCzGutXf1Vg6SDPGaZypojxISdY m5iMqXQBZ7UGdDHOcjuxzMS7TCPhFsqbQdR/xoj4asMLPkd8ZZLhvmOz5/acAEp9XL6v svP8iWbbaLLZeBqpE0aRJ/tDj1ytPUXjNBNCNJBs6l6lHuVx3Pv9BM++YR3cCg6ju6wT 9+UQ== 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:in-reply-to :references:mime-version; bh=Y92uEa6Ng6L8nssFn3ifSjrubFH60zO3GKp2+iBw/qQ=; b=BkraU6uCwBcP+qw9O2DtGvPmIJn6Ivudf1R74Lc8cqGaeEJvG5lXtOfMDOs7HxtryS ynorDPWofHpWUtFF0ncJKtl54wmr1V8va9TMsHeEdsygvFVjXtbRM9FYiiq7aei35Fb2 Ou6kJ61UNc2e6PTs1TOF4+pEECpcvkXI4N+y/MiBc8hy9nQ2zPPzFwFAhEZx8JBsDRHn kigUjzUZdpBjvdAniYsVgb+i2tfPgABtNd6/cBV/ZQRzjP9QLn2h2KptUnhQpsdELjyO 6f8fH7T6u8k6300i9IEGtAeIcoJua9emjO8L2lMTlgryF66oGqV4LsD1ir8BH4WdGaoL eqlA== X-Gm-Message-State: AOAM533j5kg1SOEphEolprEwLdDtCvUzpJBj91BcNAoNkL6Z9ZxsfYZR EDXafN6qgJXzFABpmdb/R5c= X-Google-Smtp-Source: ABdhPJw0cEa/ci8Lg7+cwTs1zmvhFaYzrmwkLmfTPGFHNy4R09D/xkuCKqHRvew/BeM8LhfVNaB+6w== X-Received: by 2002:ac2:4f92:: with SMTP id z18mr11796592lfs.343.1623682157956; Mon, 14 Jun 2021 07:49:17 -0700 (PDT) Received: from eldfell ([194.136.85.206]) by smtp.gmail.com with ESMTPSA id y8sm1501618lfj.192.2021.06.14.07.49.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Jun 2021 07:49:17 -0700 (PDT) Date: Mon, 14 Jun 2021 17:49:12 +0300 From: Pekka Paalanen To: Liviu Dudau Cc: Simon Ser , Haneen Mohammed , Alexandre Belloni , Linux Doc Mailing List , Xinliang Liu , Daniel Vetter , Edmund Dea , Alexandre Torgue , dri-devel , Russell King , Melissa Wen , Tomi Valkeinen , Thierry Reding , Laurent Pinchart , Benjamin Gaignard , Anitha Chrisanthus , Daniel Vetter , Steven Price , Sam Ravnborg , Jyri Sarha , Jerome Brunet , Marek Vasut , Joonyoung Shim , Qiang Yu , Krzysztof Kozlowski , Kevin Hilman , Neil Armstrong , Alyssa Rosenzweig , Xinwei Kong , Jonathan Hunter , David Airlie , Ludovic Desroches , Kieran Bingham , VMware Graphics , NXP Linux Team , Ben Skeggs , Chun-Kuang Hu , Maxime Coquelin , Jonas Karlman , Martin Blumenstingl , Chen Feng , Sascha Hauer , Alison Wang , Roland Scheidegger , Andrzej Hajda , Hans de Goede , Maxime Ripard , Rodrigo Vivi , Matthias Brugger , Nicolas Ferre , Chen-Yu Tsai , Sean Paul , Thomas Zimmermann , Paul Cercueil , Jernej Skrabec , Rodrigo Siqueira , Hyun Kwon , Boris Brezillon , Andrew Jeffery , Huang Rui , Yannick Fertr e , Jonathan Corbet , Seung-Woo Kim , Sandy Huang , Robert Foss , Joel Stanley , Tomeu Vizoso , Kyungmin Park , Noralf =?UTF-8?B?VHLDuG5uZXM=?= , Philippe Cornu , Pengutronix Kernel Team , Alex Deucher , Tian Tao , Oleksandr Andrushchenko , Shawn Guo , Christian =?UTF-8?B?S8O2bmln?= , Gerd Hoffmann Subject: Re: [PATCH v3] Documentation: gpu: Mention the requirements for new properties Message-ID: <20210614174912.15a49336@eldfell> In-Reply-To: <20210611120309.2b5eb4htupv5ss32@e110455-lin.cambridge.arm.com> References: <20210610174731.1209188-1-maxime@cerno.tech> <20210611120309.2b5eb4htupv5ss32@e110455-lin.cambridge.arm.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/s_k7/+lmfJUhN.4iHZeKmlr"; protocol="application/pgp-signature" Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org --Sig_/s_k7/+lmfJUhN.4iHZeKmlr Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 11 Jun 2021 13:03:09 +0100 Liviu Dudau wrote: > On Fri, Jun 11, 2021 at 08:14:59AM +0000, Simon Ser wrote: > > On Thursday, June 10th, 2021 at 23:00, Daniel Vetter wrote: > > =20 > > > If there's a strong consensus that we really need this then I'm not > > > going to nack this, but this really needs a pile of acks from > > > compositor folks that they're willing to live with the resulting > > > fallout this will likely bring. Your cc list seems to have an absence > > > of compositor folks, but instead every driver maintainer. That's > > > backwards. We make uapi for userspace, not for kernel driver > > > maintainers! =20 > >=20 > > In wlroots we have a policy of only allowing standard KMS properties to > > be used. Any vendor-specific property is going to be less well-defined, > > less widely useful, potentially have more design issues, potentially > > overlap in functionality with other vendor-specific properties, likely > > have some hardware-specific assumptions, etc. > >=20 > > What matters here is discussing with other driver & user-space folks to > > make sure the new property's design is sound. Designing uAPI is hard. > >=20 > > If kernel folks are struggling with a user-space implementation, they > > should discuss with user-space folks to see which project would be > > interested. There's a chance a compositor will be interested in the new > > property and will just do the user-space part for you, if not we can > > suggest candidate projects. > >=20 > > tl;dr strong agree with Daniel here. =20 >=20 > I think the assumption you and Daniel are making is that the first implem= entation of > a new KMS property can be made standard from day one and that it will wor= k for any > late comer driver as is, without having to make changes to its behaviour = in a > significant way. In my experience that is not the case. >=20 > I think we have moved from the times when we were trying to implement in = the Linux > world features that were available in the hardware but needed a kernel an= d userspace > API. The set of properties that exist in KMS cover a lot of needed functi= onality and > I don't expect to see new properties for stuff that is already supported = by hardware. >=20 > What I'm expected to see in the future is new functionality that gets imp= lemented by > one hardware vendor and the kernel developers trying to enable that for u= serspace. It > could be that the new property is generic, but there is no way of testing= that on > more than one implementation yet, so I'd say we are generous calling it "= standard > property". When the second or third hardware vendor comes along and start= s supporting > that property with their own set of extra requirements, then we can call = it > "standard". I agree that is a problem with trying to make generic anything. But it does not mean you should not even try. Maybe trying really hard saves a couple revisions. What I think should be planned for is revisions. How to add new properties that do the same thing but better, while documenting that a userspace KMS client can use only one revision at a time. You never remove old revisions, unless maybe with a DRM client cap they could disappear from that file description if that is necessary for seeing the new revision. While designing this, one also needs to take into account that KMS clients need to be able to save and restore properties *they do not understand*. So exposing two revisions of the same feature simultaneously would break save/restore is that's an error. > Then comes the effort cost: would it be easier to start with a vendor > property that only the vendor needs to support (and can submit patches in= to the > compositors to do so) and when the standard property gets added moves to = that, or But you can't move, you can only add? You can't delete the old property in kernel if it was ever released with a kernel and anyone used it. In the same sentence you also imply that there is a user of it, so removing it will break that user. Then you'll have to track the userspace lifetime to figure out which decade you can try removing it. > should we start with a generic property that gets implemented by the comp= ositors > (maybe, but then only one vendor supports it) and then later when we actu= ally > standardise the property we will have to carry backwards compatibility co= de in the > kernel to handle the old behaviour for old userspace? My proposal to Maxi= me was for > the former option to be reflected in the documentation, but I would like = to hear your > thoughts. You have to carry the backward compatibility in all cases, right? Userspace OTOH can drop support for older less supported KMS properties while taking advantage of a new revision. Userspace is not required to support old kernels forever. Here's a wild counter-proposal off a tangent: How about we make "implemented in and testable with VKMS" the rule, instead of "is generic" for new properties? VKMS is what compositors (will) use in CI. I would feel hugely less bad about using a property that only one hardware driver ever implements, if also VKMS implements it in a way that compositor CI can observe it working. I don't expect this proposal to be accepted, but it's food for thought. The major problem for compositor projects is testing as you usually don't have the hardware, IMO. CI tends to not have any hardware. Thanks, pq --Sig_/s_k7/+lmfJUhN.4iHZeKmlr Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAmDHbGgACgkQI1/ltBGq qqfSEw//XKYnCtuk195oOkuEK2xABCRkcU8MfJcqix8gWJlHQSmG9vtFvRJjNWAw qUvXGeA5Mu9U44gOZJl6CerXdRY4bS2c7X6LYQYXUn6zljdZko1CfW9UUkatF/c/ NeZz9rTtze95on/3sm4/dJ4FQck4Cu/lbixPHddXw0lMDAKFK4B3gBqSRxrovq8r 8k/L1nmUIbZCjo/Iz3E4shNDzjpcHOtBQ/6fl+sp7sU6zrtZPmN7Ma9i/QRu0FN3 xtCR+ETEWmLPjBRw3s2UGbNYXgQookomn5Xl6rbUj2duG8FTz1wQLbm7QepcrqyQ BZ8wWxYGNuswC1jTG9HekwaWQKfbvH6oCPQTYXxk5VCA4QiRt9vIZTrOla9qNfRq XJ7L1ero2UVlQdXkgrRaj3h/OmUzrGibU2bnxZNxhtROyXDQ9Xahc0/wNThPddGS mZRGiYFMp6KsfBQSf97AiiAwm4uSkseH6BTO0v1bJAcXQxqF+nmpKmByM6MR0Oc+ IDOQ4lLf22uODS0d7tGOsUTg1IMD8hO0NOoBvLndrzWBu4YnsuwBkMyhayJXpCOo WPVNvYfleOgOjtkBmGqn50kdoXleckKaD9L11sQcmAh/UmGoobgz9X/ZB6bT5c6X QenRvl/5ISefvKxitDWS9XGBgeMFi1ep8lEvGF4+svXI9nvK+ic= =b1pN -----END PGP SIGNATURE----- --Sig_/s_k7/+lmfJUhN.4iHZeKmlr--