From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx1.smtp.larsendata.com (mx1.smtp.larsendata.com [91.221.196.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E3B0E2F27 for ; Tue, 1 Feb 2022 20:55:13 +0000 (UTC) Received: from mail01.mxhotel.dk (mail01.mxhotel.dk [91.221.196.236]) by mx1.smtp.larsendata.com (Halon) with ESMTPS id 3a4211e5-83a1-11ec-b20b-0050568c148b; Tue, 01 Feb 2022 20:55:03 +0000 (UTC) Received: from ravnborg.org (80-162-45-141-cable.dk.customer.tdc.net [80.162.45.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: sam@ravnborg.org) by mail01.mxhotel.dk (Postfix) with ESMTPSA id 5A64D194B9E; Tue, 1 Feb 2022 21:54:05 +0100 (CET) Date: Tue, 1 Feb 2022 21:54:01 +0100 X-Report-Abuse-To: abuse@mxhotel.dk From: Sam Ravnborg To: Daniel Vetter Cc: Geert Uytterhoeven , Andy Shevchenko , Linux Fbdev development list , Michael Hennerich , Greg Kroah-Hartman , Helge Deller , linux-staging@lists.linux.dev, Javier Martinez Canillas , DRI Development , Linux Kernel Mailing List , Phillip Potter , Thomas Zimmermann , Carlis , Andy Shevchenko , Lee Jones , Heiner Kallweit Subject: Re: [PATCH v1 1/4] fbtft: Unorphan the driver Message-ID: References: <6e74d4cc-655a-e38e-0856-a59e4e6deb36@redhat.com> <840ec74d-60c6-9480-709c-8cd597c6f5b0@redhat.com> Precedence: bulk X-Mailing-List: linux-staging@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Hi Daniel, On Tue, Feb 01, 2022 at 06:06:33PM +0100, Daniel Vetter wrote: > On Tue, Feb 1, 2022 at 6:01 PM Geert Uytterhoeven wrote: > > > > Hi Thomas, > > > > On Tue, Feb 1, 2022 at 5:16 PM Thomas Zimmermann wrote: > > > Am 31.01.22 um 11:18 schrieb Javier Martinez Canillas: > > > > Another thing that's missing is a DRM_MODE_CONNECTOR_I2C, because I used for > > > > now a DRM_MODE_CONNECTOR_Unknown. > > > > > > That might have implications on userspace. Maybe ask around. (Not that > > > we actually run userspace on the device). > > > > Looking at the list of connector types (and wondering if we're gonna > > need more when converting existing fbdev drivers to drm drivers), > > there seem to be two different families of connector types, for > > 1. transports between CRTC and display (e.g. VGA, DVID, HDMI), > > 2. transports between CPU and CRTC (e.g. SPI, possibly USB, and > > the proposed I2C)? > > I was trying to argue for a panel connector type and stop doing all > these internal things because like you point out, it kinda doesn't, > only the external connectors are relevant to users. But it didn't > stick anywhere yet, we keep adding more connector types and then > having to update userspace, which should map these all to "it's the > panel" or something like that. But also since various technicolor > abbreviations are about as useful to end-users as "unknown" it really > doesn't matter, so I'm happy to let this bikeshed get a tad fancier > every year :-) We discussed DRM_MODE_CONNECTOR_PANEL or some sort - but I recall we ended up with worrying about breaking userspace. See https://lore.kernel.org/dri-devel/?q=DRM_MODE_CONNECTOR_PANEL For this kind of change I chicken out due to lack of understanding of the userspace implications. Typing the patch is simple but taking the correct decision not so. The discussion popped up when we made it mandatory to specify a connector so we could better match up stuff between display drivers/bridges and panel drivers. Sam 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 53E01C433FE for ; Tue, 1 Feb 2022 20:54:08 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 9142410E143; Tue, 1 Feb 2022 20:54:07 +0000 (UTC) Received: from mx1.smtp.larsendata.com (mx1.smtp.larsendata.com [91.221.196.215]) by gabe.freedesktop.org (Postfix) with ESMTPS id 51A6E10E143 for ; Tue, 1 Feb 2022 20:54:06 +0000 (UTC) Received: from mail01.mxhotel.dk (mail01.mxhotel.dk [91.221.196.236]) by mx1.smtp.larsendata.com (Halon) with ESMTPS id 3a4211e5-83a1-11ec-b20b-0050568c148b; Tue, 01 Feb 2022 20:55:03 +0000 (UTC) Received: from ravnborg.org (80-162-45-141-cable.dk.customer.tdc.net [80.162.45.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: sam@ravnborg.org) by mail01.mxhotel.dk (Postfix) with ESMTPSA id 5A64D194B9E; Tue, 1 Feb 2022 21:54:05 +0100 (CET) Date: Tue, 1 Feb 2022 21:54:01 +0100 X-Report-Abuse-To: abuse@mxhotel.dk From: Sam Ravnborg To: Daniel Vetter Subject: Re: [PATCH v1 1/4] fbtft: Unorphan the driver Message-ID: References: <6e74d4cc-655a-e38e-0856-a59e4e6deb36@redhat.com> <840ec74d-60c6-9480-709c-8cd597c6f5b0@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Andy Shevchenko , Linux Fbdev development list , Andy Shevchenko , Michael Hennerich , Greg Kroah-Hartman , Helge Deller , linux-staging@lists.linux.dev, Javier Martinez Canillas , DRI Development , Linux Kernel Mailing List , Geert Uytterhoeven , Thomas Zimmermann , Carlis , Phillip Potter , Lee Jones , Heiner Kallweit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi Daniel, On Tue, Feb 01, 2022 at 06:06:33PM +0100, Daniel Vetter wrote: > On Tue, Feb 1, 2022 at 6:01 PM Geert Uytterhoeven wrote: > > > > Hi Thomas, > > > > On Tue, Feb 1, 2022 at 5:16 PM Thomas Zimmermann wrote: > > > Am 31.01.22 um 11:18 schrieb Javier Martinez Canillas: > > > > Another thing that's missing is a DRM_MODE_CONNECTOR_I2C, because I used for > > > > now a DRM_MODE_CONNECTOR_Unknown. > > > > > > That might have implications on userspace. Maybe ask around. (Not that > > > we actually run userspace on the device). > > > > Looking at the list of connector types (and wondering if we're gonna > > need more when converting existing fbdev drivers to drm drivers), > > there seem to be two different families of connector types, for > > 1. transports between CRTC and display (e.g. VGA, DVID, HDMI), > > 2. transports between CPU and CRTC (e.g. SPI, possibly USB, and > > the proposed I2C)? > > I was trying to argue for a panel connector type and stop doing all > these internal things because like you point out, it kinda doesn't, > only the external connectors are relevant to users. But it didn't > stick anywhere yet, we keep adding more connector types and then > having to update userspace, which should map these all to "it's the > panel" or something like that. But also since various technicolor > abbreviations are about as useful to end-users as "unknown" it really > doesn't matter, so I'm happy to let this bikeshed get a tad fancier > every year :-) We discussed DRM_MODE_CONNECTOR_PANEL or some sort - but I recall we ended up with worrying about breaking userspace. See https://lore.kernel.org/dri-devel/?q=DRM_MODE_CONNECTOR_PANEL For this kind of change I chicken out due to lack of understanding of the userspace implications. Typing the patch is simple but taking the correct decision not so. The discussion popped up when we made it mandatory to specify a connector so we could better match up stuff between display drivers/bridges and panel drivers. Sam