Message ID | 20230729004913.215872-4-dmitry.baryshkov@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:918b:0:b0:3e4:2afc:c1 with SMTP id s11csp902449vqg; Sat, 29 Jul 2023 00:46:49 -0700 (PDT) X-Google-Smtp-Source: APBJJlGBpA029yzheUNh/dEfdt5jKUAzkvNf97cvvZtCEVbHWABSyeUOsinetLMkdGsN0pBj1dTf X-Received: by 2002:a05:6a20:415:b0:137:2213:9495 with SMTP id a21-20020a056a20041500b0013722139495mr3723104pza.58.1690616808759; Sat, 29 Jul 2023 00:46:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690616808; cv=none; d=google.com; s=arc-20160816; b=Kpb0Nd7TnK81G/d+dPYUqApW75MQSSdnfCdIglPgJ3z3VXVmR0VZ+nHzisO9rYYyc2 /GmCnAKAAX+xCZmlrYWTuPMiyBHclboyYBMGCD0XegMlqlagIgCMU9nEzAOTqnqa3f/y mz7Us5Jo83/z0XMB7nNOF4oqw2tDckskEt98YxkSVgNXqS0TDIZVkDSey3h/GFcr0nkN tlss1RY5xHJImxzJBhR6O38ncFJmEU45xFa9oe3hfFnf6pTiaHpXn4HqK5qNFlbSnnp8 shxkL5ZgIaB3neoLe72+vWuKGtR0z/PX4VRQYh2acMXgmakQAbGb1iOupldnuaV2wl9S m72g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=DeTSuwZPlptjGhIuO9GsGe/aAqJgvkK628OoK+PRdAE=; fh=Ijs4z7asxnxZXSXH1iKU90GjPS2pk4sYIkJQzsSgRPM=; b=IbsmHg9+gOJJ24Zhe2DK6up/Y5CuhyMYatDj8rQMob24yLN+zZHRM2xLrZJxaBqIYD zQ5iHx2KnSXrmZPxQ5bt78KNQTvt8LaCQUdoO/cep1F39YuodfMD4Aw7f6Da+WEErN3D 5e0YRuWg9idiccXQFogblGDIlMA0XgxdFebF2y+NdvFIupuCg3KqKUCYdf4x+2kaPRrU jjXAB4eqYW5w6myLGymd3IskmYnGXn/JesAbmjP6clMREhIpsCy5J1kx3INh/skp7Dmb URf/fn+EYrKJjs7rKiecqDOrIEMecKu+8yqXpSor6mFdavAqyzjLiNrQbe8vN+a+YfFA wDqw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=VsttY5+S; 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: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n7-20020a6543c7000000b00543e36736d3si2596348pgp.628.2023.07.29.00.46.35; Sat, 29 Jul 2023 00:46:48 -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=VsttY5+S; 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 S235282AbjG2A4c (ORCPT <rfc822;hanasaki@gmail.com> + 99 others); Fri, 28 Jul 2023 20:56:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45616 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233628AbjG2A4O (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 28 Jul 2023 20:56:14 -0400 Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C4760E4B for <linux-kernel@vger.kernel.org>; Fri, 28 Jul 2023 17:55:16 -0700 (PDT) Received: by mail-lj1-f169.google.com with SMTP id 38308e7fff4ca-2b72161c6e9so49331801fa.0 for <linux-kernel@vger.kernel.org>; Fri, 28 Jul 2023 17:55:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1690591757; x=1691196557; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=DeTSuwZPlptjGhIuO9GsGe/aAqJgvkK628OoK+PRdAE=; b=VsttY5+SOr9fF9DKFAkD1fpnsZIU2pLzIzH48JAnNTF5WLWlpLyduf34wSQbvaNWAb q0T98HLRjion0v+Y7GwNdbH2nO50r6azAiH0r5Frq1ZaCCH8lItorpS6m2+vQR62eH9A yCcuwR3l9OiBfirFtuZ7x38cXj0lPnJHQNKLKigfGi84TTJgUD4g3GhZP3EK0oE51Ey5 dYiVwpdI8VzxFLpdaBvu+EZApctr+dAKbxBXZzNoF5/W7MeqLK177oiDz4ESd7tEX8gi 2Otd6PUFptJhMXbFJrehHaYdH0YZ4JJ8iqOxiPYAmbgnXuoHCYlwShe9sd7G0vTI7HkK PLWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690591757; x=1691196557; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=DeTSuwZPlptjGhIuO9GsGe/aAqJgvkK628OoK+PRdAE=; b=L/TCQGxcppUh2evyxmK0XKE8Xo+IFhUmjELwv0xLHcdXBuAvqXWbsu8qqPVMS/F+3T 5gKSRJEuaMvyxShZarvfQ2JX/VMc/2IOqG2ajmq8oKy91p82qZ48Lx5Qiw0gapXytOaJ O2isQfV09/HB+mw9F9LgPkZnl1uK64EJsRwnbKXYV3qLQm3CpGw8fMNKW1+zUAnVZZpt lWSetDCZywaeBn0By8WJPizSEdWUsfvfae8XRS0gMg0JZllq2SvR0sEx6XFPeDMgOBeX dQkQt6E5WCWURMX98z+hNU6hVhJ3WYbFMEKPZFaGiCR3PKegOUX9QE99hWPntWFZGtL2 bXXQ== X-Gm-Message-State: ABy/qLa+gV/oaMthAYUpt8O7YPpSvZrjvOY5Lajrxd+B1CyPKobCJJ62 FlsYZH21lNYwM3AkMLZtM6iIRQ== X-Received: by 2002:a05:6512:2825:b0:4f8:6d9d:abe0 with SMTP id cf37-20020a056512282500b004f86d9dabe0mr1946529lfb.33.1690591756849; Fri, 28 Jul 2023 17:49:16 -0700 (PDT) Received: from umbar.unikie.fi ([192.130.178.91]) by smtp.gmail.com with ESMTPSA id a24-20020a19f818000000b004fe20d1b288sm500702lff.159.2023.07.28.17.49.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Jul 2023 17:49:16 -0700 (PDT) From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> To: David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, Andrzej Hajda <andrzej.hajda@intel.com>, Neil Armstrong <neil.armstrong@linaro.org>, Robert Foss <rfoss@kernel.org>, Laurent Pinchart <Laurent.pinchart@ideasonboard.com>, Jonas Karlman <jonas@kwiboo.se>, Jernej Skrabec <jernej.skrabec@gmail.com>, Andy Gross <agross@kernel.org>, Bjorn Andersson <andersson@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, Simon Ser <contact@emersion.fr>, Janne Grunau <j@jannau.net> Cc: Alex Deucher <alexander.deucher@amd.com>, =?utf-8?q?Christian_K=C3=B6nig?= <christian.koenig@amd.com>, "Pan, Xinhui" <Xinhui.Pan@amd.com>, Harry Wentland <harry.wentland@amd.com>, Leo Li <sunpeng.li@amd.com>, Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>, Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de>, Jani Nikula <jani.nikula@linux.intel.com>, Joonas Lahtinen <joonas.lahtinen@linux.intel.com>, Rodrigo Vivi <rodrigo.vivi@intel.com>, Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org Subject: [PATCH 3/4] drm/uapi: document the USB subconnector type Date: Sat, 29 Jul 2023 03:49:12 +0300 Message-Id: <20230729004913.215872-4-dmitry.baryshkov@linaro.org> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230729004913.215872-1-dmitry.baryshkov@linaro.org> References: <20230729004913.215872-1-dmitry.baryshkov@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE, URIBL_BLOCKED autolearn=ham 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1772740210610081641 X-GMAIL-MSGID: 1772740210610081641 |
Series |
drm/bridge-connector: simplify handling of USB-C DP
|
|
Commit Message
Dmitry Baryshkov
July 29, 2023, 12:49 a.m. UTC
To properly define the USB-C DP altmode connectors, add the USB
subconnector type.
Suggested-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
drivers/gpu/drm/drm_connector.c | 1 +
include/uapi/drm/drm_mode.h | 1 +
2 files changed, 2 insertions(+)
Comments
Hi Dmitry, Thank you for the patch. On Sat, Jul 29, 2023 at 03:49:12AM +0300, Dmitry Baryshkov wrote: > To properly define the USB-C DP altmode connectors, add the USB > subconnector type. > > Suggested-by: Simon Ser <contact@emersion.fr> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > --- > drivers/gpu/drm/drm_connector.c | 1 + > include/uapi/drm/drm_mode.h | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c > index a6066e4a5e9a..9e96b038f5d0 100644 > --- a/drivers/gpu/drm/drm_connector.c > +++ b/drivers/gpu/drm/drm_connector.c > @@ -1050,6 +1050,7 @@ static const struct drm_prop_enum_list drm_dp_subconnector_enum_list[] = { > { DRM_MODE_SUBCONNECTOR_DisplayPort, "DP" }, /* DP */ > { DRM_MODE_SUBCONNECTOR_Wireless, "Wireless" }, /* DP */ > { DRM_MODE_SUBCONNECTOR_Native, "Native" }, /* DP */ > + { DRM_MODE_SUBCONNECTOR_USB, "USB" }, /* DP */ Should this be DRM_MODE_SUBCONNECTOR_USB_C and "USB-C", in case we get another USB type later ? > }; > > DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name, > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h > index 92d96a2b6763..0f74918b011c 100644 > --- a/include/uapi/drm/drm_mode.h > +++ b/include/uapi/drm/drm_mode.h > @@ -398,6 +398,7 @@ enum drm_mode_subconnector { > DRM_MODE_SUBCONNECTOR_HDMIA = 11, /* DP */ > DRM_MODE_SUBCONNECTOR_Native = 15, /* DP */ > DRM_MODE_SUBCONNECTOR_Wireless = 18, /* DP */ > + DRM_MODE_SUBCONNECTOR_USB = 20, /* DP */ > }; > > #define DRM_MODE_CONNECTOR_Unknown 0
On 02/08/2023 21:55, Laurent Pinchart wrote: > Hi Dmitry, > > Thank you for the patch. > > On Sat, Jul 29, 2023 at 03:49:12AM +0300, Dmitry Baryshkov wrote: >> To properly define the USB-C DP altmode connectors, add the USB >> subconnector type. >> >> Suggested-by: Simon Ser <contact@emersion.fr> >> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> >> --- >> drivers/gpu/drm/drm_connector.c | 1 + >> include/uapi/drm/drm_mode.h | 1 + >> 2 files changed, 2 insertions(+) >> >> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c >> index a6066e4a5e9a..9e96b038f5d0 100644 >> --- a/drivers/gpu/drm/drm_connector.c >> +++ b/drivers/gpu/drm/drm_connector.c >> @@ -1050,6 +1050,7 @@ static const struct drm_prop_enum_list drm_dp_subconnector_enum_list[] = { >> { DRM_MODE_SUBCONNECTOR_DisplayPort, "DP" }, /* DP */ >> { DRM_MODE_SUBCONNECTOR_Wireless, "Wireless" }, /* DP */ >> { DRM_MODE_SUBCONNECTOR_Native, "Native" }, /* DP */ >> + { DRM_MODE_SUBCONNECTOR_USB, "USB" }, /* DP */ > > Should this be DRM_MODE_SUBCONNECTOR_USB_C and "USB-C", in case we get > another USB type later ? Hmm, which id should I use for micro-USB then? (consider anx7808, SlimPort). I thought about using DRM_MODE_SUBCONNECTOR_USB for both of them. But maybe I should add another subtype for SlimPort. > >> }; >> >> DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name, >> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h >> index 92d96a2b6763..0f74918b011c 100644 >> --- a/include/uapi/drm/drm_mode.h >> +++ b/include/uapi/drm/drm_mode.h >> @@ -398,6 +398,7 @@ enum drm_mode_subconnector { >> DRM_MODE_SUBCONNECTOR_HDMIA = 11, /* DP */ >> DRM_MODE_SUBCONNECTOR_Native = 15, /* DP */ >> DRM_MODE_SUBCONNECTOR_Wireless = 18, /* DP */ >> + DRM_MODE_SUBCONNECTOR_USB = 20, /* DP */ >> }; >> >> #define DRM_MODE_CONNECTOR_Unknown 0 >
On Wed, Aug 02, 2023 at 10:01:19PM +0300, Dmitry Baryshkov wrote: > On 02/08/2023 21:55, Laurent Pinchart wrote: > > Hi Dmitry, > > > > Thank you for the patch. > > > > On Sat, Jul 29, 2023 at 03:49:12AM +0300, Dmitry Baryshkov wrote: > >> To properly define the USB-C DP altmode connectors, add the USB > >> subconnector type. > >> > >> Suggested-by: Simon Ser <contact@emersion.fr> > >> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > >> --- > >> drivers/gpu/drm/drm_connector.c | 1 + > >> include/uapi/drm/drm_mode.h | 1 + > >> 2 files changed, 2 insertions(+) > >> > >> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c > >> index a6066e4a5e9a..9e96b038f5d0 100644 > >> --- a/drivers/gpu/drm/drm_connector.c > >> +++ b/drivers/gpu/drm/drm_connector.c > >> @@ -1050,6 +1050,7 @@ static const struct drm_prop_enum_list drm_dp_subconnector_enum_list[] = { > >> { DRM_MODE_SUBCONNECTOR_DisplayPort, "DP" }, /* DP */ > >> { DRM_MODE_SUBCONNECTOR_Wireless, "Wireless" }, /* DP */ > >> { DRM_MODE_SUBCONNECTOR_Native, "Native" }, /* DP */ > >> + { DRM_MODE_SUBCONNECTOR_USB, "USB" }, /* DP */ > > > > Should this be DRM_MODE_SUBCONNECTOR_USB_C and "USB-C", in case we get > > another USB type later ? > > Hmm, which id should I use for micro-USB then? (consider anx7808, > SlimPort). I thought about using DRM_MODE_SUBCONNECTOR_USB for both of > them. But maybe I should add another subtype for SlimPort. I suppose it depends on whether userspace needs a way to differentiate those. Do you have a good visibility on the userspace use cases ? > >> }; > >> > >> DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name, > >> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h > >> index 92d96a2b6763..0f74918b011c 100644 > >> --- a/include/uapi/drm/drm_mode.h > >> +++ b/include/uapi/drm/drm_mode.h > >> @@ -398,6 +398,7 @@ enum drm_mode_subconnector { > >> DRM_MODE_SUBCONNECTOR_HDMIA = 11, /* DP */ > >> DRM_MODE_SUBCONNECTOR_Native = 15, /* DP */ > >> DRM_MODE_SUBCONNECTOR_Wireless = 18, /* DP */ > >> + DRM_MODE_SUBCONNECTOR_USB = 20, /* DP */ > >> }; > >> > >> #define DRM_MODE_CONNECTOR_Unknown 0
2 августа 2023 г. 22:13:51 GMT+03:00, Laurent Pinchart <laurent.pinchart@ideasonboard.com> пишет: >On Wed, Aug 02, 2023 at 10:01:19PM +0300, Dmitry Baryshkov wrote: >> On 02/08/2023 21:55, Laurent Pinchart wrote: >> > Hi Dmitry, >> > >> > Thank you for the patch. >> > >> > On Sat, Jul 29, 2023 at 03:49:12AM +0300, Dmitry Baryshkov wrote: >> >> To properly define the USB-C DP altmode connectors, add the USB >> >> subconnector type. >> >> >> >> Suggested-by: Simon Ser <contact@emersion.fr> >> >> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> >> >> --- >> >> drivers/gpu/drm/drm_connector.c | 1 + >> >> include/uapi/drm/drm_mode.h | 1 + >> >> 2 files changed, 2 insertions(+) >> >> >> >> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c >> >> index a6066e4a5e9a..9e96b038f5d0 100644 >> >> --- a/drivers/gpu/drm/drm_connector.c >> >> +++ b/drivers/gpu/drm/drm_connector.c >> >> @@ -1050,6 +1050,7 @@ static const struct drm_prop_enum_list drm_dp_subconnector_enum_list[] = { >> >> { DRM_MODE_SUBCONNECTOR_DisplayPort, "DP" }, /* DP */ >> >> { DRM_MODE_SUBCONNECTOR_Wireless, "Wireless" }, /* DP */ >> >> { DRM_MODE_SUBCONNECTOR_Native, "Native" }, /* DP */ >> >> + { DRM_MODE_SUBCONNECTOR_USB, "USB" }, /* DP */ >> > >> > Should this be DRM_MODE_SUBCONNECTOR_USB_C and "USB-C", in case we get >> > another USB type later ? >> >> Hmm, which id should I use for micro-USB then? (consider anx7808, >> SlimPort). I thought about using DRM_MODE_SUBCONNECTOR_USB for both of >> them. But maybe I should add another subtype for SlimPort. > >I suppose it depends on whether userspace needs a way to differentiate >those. Do you have a good visibility on the userspace use cases ? No. I'm not even sure, which userspace handles subtypes properly. For the reference, SlimPort is mostly legacy hardware, think about Nexus 4, 5, 6, 7 (2013) > >> >> }; >> >> >> >> DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name, >> >> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h >> >> index 92d96a2b6763..0f74918b011c 100644 >> >> --- a/include/uapi/drm/drm_mode.h >> >> +++ b/include/uapi/drm/drm_mode.h >> >> @@ -398,6 +398,7 @@ enum drm_mode_subconnector { >> >> DRM_MODE_SUBCONNECTOR_HDMIA = 11, /* DP */ >> >> DRM_MODE_SUBCONNECTOR_Native = 15, /* DP */ >> >> DRM_MODE_SUBCONNECTOR_Wireless = 18, /* DP */ >> >> + DRM_MODE_SUBCONNECTOR_USB = 20, /* DP */ >> >> }; >> >> >> >> #define DRM_MODE_CONNECTOR_Unknown 0 >
On Wednesday, August 2nd, 2023 at 21:23, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote: > >> >> + { DRM_MODE_SUBCONNECTOR_USB, "USB" }, /* DP */ > >> > > >> > Should this be DRM_MODE_SUBCONNECTOR_USB_C and "USB-C", in case we get > >> > another USB type later ? > >> > >> Hmm, which id should I use for micro-USB then? (consider anx7808, > >> SlimPort). I thought about using DRM_MODE_SUBCONNECTOR_USB for both of > >> them. But maybe I should add another subtype for SlimPort. > > > >I suppose it depends on whether userspace needs a way to differentiate > >those. Do you have a good visibility on the userspace use cases ? > > No. I'm not even sure, which userspace handles subtypes properly. wlroots uses it for human-readable output descriptions, e.g. > wayland-info interface: 'wl_output', version: 4, name: 49 name: DP-3 description: Samsung Electric Company SyncMaster HS3P505873 (DP-3 via DVI-D) The "via DVI-D" bit comes from subconnector. The description is displayed to the user when picking an output to screen capture, among other things. It is helpful to users because they can better understand why their output connected via DVI shows up as "DP". The KMS docs describe "subconnector" to be defined as "downstream port" for DP. Can USB-C (or USB) be seen as a DP downstream port?
On Thursday, August 3rd, 2023 at 17:22, Simon Ser <contact@emersion.fr> wrote: > The KMS docs describe "subconnector" to be defined as "downstream port" for DP. > Can USB-C (or USB) be seen as a DP downstream port? To expand on this a bit: I'm wondering if we're mixing apples and oranges here. The current values of "subconnector" typically describe the lower-level protocol tunneled inside DP. For instance, VGA can be tunneled inside the DP cable when using DP → VGA adapter. However, in the USB-C case, DP itself is tunneled inside USB-C. And you might use a USB-C → DP adapter. So it's not really *sub*connector, it's more of a *super*connector, right? I think [1] is somewhat related, since it also allows user-space to discover whether a connector uses USB-C. But relying on sysfs to figure this out isn't super optimal perhaps. [1]: https://lore.kernel.org/dri-devel/20221108185004.2263578-1-wonchung@google.com/
On Thu, 3 Aug 2023 at 18:31, Simon Ser <contact@emersion.fr> wrote: > > On Thursday, August 3rd, 2023 at 17:22, Simon Ser <contact@emersion.fr> wrote: > > > The KMS docs describe "subconnector" to be defined as "downstream port" for DP. > > Can USB-C (or USB) be seen as a DP downstream port? > > To expand on this a bit: I'm wondering if we're mixing apples and > oranges here. The current values of "subconnector" typically describe > the lower-level protocol tunneled inside DP. For instance, VGA can be > tunneled inside the DP cable when using DP → VGA adapter. My opinion hasn't changed: I think this should be the USB connector with proper DP / DVI / HDMI / etc. subconnector type (or lack of it). In the end, the physical connector on the side of laptop is USB-C. If we want to make it different from GUD, we might want to define a USB-DP connector type (which would also include SlimPort). > > However, in the USB-C case, DP itself is tunneled inside USB-C. And you > might use a USB-C → DP adapter. So it's not really *sub*connector, it's > more of a *super*connector, right? > > I think [1] is somewhat related, since it also allows user-space to > discover whether a connector uses USB-C. But relying on sysfs to figure > this out isn't super optimal perhaps. > > [1]: https://lore.kernel.org/dri-devel/20221108185004.2263578-1-wonchung@google.com/
On Thursday, August 3rd, 2023 at 17:36, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote: > On Thu, 3 Aug 2023 at 18:31, Simon Ser contact@emersion.fr wrote: > > > On Thursday, August 3rd, 2023 at 17:22, Simon Ser contact@emersion.fr wrote: > > > > > The KMS docs describe "subconnector" to be defined as "downstream port" for DP. > > > Can USB-C (or USB) be seen as a DP downstream port? > > > > To expand on this a bit: I'm wondering if we're mixing apples and > > oranges here. The current values of "subconnector" typically describe > > the lower-level protocol tunneled inside DP. For instance, VGA can be > > tunneled inside the DP cable when using DP → VGA adapter. > > My opinion hasn't changed: I think this should be the USB connector > with proper DP / DVI / HDMI / etc. subconnector type (or lack of it). > In the end, the physical connector on the side of laptop is USB-C. - Even if the connector is USB-C, the protocol used for display is still DP. There's also the case of Thunderbolt. - This is inconsistent with existing drivers. i915 and amdgpu expose DP ports for their USB-C ports. Changing that isn't possible without causing user-space regressions (compositor config files use the connector type).
On Thu, 3 Aug 2023 at 18:43, Simon Ser <contact@emersion.fr> wrote: > > On Thursday, August 3rd, 2023 at 17:36, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote: > > > On Thu, 3 Aug 2023 at 18:31, Simon Ser contact@emersion.fr wrote: > > > > > On Thursday, August 3rd, 2023 at 17:22, Simon Ser contact@emersion.fr wrote: > > > > > > > The KMS docs describe "subconnector" to be defined as "downstream port" for DP. > > > > Can USB-C (or USB) be seen as a DP downstream port? > > > > > > To expand on this a bit: I'm wondering if we're mixing apples and > > > oranges here. The current values of "subconnector" typically describe > > > the lower-level protocol tunneled inside DP. For instance, VGA can be > > > tunneled inside the DP cable when using DP → VGA adapter. > > > > My opinion hasn't changed: I think this should be the USB connector > > with proper DP / DVI / HDMI / etc. subconnector type (or lack of it). > > In the end, the physical connector on the side of laptop is USB-C. > > - Even if the connector is USB-C, the protocol used for display is > still DP. There's also the case of Thunderbolt. Yes. But the connector type is not about the protocol. > - This is inconsistent with existing drivers. i915 and amdgpu expose > DP ports for their USB-C ports. Changing that isn't possible without > causing user-space regressions (compositor config files use the > connector type). Yes, I know. Consider my phrase as a personal opinion or minority report. I think that using DisplayPort for USB-C connectors was a mistake, which we now have to cope with somehow.
On Thu, Aug 03, 2023 at 03:31:16PM +0000, Simon Ser wrote: > On Thursday, August 3rd, 2023 at 17:22, Simon Ser <contact@emersion.fr> wrote: > > > The KMS docs describe "subconnector" to be defined as "downstream port" for DP. > > Can USB-C (or USB) be seen as a DP downstream port? > > To expand on this a bit: I'm wondering if we're mixing apples and > oranges here. The current values of "subconnector" typically describe > the lower-level protocol tunneled inside DP. For instance, VGA can be > tunneled inside the DP cable when using DP → VGA adapter. Doesn't this contradict the example use case you gave in your previous e-mail, with wlroots stating "DP-3 via DVI-D" ? I understand that as DP carried over a DVI-D physical connector, did I get it wrong ? > However, in the USB-C case, DP itself is tunneled inside USB-C. And you > might use a USB-C → DP adapter. So it's not really *sub*connector, it's > more of a *super*connector, right? > > I think [1] is somewhat related, since it also allows user-space to > discover whether a connector uses USB-C. But relying on sysfs to figure > this out isn't super optimal perhaps. > > [1]: https://lore.kernel.org/dri-devel/20221108185004.2263578-1-wonchung@google.com/
On Thursday, August 3rd, 2023 at 22:44, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > On Thu, Aug 03, 2023 at 03:31:16PM +0000, Simon Ser wrote: > > > On Thursday, August 3rd, 2023 at 17:22, Simon Ser contact@emersion.fr wrote: > > > > > The KMS docs describe "subconnector" to be defined as "downstream port" for DP. > > > Can USB-C (or USB) be seen as a DP downstream port? > > > > To expand on this a bit: I'm wondering if we're mixing apples and > > oranges here. The current values of "subconnector" typically describe > > the lower-level protocol tunneled inside DP. For instance, VGA can be > > tunneled inside the DP cable when using DP → VGA adapter. > > Doesn't this contradict the example use case you gave in your previous > e-mail, with wlroots stating "DP-3 via DVI-D" ? I understand that as DP > carried over a DVI-D physical connector, did I get it wrong ? No, this is DVI carried over DP. DP cannot be carried over VGA/DVI/HDMI, but VGA/DVI/HDMI can be carried over DP.
On Thu, 3 Aug 2023 at 23:47, Simon Ser <contact@emersion.fr> wrote: > > On Thursday, August 3rd, 2023 at 22:44, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > > > On Thu, Aug 03, 2023 at 03:31:16PM +0000, Simon Ser wrote: > > > > > On Thursday, August 3rd, 2023 at 17:22, Simon Ser contact@emersion.fr wrote: > > > > > > > The KMS docs describe "subconnector" to be defined as "downstream port" for DP. > > > > Can USB-C (or USB) be seen as a DP downstream port? > > > > > > To expand on this a bit: I'm wondering if we're mixing apples and > > > oranges here. The current values of "subconnector" typically describe > > > the lower-level protocol tunneled inside DP. For instance, VGA can be > > > tunneled inside the DP cable when using DP → VGA adapter. > > > > Doesn't this contradict the example use case you gave in your previous > > e-mail, with wlroots stating "DP-3 via DVI-D" ? I understand that as DP > > carried over a DVI-D physical connector, did I get it wrong ? > > No, this is DVI carried over DP. DP cannot be carried over VGA/DVI/HDMI, > but VGA/DVI/HDMI can be carried over DP. Well, not quite. It means that the sink (display) connected to this port identifies itself as an VGA / DVI / HDMI monitor. E.g. on if connect HDMI/DVI monitor through the DP-DVI dongle (native DP connector), AMD driver still identifies it as 'subconnector HDMI', despite dongle a DVI connector on the other side.
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index a6066e4a5e9a..9e96b038f5d0 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -1050,6 +1050,7 @@ static const struct drm_prop_enum_list drm_dp_subconnector_enum_list[] = { { DRM_MODE_SUBCONNECTOR_DisplayPort, "DP" }, /* DP */ { DRM_MODE_SUBCONNECTOR_Wireless, "Wireless" }, /* DP */ { DRM_MODE_SUBCONNECTOR_Native, "Native" }, /* DP */ + { DRM_MODE_SUBCONNECTOR_USB, "USB" }, /* DP */ }; DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name, diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index 92d96a2b6763..0f74918b011c 100644 --- a/include/uapi/drm/drm_mode.h +++ b/include/uapi/drm/drm_mode.h @@ -398,6 +398,7 @@ enum drm_mode_subconnector { DRM_MODE_SUBCONNECTOR_HDMIA = 11, /* DP */ DRM_MODE_SUBCONNECTOR_Native = 15, /* DP */ DRM_MODE_SUBCONNECTOR_Wireless = 18, /* DP */ + DRM_MODE_SUBCONNECTOR_USB = 20, /* DP */ }; #define DRM_MODE_CONNECTOR_Unknown 0