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=-10.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 7EEC2C48BE5 for ; Fri, 11 Jun 2021 15:26:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 63256613EE for ; Fri, 11 Jun 2021 15:26:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231324AbhFKP2U (ORCPT ); Fri, 11 Jun 2021 11:28:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38866 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230451AbhFKP2S (ORCPT ); Fri, 11 Jun 2021 11:28:18 -0400 Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A5D13C061574 for ; Fri, 11 Jun 2021 08:26:20 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id y7so6500694wrh.7 for ; Fri, 11 Jun 2021 08:26:20 -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:content-transfer-encoding:in-reply-to; bh=0fXaAQCav4JMHqqDLTmJAA9vL2ofAn8LFVDAYy3FosU=; b=RxaoGZB9PdBO2obWWr9Son1CIQ7DAYfphJ4uKNVobOiYpJ+mmavn7NB0YtCHIT1l1D oQsizyYQ4FJRefvQAFJO/0AJOav1E/ofoqH4paJ297oy93lpQ3e896974RQ7zKVhhvb1 oqY38pf1DVDLn5a35cw/r70vfWSV/1SHhcR0w= 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:content-transfer-encoding :in-reply-to; bh=0fXaAQCav4JMHqqDLTmJAA9vL2ofAn8LFVDAYy3FosU=; b=d5XOickvhI3ZtxUKnL1ZYIf4E31j1LW4rSOJk/Wz7NEsLarpPh0E17cQNhPdpNTcpw JXUUxoR418ftD0UwqoOSVkjzDjaKU5ESBOKYOSiMtVPBCGoqoweaaFAf/gy/EzDJVr8g uS5KlOeR8vqmW9LRTOdqP7z4wSkvIIIgyJ9fE0I9uOcQeRDQ0ri1b/f0w3ywRBXc5xsG hgIS3kwtobKShwFN5KMb1swmdeYNk+bEf4B5+Q8uFbPaYguY3rDoUEH1fx8HIGob2SIs Z4IFqc3zsdAzha+GmRLzg2RjdNT0zP6SSfAk9Mzk3/pJzE6HP99P78ZB1GJD7lyvO6oS 5Mwg== X-Gm-Message-State: AOAM531+UvHP3cRkly4bPkb90DNmFPk4C3zzK0XxLZKk8uAU9k4mgOJI 85O7Q/+H1clZx6sxZLVzzrUklQ== X-Google-Smtp-Source: ABdhPJw2KFr1zO8QQtfKE4YD9azGDVISyK9XC85GcDukXzrthZ23Yp2apTf9M28mUBh5xZI3M9Pdgw== X-Received: by 2002:a5d:438a:: with SMTP id i10mr4768390wrq.82.1623425179113; Fri, 11 Jun 2021 08:26:19 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id h11sm6267937wmq.34.2021.06.11.08.26.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Jun 2021 08:26:18 -0700 (PDT) Date: Fri, 11 Jun 2021 17:26:14 +0200 From: Daniel Vetter To: Tomi Valkeinen Cc: Maxime Ripard , Daniel Vetter , dri-devel , Daniel Vetter , David Airlie , Maarten Lankhorst , Thomas Zimmermann , Linux Doc Mailing List , Jonathan Corbet , Alexandre Belloni , Alexandre Torgue , Alex Deucher , Alison Wang , Alyssa Rosenzweig , Andrew Jeffery , Andrzej Hajda , Anitha Chrisanthus , Benjamin Gaignard , Ben Skeggs , Boris Brezillon , Brian Starkey , Chen Feng , Chen-Yu Tsai , Christian Gmeiner , Christian =?iso-8859-1?Q?K=F6nig?= , Chun-Kuang Hu , Edmund Dea , Eric Anholt , Fabio Estevam , Gerd Hoffmann , Haneen Mohammed , Hans de Goede , Heiko =?iso-8859-1?Q?St=FCbner?= , Huang Rui , Hyun Kwon , Inki Dae , Jani Nikula , Jernej Skrabec , Jerome Brunet , Joel Stanley , John Stultz , Jonas Karlman , Jonathan Hunter , Joonas Lahtinen , Joonyoung Shim , Jyri Sarha , Kevin Hilman , Kieran Bingham , Krzysztof Kozlowski , Kyungmin Park , Laurent Pinchart , Linus Walleij , Liviu Dudau , Lucas Stach , Ludovic Desroches , Marek Vasut , Martin Blumenstingl , Matthias Brugger , Maxime Coquelin , Melissa Wen , Neil Armstrong , Nicolas Ferre , Noralf =?iso-8859-1?Q?Tr=F8nnes?= , NXP Linux Team , Oleksandr Andrushchenko , Patrik Jakobsson , Paul Cercueil , Pengutronix Kernel Team , Philippe Cornu , Philipp Zabel , Qiang Yu , Rob Clark , Robert Foss , Rob Herring , Rodrigo Siqueira , Rodrigo Vivi , Roland Scheidegger , Russell King , Sam Ravnborg , Sandy Huang , Sascha Hauer , Sean Paul , Seung-Woo Kim , Shawn Guo , Stefan Agner , Steven Price , Sumit Semwal , Thierry Reding , Tian Tao , Tomeu Vizoso , VMware Graphics , Xinliang Liu , Xinwei Kong , Yannick Fertre , Zack Rusin Subject: Re: [PATCH v3] Documentation: gpu: Mention the requirements for new properties Message-ID: References: <20210610174731.1209188-1-maxime@cerno.tech> <20210611055407.aoeams62wbalodrj@gilmour> <1cac781e-122f-568b-5f5a-7e0ceb94bd0b@ideasonboard.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1cac781e-122f-568b-5f5a-7e0ceb94bd0b@ideasonboard.com> X-Operating-System: Linux phenom 5.10.32scarlett+ Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Fri, Jun 11, 2021 at 09:53:19AM +0300, Tomi Valkeinen wrote: > On 11/06/2021 08:54, Maxime Ripard wrote: > > Hi, > > > > On Thu, Jun 10, 2021 at 11:00:05PM +0200, Daniel Vetter wrote: > > > On Thu, Jun 10, 2021 at 7:47 PM Maxime Ripard wrote: > > > > > > > > New KMS properties come with a bunch of requirements to avoid each > > > > driver from running their own, inconsistent, set of properties, > > > > eventually leading to issues like property conflicts, inconsistencies > > > > between drivers and semantics, etc. > > > > > > > > Let's document what we expect. > > > > > > > > Cc: Alexandre Belloni > > > > Cc: Alexandre Torgue > > > > Cc: Alex Deucher > > > > Cc: Alison Wang > > > > Cc: Alyssa Rosenzweig > > > > Cc: Andrew Jeffery > > > > Cc: Andrzej Hajda > > > > Cc: Anitha Chrisanthus > > > > Cc: Benjamin Gaignard > > > > Cc: Ben Skeggs > > > > Cc: Boris Brezillon > > > > Cc: Brian Starkey > > > > Cc: Chen Feng > > > > Cc: Chen-Yu Tsai > > > > Cc: Christian Gmeiner > > > > Cc: "Christian König" > > > > Cc: Chun-Kuang Hu > > > > Cc: Edmund Dea > > > > Cc: Eric Anholt > > > > Cc: Fabio Estevam > > > > Cc: Gerd Hoffmann > > > > Cc: Haneen Mohammed > > > > Cc: Hans de Goede > > > > Cc: "Heiko Stübner" > > > > Cc: Huang Rui > > > > Cc: Hyun Kwon > > > > Cc: Inki Dae > > > > Cc: Jani Nikula > > > > Cc: Jernej Skrabec > > > > Cc: Jerome Brunet > > > > Cc: Joel Stanley > > > > Cc: John Stultz > > > > Cc: Jonas Karlman > > > > Cc: Jonathan Hunter > > > > Cc: Joonas Lahtinen > > > > Cc: Joonyoung Shim > > > > Cc: Jyri Sarha > > > > Cc: Kevin Hilman > > > > Cc: Kieran Bingham > > > > Cc: Krzysztof Kozlowski > > > > Cc: Kyungmin Park > > > > Cc: Laurent Pinchart > > > > Cc: Linus Walleij > > > > Cc: Liviu Dudau > > > > Cc: Lucas Stach > > > > Cc: Ludovic Desroches > > > > Cc: Marek Vasut > > > > Cc: Martin Blumenstingl > > > > Cc: Matthias Brugger > > > > Cc: Maxime Coquelin > > > > Cc: Maxime Ripard > > > > Cc: Melissa Wen > > > > Cc: Neil Armstrong > > > > Cc: Nicolas Ferre > > > > Cc: "Noralf Trĝnnes" > > > > Cc: NXP Linux Team > > > > Cc: Oleksandr Andrushchenko > > > > Cc: Patrik Jakobsson > > > > Cc: Paul Cercueil > > > > Cc: Pengutronix Kernel Team > > > > Cc: Philippe Cornu > > > > Cc: Philipp Zabel > > > > Cc: Qiang Yu > > > > Cc: Rob Clark > > > > Cc: Robert Foss > > > > Cc: Rob Herring > > > > Cc: Rodrigo Siqueira > > > > Cc: Rodrigo Vivi > > > > Cc: Roland Scheidegger > > > > Cc: Russell King > > > > Cc: Sam Ravnborg > > > > Cc: Sandy Huang > > > > Cc: Sascha Hauer > > > > Cc: Sean Paul > > > > Cc: Seung-Woo Kim > > > > Cc: Shawn Guo > > > > Cc: Stefan Agner > > > > Cc: Steven Price > > > > Cc: Sumit Semwal > > > > Cc: Thierry Reding > > > > Cc: Tian Tao > > > > Cc: Tomeu Vizoso > > > > Cc: Tomi Valkeinen > > > > Cc: VMware Graphics > > > > Cc: Xinliang Liu > > > > Cc: Xinwei Kong > > > > Cc: Yannick Fertre > > > > Cc: Zack Rusin > > > > Reviewed-by: Daniel Vetter > > > > Signed-off-by: Maxime Ripard > > > > > > > > --- > > > > > > > > Changes from v2: > > > > - Take into account the feedback from Laurent and Lidiu to no longer > > > > force generic properties, but prefix vendor-specific properties with > > > > the vendor name > > > > > > I'm pretty sure my r-b was without this ... > > > > Yeah, sorry. I wanted to tell you on IRC that you wanted to have a > > second look, but I shouldn't have kept it and caught you by surprise > > indeed. > > > > > Why exactly do we need this? KMS is meant to be fairly generic (bugs > > > throw a wrench around here sometimes, and semantics can be tricky). If > > > we open up the door to yolo vendor properties in upstream, then that > > > goal is pretty much written off. And we've been there with vendor > > > properties, it's a giantic mess. > > > > > > Minimally drop my r-b, I'm definitely not in support of this idea. > > > > So the argument Lidiu and Laurent made was that in some cases, getting a > > generic property right with only a couple of users is hard. So they > > advocated for the right to keep non-generic properties. I can get the > > argument, and no-one else said that was wrong, so it felt like the > > consensus was there. > > I also think that (maybe mainly on embedded side) we may have 1) esoteric HW > features which perhaps can't even be made generic, and 2) features which may > or may not be generic, but for which support cannot be added to any common > opensource userspace projects like X or Weston, as the only use cases for > the features are specialized low level apps (often customer's closed-source > apps). > > While I agree with Daniel's "gigantic mess" problem, it would also be quite > nice to have a way to support all the HW features upstream instead of > carrying them in vendor trees. So this means to be able to accomodate this "vendor properties are totally fine, go wild" exception we also need to throw "open source userspace user, fully reviewed and tested" into the drink? At least my experience from what I've seen with funky vendor properties isn't so much that we can't figure out a reasonable way to expose them. The problem is that the userspace tends to be a (often closed source) vendor fork of a random compositor somewhere. So if that requirement is somehow a problem, we need to talk about _that_. Not promising we'll totally merge some vendor properties without spelling out what exactly this means. All that ensures is that people submit patches and then get annoyed because they still can't be merged because the userspace situation is all the same. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch 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=-8.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 59A10C48BD1 for ; Fri, 11 Jun 2021 15:26:22 +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 2C43761400 for ; Fri, 11 Jun 2021 15:26:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2C43761400 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 6FC866E50E; Fri, 11 Jun 2021 15:26:21 +0000 (UTC) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) by gabe.freedesktop.org (Postfix) with ESMTPS id 80D946E50E for ; Fri, 11 Jun 2021 15:26:20 +0000 (UTC) Received: by mail-wr1-x434.google.com with SMTP id a11so6501459wrt.13 for ; Fri, 11 Jun 2021 08:26:20 -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:content-transfer-encoding:in-reply-to; bh=0fXaAQCav4JMHqqDLTmJAA9vL2ofAn8LFVDAYy3FosU=; b=RxaoGZB9PdBO2obWWr9Son1CIQ7DAYfphJ4uKNVobOiYpJ+mmavn7NB0YtCHIT1l1D oQsizyYQ4FJRefvQAFJO/0AJOav1E/ofoqH4paJ297oy93lpQ3e896974RQ7zKVhhvb1 oqY38pf1DVDLn5a35cw/r70vfWSV/1SHhcR0w= 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:content-transfer-encoding :in-reply-to; bh=0fXaAQCav4JMHqqDLTmJAA9vL2ofAn8LFVDAYy3FosU=; b=ZmJSLe81D/oN11tVWLgiWOFZUIxzvye4P/6Is/3ZkUfCeDwvEwejBiwIlSIqeIqLP2 F4BkfqnPABgD0wKnZdBP5HvwdzGNqapAckCo6sNt9/Lp9CNJgDnNsZfdYFmvlB8GPZNM 8BdNEIh7py0GkNwP32wpFkpsLwUC33Axt603zS19pUciTt9m/vDM630BCNEDkDNpnfqB rXH2VIc5Ix6aDj0TRriSnFh4mm/01QCJgoE9/l42bxNtE2g1tjyIVgl0ChypBCe3biOq AmVlZM4yTxAiQoI2FnKkXiyzi12lukxRWzqL6aAhePYG6xM3w8tlpnjkfJZTDjnzIYn1 Qa0Q== X-Gm-Message-State: AOAM531SKBp4ngyPv4/qeZWSrc/yH60ZwutJdJOxtTx4VZ7K90OsosPh 5dk2ORdmLZaG+uMnjziU12Cw4g== X-Google-Smtp-Source: ABdhPJw2KFr1zO8QQtfKE4YD9azGDVISyK9XC85GcDukXzrthZ23Yp2apTf9M28mUBh5xZI3M9Pdgw== X-Received: by 2002:a5d:438a:: with SMTP id i10mr4768390wrq.82.1623425179113; Fri, 11 Jun 2021 08:26:19 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id h11sm6267937wmq.34.2021.06.11.08.26.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Jun 2021 08:26:18 -0700 (PDT) Date: Fri, 11 Jun 2021 17:26:14 +0200 From: Daniel Vetter To: Tomi Valkeinen Subject: Re: [PATCH v3] Documentation: gpu: Mention the requirements for new properties Message-ID: References: <20210610174731.1209188-1-maxime@cerno.tech> <20210611055407.aoeams62wbalodrj@gilmour> <1cac781e-122f-568b-5f5a-7e0ceb94bd0b@ideasonboard.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1cac781e-122f-568b-5f5a-7e0ceb94bd0b@ideasonboard.com> X-Operating-System: Linux phenom 5.10.32scarlett+ 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: Xinliang Liu , dri-devel , Anitha Chrisanthus , Jonathan Hunter , Jerome Brunet , Kevin Hilman , Ludovic Desroches , NXP Linux Team , Sascha Hauer , Roland Scheidegger , Sean Paul , Hyun Kwon , Andrew Jeffery , Seung-Woo Kim , Noralf =?iso-8859-1?Q?Tr=F8nnes?= , Pengutronix Kernel Team , Alex Deucher , Laurent Pinchart , Alexandre Belloni , Linux Doc Mailing List , David Airlie , Edmund Dea , Thierry Reding , Daniel Vetter , Krzysztof Kozlowski , Steven Price , VMware Graphics , Ben Skeggs , Martin Blumenstingl , Rodrigo Siqueira , Boris Brezillon , Sandy Huang , Kyungmin Park , Maxime Coquelin , Haneen Mohammed , Neil Armstrong , Melissa Wen , Gerd Hoffmann , Benjamin Gaignard , Sam Ravnborg , Jonathan Corbet , Xinwei Kong , Chen-Yu Tsai , Alyssa Rosenzweig , Joel Stanley , Chun-Kuang Hu , Jonas Karlman , Chen Feng , Alison Wang , Maxime Ripard , Rodrigo Vivi , Tomeu Vizoso , Kieran Bingham , Tian Tao , Shawn Guo , Christian =?iso-8859-1?Q?K=F6nig?= , Daniel Vetter , Liviu Dudau , Alexandre Torgue , Paul Cercueil , Andrzej Hajda , Huang Rui , Marek Vasut , Joonyoung Shim , Oleksandr Andrushchenko , Russell King , Philippe Cornu , Thomas Zimmermann , Hans de Goede , Matthias Brugger , Jernej Skrabec , Yannick Fertre , Nicolas Ferre , Robert Foss , Qiang Yu , Jyri Sarha Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, Jun 11, 2021 at 09:53:19AM +0300, Tomi Valkeinen wrote: > On 11/06/2021 08:54, Maxime Ripard wrote: > > Hi, > > > > On Thu, Jun 10, 2021 at 11:00:05PM +0200, Daniel Vetter wrote: > > > On Thu, Jun 10, 2021 at 7:47 PM Maxime Ripard wrote: > > > > > > > > New KMS properties come with a bunch of requirements to avoid each > > > > driver from running their own, inconsistent, set of properties, > > > > eventually leading to issues like property conflicts, inconsistencies > > > > between drivers and semantics, etc. > > > > > > > > Let's document what we expect. > > > > > > > > Cc: Alexandre Belloni > > > > Cc: Alexandre Torgue > > > > Cc: Alex Deucher > > > > Cc: Alison Wang > > > > Cc: Alyssa Rosenzweig > > > > Cc: Andrew Jeffery > > > > Cc: Andrzej Hajda > > > > Cc: Anitha Chrisanthus > > > > Cc: Benjamin Gaignard > > > > Cc: Ben Skeggs > > > > Cc: Boris Brezillon > > > > Cc: Brian Starkey > > > > Cc: Chen Feng > > > > Cc: Chen-Yu Tsai > > > > Cc: Christian Gmeiner > > > > Cc: "Christian König" > > > > Cc: Chun-Kuang Hu > > > > Cc: Edmund Dea > > > > Cc: Eric Anholt > > > > Cc: Fabio Estevam > > > > Cc: Gerd Hoffmann > > > > Cc: Haneen Mohammed > > > > Cc: Hans de Goede > > > > Cc: "Heiko Stübner" > > > > Cc: Huang Rui > > > > Cc: Hyun Kwon > > > > Cc: Inki Dae > > > > Cc: Jani Nikula > > > > Cc: Jernej Skrabec > > > > Cc: Jerome Brunet > > > > Cc: Joel Stanley > > > > Cc: John Stultz > > > > Cc: Jonas Karlman > > > > Cc: Jonathan Hunter > > > > Cc: Joonas Lahtinen > > > > Cc: Joonyoung Shim > > > > Cc: Jyri Sarha > > > > Cc: Kevin Hilman > > > > Cc: Kieran Bingham > > > > Cc: Krzysztof Kozlowski > > > > Cc: Kyungmin Park > > > > Cc: Laurent Pinchart > > > > Cc: Linus Walleij > > > > Cc: Liviu Dudau > > > > Cc: Lucas Stach > > > > Cc: Ludovic Desroches > > > > Cc: Marek Vasut > > > > Cc: Martin Blumenstingl > > > > Cc: Matthias Brugger > > > > Cc: Maxime Coquelin > > > > Cc: Maxime Ripard > > > > Cc: Melissa Wen > > > > Cc: Neil Armstrong > > > > Cc: Nicolas Ferre > > > > Cc: "Noralf Trĝnnes" > > > > Cc: NXP Linux Team > > > > Cc: Oleksandr Andrushchenko > > > > Cc: Patrik Jakobsson > > > > Cc: Paul Cercueil > > > > Cc: Pengutronix Kernel Team > > > > Cc: Philippe Cornu > > > > Cc: Philipp Zabel > > > > Cc: Qiang Yu > > > > Cc: Rob Clark > > > > Cc: Robert Foss > > > > Cc: Rob Herring > > > > Cc: Rodrigo Siqueira > > > > Cc: Rodrigo Vivi > > > > Cc: Roland Scheidegger > > > > Cc: Russell King > > > > Cc: Sam Ravnborg > > > > Cc: Sandy Huang > > > > Cc: Sascha Hauer > > > > Cc: Sean Paul > > > > Cc: Seung-Woo Kim > > > > Cc: Shawn Guo > > > > Cc: Stefan Agner > > > > Cc: Steven Price > > > > Cc: Sumit Semwal > > > > Cc: Thierry Reding > > > > Cc: Tian Tao > > > > Cc: Tomeu Vizoso > > > > Cc: Tomi Valkeinen > > > > Cc: VMware Graphics > > > > Cc: Xinliang Liu > > > > Cc: Xinwei Kong > > > > Cc: Yannick Fertre > > > > Cc: Zack Rusin > > > > Reviewed-by: Daniel Vetter > > > > Signed-off-by: Maxime Ripard > > > > > > > > --- > > > > > > > > Changes from v2: > > > > - Take into account the feedback from Laurent and Lidiu to no longer > > > > force generic properties, but prefix vendor-specific properties with > > > > the vendor name > > > > > > I'm pretty sure my r-b was without this ... > > > > Yeah, sorry. I wanted to tell you on IRC that you wanted to have a > > second look, but I shouldn't have kept it and caught you by surprise > > indeed. > > > > > Why exactly do we need this? KMS is meant to be fairly generic (bugs > > > throw a wrench around here sometimes, and semantics can be tricky). If > > > we open up the door to yolo vendor properties in upstream, then that > > > goal is pretty much written off. And we've been there with vendor > > > properties, it's a giantic mess. > > > > > > Minimally drop my r-b, I'm definitely not in support of this idea. > > > > So the argument Lidiu and Laurent made was that in some cases, getting a > > generic property right with only a couple of users is hard. So they > > advocated for the right to keep non-generic properties. I can get the > > argument, and no-one else said that was wrong, so it felt like the > > consensus was there. > > I also think that (maybe mainly on embedded side) we may have 1) esoteric HW > features which perhaps can't even be made generic, and 2) features which may > or may not be generic, but for which support cannot be added to any common > opensource userspace projects like X or Weston, as the only use cases for > the features are specialized low level apps (often customer's closed-source > apps). > > While I agree with Daniel's "gigantic mess" problem, it would also be quite > nice to have a way to support all the HW features upstream instead of > carrying them in vendor trees. So this means to be able to accomodate this "vendor properties are totally fine, go wild" exception we also need to throw "open source userspace user, fully reviewed and tested" into the drink? At least my experience from what I've seen with funky vendor properties isn't so much that we can't figure out a reasonable way to expose them. The problem is that the userspace tends to be a (often closed source) vendor fork of a random compositor somewhere. So if that requirement is somehow a problem, we need to talk about _that_. Not promising we'll totally merge some vendor properties without spelling out what exactly this means. All that ensures is that people submit patches and then get annoyed because they still can't be merged because the userspace situation is all the same. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch