Re: [RFC PATCH v1 00/12] drm,usb/typec: uABI for USB-C DisplayPort connectors

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 04/09/2023 18:46, Bjorn Andersson wrote:
On Mon, Sep 04, 2023 at 12:41:38AM +0300, Dmitry Baryshkov wrote:
During the discussion regarding DisplayPort wrapped in the USB-C
connectors (via the USB-C altmode) it was pointed out that currently
there is no good way to let userspace know if the DRM connector in
question is the 'native' DP connector or if it is the USB-C connector.

An attempt to use DRM_MODE_CONNECTOR_USB for such connectors was
declined, as existing DP drivers (i915, AMD) use
DRM_MODE_CONNECTOR_DisplayPort. New drivers should behave in the same
way.


Sorry, didn't see the commit message before posting my complaint about
USB -> DisplayPort.

An attempt to use subconnector property was also declined. It is defined
to the type of the DP dongle connector rather than the host connector.

This attempt targets reusing the connector's PATH property. Currently
this property is only used for the DP MST connectors. This patchset
reuses it to point out to the corresponding registered typec port
device.


Still interested in understanding how the path string should look like.

As wrote in the other letter, on RB5 it is 'typec:port0'. If the machine has two Type-C ports and two connected DP blocks, one of them will have 'typec:port0', another one 'typec:port1'. This way one can further look under /sys/class/typec/portN/physical_localtion/ and find corresponding location, etc.

Is the path expected to be consumed by machine, or is it only there for
human convenience?

As with DP MST it is expected that userspace will consume this information, possibly renaming the connector. For example, on my laptop I have DP-1, ... DP-5 connectors (with DP-2 -- DP-5 being DP MST ones). Xorg renames them to DP-1, DP-2, DP-1-1, DP-1-2, DP-1-3, because the MST ones are branches for the DP-1.

--
With best wishes
Dmitry




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux