You are not logged in.
Hello Arch community,
I have a ThinkPad T14 Gen2 Intel running Arch Linux, and I’m experiencing an issue where my USB-C monitor is no longer detected as a display. The monitor was working fine before via USB-C, but it suddenly stopped being recognized after running pacman -Syu two days ago. I’ve tried various troubleshooting steps, including checking kernel logs and testing with different kernels, but I haven’t been able to resolve the issue.
System Information:
Laptop: ThinkPad T14 Gen2 (Intel)
OS: Arch Linux (fully updated)
Kernel: Tried both latest (6.13.8), LTS and linux-zen
Graphics: Intel iGPU (i915 module loaded)
Relevant Modules Loaded: i915, thunderbolt, typec, typec_ucsi, typec_displayport
Issue Description:
The USB-C monitor was previously working (I suppose via DP Alt Mode) but is now not detected.
It still works fine when connected via HDMI but I need the only HDMI slot in my laptop to connect my other external monitor
xrandr does not show any new display when the monitor is plugged in.
xrandr --listmonitors shows only my laptop's monitor and my other monitor connected over HDMI:
Monitors: 2
0: +eDP-1 1920/310x1080/170+0+0 eDP-1
1: +HDMI-A-1 1920/530x1080/300+1920+0 HDMI-A-1cat /proc/cmdline:
BOOT_IMAGE=/vmlinuz-linux-lts root=/dev/mapper/volgroup0-lv_root rw loglevel=3 cryptdevice=/dev/nvme0n1p3:volgroup0 quietjournalctl | grep -iE "typec|thunderbolt|dp-alt" logs show messages like:
Mar 24 02:32:00 archlinux kernel: i915 0000:00:02.0: [drm:intel_tc_port_update_mode [i915]] Port E/TC#2: TC port mode reset (disconnected -> dp-alt)
Mar 24 02:32:02 archlinux kernel: i915 0000:00:02.0: [drm:intel_tc_port_update_mode [i915]] Port E/TC#2: TC port mode reset (dp-alt -> disconnected)This suggests that DP Alt Mode is attempting to activate but then immediately disconnects.
dmesg -w when plugging in the second external monitor via usb-c:
[ 771.257858] usb 3-5: new high-speed USB device number 10 using xhci_hcd
[ 771.459261] usb 3-5: New USB device found, idVendor=05e3, idProduct=0610, bcdDevice=76.31
[ 771.459266] usb 3-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 771.459268] usb 3-5: Product: USB2.1 Hub
[ 771.459269] usb 3-5: Manufacturer: GenesysLogic
[ 771.461756] hub 3-5:1.0: USB hub found
[ 771.462031] hub 3-5:1.0: 4 ports detected
[ 771.764514] usb 3-5.4: new high-speed USB device number 11 using xhci_hcd
[ 771.878895] usb 3-5.4: New USB device found, idVendor=05e3, idProduct=0608, bcdDevice=89.32
[ 771.878901] usb 3-5.4: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[ 771.878904] usb 3-5.4: Product: USB2.0 Hub
[ 771.879888] hub 3-5.4:1.0: USB hub found
[ 771.880132] hub 3-5.4:1.0: 4 ports detected
[ 772.161171] usb 3-5.4.1: new high-speed USB device number 12 using xhci_hcd
[ 772.244092] usb 3-5.4.1: New USB device found, idVendor=0bda, idProduct=8153, bcdDevice=31.00
[ 772.244099] usb 3-5.4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[ 772.244100] usb 3-5.4.1: Product: USB 10/100/1000 LAN
[ 772.244101] usb 3-5.4.1: Manufacturer: Realtek
[ 772.244103] usb 3-5.4.1: SerialNumber: 001000000
[ 772.244198] usbip-host 3-5.4.1: 3-5.4.1 is not in match_busid table... skip!
[ 772.311386] r8152-cfgselector 3-5.4.1: reset high-speed USB device number 12 using xhci_hcd
[ 772.458332] r8152 3-5.4.1:1.0 eth0: v1.12.13
[ 772.527854] usb 3-5.4.2: new full-speed USB device number 13 using xhci_hcd
[ 772.621729] usb 3-5.4.2: New USB device found, idVendor=04e8, idProduct=f649, bcdDevice= 0.00
[ 772.621734] usb 3-5.4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 772.621736] usb 3-5.4.2: Product: Samsung Type-C Monitor
[ 772.621737] usb 3-5.4.2: Manufacturer: Cypress Semiconductor
[ 772.621738] usb 3-5.4.2: SerialNumber: 11AD1D04E7B34006412B0B00
[ 772.635142] hid-generic 0003:04E8:F649.0004: hiddev96,hidraw2: USB HID v1.11 Device [Cypress Semiconductor Samsung Type-C Monitor] on usb-0000:00:14.0-5.4.2/input1
[ 772.647577] r8152 3-5.4.1:1.0 enp0s20f0u5u4u1: renamed from eth0
[ 781.296548] r8152-cfgselector 3-5.4.1: USB disconnect, device number 12
[ 781.296716] r8152 3-5.4.1:1.0 enp0s20f0u5u4u1: Stop submitting intr, status -108cat xorg.0.log | grep EE
[ 321.513] Current Operating System: Linux ianvs 6.1.24-1-lts #1 SMP PREEMPT_DYNAMIC Thu, 13 Apr 2023 17:22:35 +0000 x86_64
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 321.555] (EE) Failed to load module "intel" (module does not exist, 0)
[ 321.556] (EE) Failed to load module "fbdev" (module does not exist, 0)
[ 321.557] (EE) Failed to load module "vesa" (module does not exist, 0)
[ 321.896] (II) Initializing extension MIT-SCREEN-SAVER
[ 415.998] (EE) systemd-logind: failed to release device: Device not takenlsmod | grep "i915\|thunderbolt\|usb\|typec" confirms that all relevant modules are loaded (thunderbold not used though):
usbnet 61440 2 r8153_ecm,cdc_ether
mii 16384 2 usbnet,r8152
usbhid 86016 0
typec_displayport 24576 1
btusb 77824 0
btrtl 32768 1 btusb
btintel 69632 1 btusb
btbcm 24576 1 btusb
btmtk 32768 1 btusb
bluetooth 1101824 38 btrtl,btmtk,btintel,btbcm,bnep,btusb,rfcomm
typec_ucsi 77824 1 ucsi_acpi
typec 110592 2 typec_displayport,typec_ucsi
thunderbolt 573440 0
roles 16384 1 typec_ucsi
usbip_host 49152 0
usbip_core 36864 1 usbip_host
i915 4583424 34
i2c_algo_bit 20480 2 xe,i915
drm_buddy 24576 2 xe,i915
ttm 106496 3 drm_ttm_helper,xe,i915
intel_gtt 28672 1 i915
drm_display_helper 270336 2 xe,i915
video 81920 3 thinkpad_acpi,xe,i915
cec 94208 3 drm_display_helper,xe,i915/sys/class/typec/port0-partner/* shows the monitor is at least detected as a partner but not as a display.
cat /sys/class/drm/card1-DP-*/status shows all DP outputs as disconnected.
disconnected
disconnected
disconnected
disconnectedSteps Taken:
Tested with different kernels (6.13.7 and 6.13.8 (both were flagged out of date)) and LTS)
Verified DisplayPort Alt Mode support (should be supported by my hardware)
Checked lsmod and sysfs for loaded modules and detected partners
Tried another USB-C cable that also explicitly supports DP Alt mode to rule out hardware issues
Complete log files:
last boot before system update was done
boot where system update was done
last boot before problem occurred
boot when problem occurred
dmesg-all
xorg.0.log
Questions:
1. How can I further debug why DP Alt Mode is failing?
2. Are there any kernel parameters or module options that could help?
3. Could this be a regression in a recent kernel update?
4. Is there a way to force DP Alt Mode activation manually?
Last edited by romkov (2025-03-29 14:11:28)
Offline
I forgot to mention:
I performed a firmware update using fwupd after the issue started, as an attempt to resolve it, but it didn’t change anything.
Additionally, I used to use SDDM as my display manager, and I disabled it to see if that would make a difference.
Also, I'm using Wayland with Hyprland, so if there are any Wayland-specific factors that could affect DisplayPort Alt Mode or USB-C display detection, I’d appreciate any insights.
Any help would be very appreciated!
Offline
[ 321.513] (==) Log file: "/home/romkov/.local/share/xorg/Xorg.0.log", Time: Wed Apr 26 20:11:12 2023The xorg log is vastly dated, sddm stores the X11 log in /var/log resp. since it's apprently running rootless now: /var/lib/sddm/.local/share/xorg/Xorg.0.log
Does the problem also exist w/ SDDM or only
Mar 23 19:00:22 archlinux sddm[1383]: Reading from "/usr/share/wayland-sessions/hyprland.desktop"hyprland?
"TC port mode reset" does not show up in http://0x0.st/8j9P.txt ("when problem occurred") - actually there's no error logged at all.
Does the problem exist w/ and openbox or i3wm session on X11?
What does the "xrandr -q" output there look like?
What about "hyprctl monitors" (on hyprland)?
https://wiki.archlinux.org/title/Hyprla … resolution
Offline
You're right, outdated Xorg.log file, it was from ~/.local/share/xorg/Xorg.0.log
Thanks for pointing out.
/var/lib/sddm/.local/share/xorg/Xorg.0.log
/var/log/Xorg.0.log
Disabling SDDM didn't change anything.
Both "hyprctl monitors" and "hyprctl monitors all" show also only the 2 monitors output but not the third usb-c connected one:
Monitor eDP-1 (ID 0):
1920x1080@60.03300 at 0x0
description: AU Optronics 0x573D
make: AU Optronics
model: 0x573D
serial:
active workspace: 8 (8)
special workspace: 0 ()
reserved: 0 28 0 0
scale: 1.00
transform: 0
focused: no
dpmsStatus: 1
vrr: false
solitary: 0
activelyTearing: false
directScanoutTo: 0
disabled: false
currentFormat: XRGB8888
mirrorOf: none
availableModes: 1920x1080@60.03Hz
Monitor HDMI-A-1 (ID 1):
1920x1080@60.00000 at -1920x0
description: BNQ BenQ GL2450H K1E03656019
make: BNQ
model: BenQ GL2450H
serial: K1E03656019
active workspace: 2 (2)
special workspace: 0 ()
reserved: 0 0 0 0
scale: 1.00
transform: 0
focused: yes
dpmsStatus: 1
vrr: false
solitary: 0
activelyTearing: false
directScanoutTo: 0
disabled: false
currentFormat: XRGB8888
mirrorOf: none
availableModes: 1920x1080@60.00Hz 1920x1080@60.00Hz 1920x1080@59.94Hz 1920x1080@50.00Hz 1680x1050@59.88Hz 1600x900@60.00Hz 1280x1024@75.03Hz 1280x1024@60.02Hz 1280x800@59.91Hz 1152x864@75.00Hz 1280x720@60.00Hz 1280x720@60.00Hz 1280x720@59.94Hz 1280x720@50.00Hz 1024x768@75.03Hz 1024x768@60.00Hz 832x624@74.55Hz 800x600@75.00Hz 800x600@60.32Hz 720x576@50.00Hz 720x576@50.00Hz 720x480@60.00Hz 720x480@60.00Hz 720x480@59.94Hz 720x480@59.94Hz 720x480@59.94Hz 640x480@75.00Hz 640x480@60.00Hz 640x480@59.94Hz 640x480@59.94Hz 720x400@70.08HzI will try xrandr -q with openbox, i3 etc. and report back.
Thanks a lot so far!
Offline
The monitor doesn't show up in the xorg log and will likely not work in an X11 session.
suddenly stopped being recognized after running pacman -Syu two days ago
What was in that update?
Offline
A lot:
I downgraded some packages like mesa and as said before the kernels after this update, which didn't change anything.
Today I also did another full update since the kernel 6.13.7 was flagged out of date, but also no change.
Offline
libusb (1.0.27-1 -> 1.0.28-1)
- obviously -
systemd (257.2-2 -> 257.4-1)
systemd-libs (257.2-2 -> 257.4-1)
- hwdb -
tlp (1.7.0-1 -> 1.8.0-1)
- underpowered? -
util-linux (2.40.4-1 -> 2.41-2)
util-linux-libs (2.40.4-1 -> 2.41-2)
- unlikely -Offline
I downgraded these and a couple more: device-mapper lvm2 dkms glib2 hyprland aquamarine xorg-server xorg-server-common xorg-xauth xorg-xwayland wayland-protocols mesa
Still no change. Will continue troubleshooting, possibly reverting the whole update.
Offline
possibly reverting the whole update
I'd do that first - the partial updates might get you into trouble at some point and also to see whether the update was relevant at all and not just coincidental.
Then consider incremental updates until things break, https://wiki.archlinux.org/title/Arch_L … cific_date
Offline
Ok, so I got the monitor working again via usb-c.
This is what I did:
The issue surfaced post-update from linux 6.13.2
Following your advice I downgraded the system about 1.5 Months back to a date before the second last update I performed which was Feb 8, 2025.
I then booted with linux-lts 6.12.20-1.
Result: Monitor’s USB/Ethernet worked, but display failed, AUX timeouts on USBC2/DDI TC2/PHY TC2 persisted in dmesg. Ruled out a simple kernel regression since 6.13.2 had worked.
I then made another full downgrade, now around 2.5 months back (Jan 8, 2025) to linux-lts 6.6.70-1 and matching packages
Result: Same problem, USB/Ethernet fine, display dead, same AUX timeouts and dp-alt flapping. My gues was a hardware or BIOS issue instead of software, as even this old kernel failed.
Then I thought maybe I should look at boot menu options once more again, and remembered I toggled BIOS PCIe Tunneling on in an earlier troubleshooting attempt.
So I disabled PCIe Tunneling, booted on linux-zen 6.12.8 and the monitor worked again via usb-c. I also tried linux-lts 6.6.70-1 which also worked.
dmesg showed no AUX timeouts anymore, and a clean DP Alt Mode on DP-2 (my usb-c monitor). So I assumed the PCIe Tunneling setting maybe caused a thunderbolt controller conflict or something like that.
To test I re-enabled PCIe Tunneling but surprisingly the monitor still worked - clean dmesg with DP-2 on DDI TC2/PHY TC2, no timeouts.
Next step I decided to first directly do a full update back to 6.13.8 and if this should reintroduce the issue go back to 6.12.8 and try incremental updates from there, as you suggested. But booting with 6.13.8 everything still was fine.
So now I'm basically in the dark about the exact culprit of the original issue (since the potentially problematic update from 6.13.2 to 6.13.7 could have been coincidental, as you already said, seth, but my best guess towards what solved it is maybe not the PCIe Tunneling setting itself (since it wasn't what originally set off the monitor not being detected) but an interplay between these different factors, doing the firmware upgrade with fwupd, full system downgrades, toggling PCIe Tunneling.
So, big thanks to you, seth, for suggesting the date-specific downgrade, which kicked off this journey and helped narrow it down, I was already beginning to give up and accept the monitor not working from now on.
Offline
I'm basically in the dark about the exact culprit of the original issue
Since the solution involved altering the BIOS settings: is there a parallel OS (windows)?
Offline
No, I'm single booting arch.
Offline