Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 1 Dec 2020 11:08:23 -0700
From:      Scott Long <scottl@samsco.org>
To:        Ali Abdallah <ali.abdallah@suse.com>
Cc:        myfreeweb <greg@unrelenting.technology>, freebsd-current@freebsd.org, Hans Petter Selasky <hps@selasky.org>, Scott Long <scottl@FreeBSD.org>
Subject:   Re: Issues with USB-C external monitors
Message-ID:  <68205920-BE4F-460D-BF70-1A84FE3BC536@samsco.org>
In-Reply-To: <20201201173223.mwmrkogcjmtc4k2j@frix230>
References:  <20201201131430.ol7pzms24h743iwf@frix230> <342519ee-6f73-98be-29b1-cea7890ccb1e@selasky.org> <BD186C8D-AF73-4182-BF89-89005854F618@unrelenting.technology> <20201201173223.mwmrkogcjmtc4k2j@frix230>

next in thread | previous in thread | raw e-mail | index | archive | help

> On Dec 1, 2020, at 10:32 AM, Ali Abdallah <ali.abdallah@suse.com> =
wrote:
>=20
> On 01.12.2020 17:10, myfreeweb wrote:
>>>> __snippet__
>>>> res =3D drmModeGetResources(fd);
>>>> for (int i =3D 0; i < res->count_connectors; ++i) {
>>>>    conn =3D drmModeGetConnector(fd, res->connectors[i]);
>>=20
>> Note: you can run graphics/drm_info instead of writing custom code.
>=20
> Thanks for the tip.
>=20
>> devd (really drm in the kernel) provides hotplug events (system DRM, =
type HOTPLUG).
>> libudev-devd translates these to UD_ACTION_HOTPLUG.
>> This works well with wlroots compositors at least.
>>=20
>> How xorg does this I have no idea, as I don't use xorg.
>> If your xorg is built with DEVD instead of UDEV option, it shouldn't =
work, I don't recall anyone adding support for that there.
>> With UDEV it might work?
>=20
> On current, for now I'm using the standard xorg-server from pkg, built
> with UDEV according to [1], so apparently that is not working either. =
At
> least in my case.
>=20
> Will dig futher into it.
>=20
>>=20
>>> There is missing code in the kernel to handle USB-C PCI express
>>> attach/detach. CC'ing Scott Long.
>>=20
>> Seems like this is about regular DisplayPort over USB-C (the USB side =
almost always handled in firmware for this on non-embedded computers).
>> I don't think I've ever seen a *monitor* connecting over PCIe to an =
existing GPU ;)
>> (in this case card0, the onboard vega)
>=20
> Yes, this is just the DisplayPort over USB-C from the onboard vega =
GPU.
>=20
> [1] https://www.freshports.org/x11-servers/xorg-server/
>=20
>=20

I have a work-in-progress to support Thunderbolt, but that=E2=80=99s not =
always the same as just DisplayPort-over-USBC.  If your connector has =
the Thunderbolt logo, then it=E2=80=99s Thunderbolt, if it has the DP =
logo then it=E2=80=99s not.  Even then, the Thunderbolt component only =
controls enable/disable permissions and bandwidth partitioning.  The =
graphics chip and DRM code does the rest of the work, and it sounds like =
the problems here are with those components.

Scott




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?68205920-BE4F-460D-BF70-1A84FE3BC536>