Re: Issues with USB-C external monitors

> On Dec 1, 2020, at 10:32 AM, Ali Abdallah <ali.abdallah_at_suse.com> wrote:
> 
> On 01.12.2020 17:10, myfreeweb wrote:
>>>> __snippet__
>>>> res = drmModeGetResources(fd);
>>>> for (int i = 0; i < res->count_connectors; ++i) {
>>>>    conn = drmModeGetConnector(fd, res->connectors[i]);
>> 
>> Note: you can run graphics/drm_info instead of writing custom code.
> 
> Thanks for the tip.
> 
>> 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.
>> 
>> 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?
> 
> 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.
> 
> Will dig futher into it.
> 
>> 
>>> There is missing code in the kernel to handle USB-C PCI express
>>> attach/detach. CC'ing Scott Long.
>> 
>> 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)
> 
> Yes, this is just the DisplayPort over USB-C from the onboard vega GPU.
> 
> [1] https://www.freshports.org/x11-servers/xorg-server/
> 
> 

I have a work-in-progress to support Thunderbolt, but that’s not always the same as just DisplayPort-over-USBC.  If your connector has the Thunderbolt logo, then it’s Thunderbolt, if it has the DP logo then it’s 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