| Message ID | 20230729004913.215872-4-dmitry.baryshkov@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | drm/bridge-connector: simplify handling of USB-C DP | expand |
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.
Simon, Laurent, On 03/08/2023 23:46, Simon Ser 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. Please excuse me for the long delay, I was on vacation. Several notes on the subconnector topic. For TV and DVI-I we are really identifying a connector (or a part of the connector pins) present on the device. So, we can have e.g. following combinations (type / subtype): DVI-I / DVI-D (digital part of DVI connector) DVI-I / DVI-A (analog part of DVI connector) TV / S-Video (full S-Video connector) TV / Composite (either a separate Composite connector, or shared with S-Video) etc. For DP unfortunately we have mixed everything together. The physical connector present on the device can be DP / miniDP or USB-C (or micro-USB for SlimPort). The physical protocol can be DP or DVI / HDMI (but only for dual-mode DP ports). Over USB-C link the DP can be transferred using DP or USB signal levels. And last, but not least, we have the dongle / display connector type, which can be VGA (for active DP -> VGA converters), HDMI, DVI, DP, etc. If we were designing this from the scratch, I'd say that we should encode physical connector type to DRM connector type and the dongle type to subconnector. However AMD and Intel drivers have already reused DisplayPort connector type for USB-C connections. Subconnector type represents (if known) the type of downstream / dongle port. I'm not going to judge whether this was correct or not. We have to live with this and behave in a similar way. We have been looking for a way to document that the corresponding DP port is represented by the USB connector on the device. Consequently, I believe the best way to document it, would be to use DisplayPort / USB, when there is no dongle connected, switching to DisplayPort / HDMI, DisplayPort / VGA, DisplayPort / DisplayPort, etc. when the actual dongle / display is connected and then switching back to the DisplayPort / USB when it gets disconnected. If this sounds good to all parties, I'll post v2, adding this explanation to the cover letter.
On Thursday, August 17th, 2023 at 21:33, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote: > We have been looking for a way to document that the corresponding DP > port is represented by the USB connector on the device. > > Consequently, I believe the best way to document it, would be to use > DisplayPort / USB, when there is no dongle connected, switching to > DisplayPort / HDMI, DisplayPort / VGA, DisplayPort / DisplayPort, etc. > when the actual dongle / display is connected and then switching back to > the DisplayPort / USB when it gets disconnected. > > If this sounds good to all parties, I'll post v2, adding this > explanation to the cover letter. But how can user-space discover that the port is USB-C when it's connected? That information is lost at this point. (In addition, this clashes with the existing semantics of the subconnector prop as discussed before: USB-C is not sub-, it's super-.)
On 18/08/2023 09:24, Simon Ser wrote: > On Thursday, August 17th, 2023 at 21:33, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote: > >> We have been looking for a way to document that the corresponding DP >> port is represented by the USB connector on the device. >> >> Consequently, I believe the best way to document it, would be to use >> DisplayPort / USB, when there is no dongle connected, switching to >> DisplayPort / HDMI, DisplayPort / VGA, DisplayPort / DisplayPort, etc. >> when the actual dongle / display is connected and then switching back to >> the DisplayPort / USB when it gets disconnected. >> >> If this sounds good to all parties, I'll post v2, adding this >> explanation to the cover letter. > > But how can user-space discover that the port is USB-C when it's > connected? That information is lost at this point. Yes, unfortunately. > (In addition, this clashes with the existing semantics of the > subconnector prop as discussed before: USB-C is not sub-, it's super-.) Ok. How do we proceed then? Is it fine to add another property for DP case? Do you have any particular property name in mind? I will follow with addition of this property then.
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
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(+)