TL;DR: very weird behaviour, but actually workable. (Though only in one USB-C orientation). Probably fixable?
USB-C mini-dock by LMP (it's the standard issue for Mac Books, etc. at my employer (ETHZ) )
Identifies on the USB as:
- Bus 008 Device 075: ID 058f:8468 Alcor Micro Corp.
- Bus 008 Device 076: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter
- Bus 008 Device 074: ID 0bda:0411 Realtek Semiconductor Corp.
- Bus 008 Device 073: ID 2109:0813 VIA Labs, Inc. USB3.0 Hub
Tree:
Code:
/: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
|__ Port 1: Dev 73, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 2: Dev 74, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 1: Dev 76, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
|__ Port 4: Dev 75, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
According to specs, this dock is both able to do UHD (4K at 60, etc.) and USB-3 (+ Network, SD and µSD over USB).
(So probably it's capable to dynamically remap the high speed lanes to either USB 3 and/or DisplayPort as needed)
I'm using it on Manjaro ARM which uses the latest upstream 5.4 kernel.
Now the weirdness:
When plugging the USB-C in one orientation, never works, except charging.
When I plug everything (with charger) and the USB-C in the other orientation (just reverse the connector, turning the USB-C the other way around), the dock keep cycling on/off as long as there is USB-PD powering.
Weirdness increases:
If I time correctly and unplug the USB-PD at the right moment (e.g.: by watching stuff getting detected and cycled on the `journalctl --follow`), the dock stops cycling at a moment when the DP-to-HDMI output converter is detected (I can see the monitor on output DP-1 in `xrandr`).
I can then set the monitor enabled and the resolution to something that only uses 2 out of the 4 high speed lanes (e.g.: 1920x1080 @24fps).
From that point onward, every thing (HDMI, USB-PD charging, USB3 hub, Ethernet and SD/µSD reader) work reliably even when unplugging/re-plugging.
But only in this orientations.
To me it seems like some race condition happening between the OS trying to enumerate everything available (USB-PD, everything on USB-3, all the display modes on DP) and the drivers assigning high-speed lanes to either USB-3 or HDMI (probing 4K @60Hz requires 4 DisplayPort lanes, which would yank out the two USB3 lanes, which would trigger a rescan of the USB-3, etc. thus the on/off cycles).
(
I've pinged the mainline kernel dev in the other thread).