My system still freezes when booting up while connected to the dock, right around when GNOME is supposed to launch. The same thing happens when shutting down.
Framework 13, AMD Ryzen 7840U, Fedora 39.
Dock: CalDigit TS4
My system still freezes when booting up while connected to the dock, right around when GNOME is supposed to launch. The same thing happens when shutting down.
Framework 13, AMD Ryzen 7840U, Fedora 39.
Dock: CalDigit TS4
Have you run the beta BIOS update recently?
No issues for mine when plugging into OWC thunderbolt hubs (real docks use real hardware docking mechanisms imho) or an Anker hub. Same distro, most recent kernel.
Framework 13 AMD Ryzen 7040 BIOS 3.03b BETA
Following up/āansweringā on my previous post about my monitor issues with the Kensington SD5780T dock and monitor connected to it over HDMI:
I finally got my hands on a second, Apple, TB4 cable. Just replacing the host/dock cable with this Apple cable didnāt fix the issue:
[FW]---(Apple TB4 cable)---[dock]---(HDMI cable)---[monitor]
So I switched back to the Kensington-supplied TB4 cable.
Then, on a whim since I now have a second TB4 cable around I used one of the dockās TB outputs to connect to the monitorās USB-C (DP alt mode) input instead of HDMI:
[FW]---(Kensington TB4 cable)---[dock]---(Apple TB4 cable)---[monitor]
and to some surprise the monitor (EDID) gets detected correctly and everything (display-wise) works.
This does make the Linux kworker
issue, or rather its workaround of toggling power to the dock, have more of an āimpactā with various windows scurrying off to the laptop monitor, as expected.
Anyway, for extra kicks I also tried:
[FW]---(Apple TB4 cable)---[dock]---(Kensington TB4 cable)---[monitor]
And that, consistently, results in a new failure mode: The monitor is detected but only at 30Hz. Not enough bandwidth?
Anyway, the Kensington cable seems to be at least part of the problem - on the AMD USB4 host - The same first/original topology above still works with many other laptops including a gen11 Intel FW.
Hey there, just adding my feedback to this issue.
I just got a CalDigit TS4 dock for my Framework 16 (no dGPU) and I noticed a really weird behavior with monitor resolutions.
When running on Windows 11, I can connect 2 monitors in DisplayPort (one using the DP port and the other through an USB-C to DP cable) on the dock and they both work perfectly at high resolution and refresh rate (1440p 165Hz).
But under Linux (Arch, Wayland/Hyprland) it seems that the displays canāt report their EDID infos correctly because they are locked at 640x480 60Hz and no display infos can be seen.
Although I can force the two monitors to their full resolution (but not above 120Hz) through hyprctl commands.
Would this be a bug in the AMD driver in Linux?
There should be enough logging in TB/USB4 drivers to be enabled to see them choosing DP connection speeds etc. I think that should be the only other way to possibly cause issues not rooted in the GPU drivers when you can still get some connections to work.
On windows with the software connection manager it reports the DP capabilities of the outputting TB controller for every tunnel and what it ended up choosing (Windows event log). And maybe with linux you can actually see the math of it blocking a specific DP speed because it thinks it is out of bandwidth or sth.
Maybe this can narrow it down to one or the other. Or a surprise 3rd participant in those negotiations.
Whatās the best way to collect logs for a quality bug report, with regards to thunderbolt dock issues?
It seems everybody is experiencing their own unique paper cuts with TB docks. In my case, everything works great with my AMD 13", running fedora 39, connected to a Caldigit TS3+, except that on wake from sleep, all usb is dead until I unplug and replug. My display, which is connected over display port, works fine on wake. But my keyboard and mouse are dead until I pull and replug the cable.
Figure this is more likely something to report to Fedoraās bugtracker than Frameworkās, but I donāt know enough about linux logging to know how to find good logs to include in the report.
Is it still working well? Are you able to do updates through LVFS?
https://fwupd.org/lvfs/docs/users
Hello, new friends!
I have a Framework Laptop 13 (AMD Ryzen 7040 Series) Professional Pre-Built on order (with Windows 11 Pro, the OS I intend to use), and I want to get a dock for it. Iām looking at this one:
Plugable 12-in-1 USB C Docking Station Triple Monitor
https://www.amazon.com/gp/product/B09NQQ1G1N
Iām no hardware maven, but I note that the laptopās power adapter is rated 65W and this dock only passes on 60W to the laptop. Will that be a problem?
Anyone have experience with this dock? I do intend to run three monitors, but only need 1920x1080 resolution out of them.
Anybody care to suggest a better dock choice?
Many thanks!
Rob (in Toronto)
Those of you who have posted that docks work inconsistently or with different cables can you please experiment with stopping fwupd.service
before you plug in the dock after boot up?
If that helps there is an upstream fwupd bug about what might be going on.
I can confirm that stopping fwupd.service
didnāt change anything for my monitor issue, using both DP and USB-C to DP cables on a CalDigit TS4 dock. I commented on the GitLab issue above the other day.
Although Iāve been able to test out with 2 other DP monitors (a iiyama 1080p 75Hz and a LG 1080p 21:9 75Hz) and they are recognized correctly. I have a different (LG) 1440p 165Hz display I can try tomorrow too but Iām starting to think itās linked to high-spec (recent ?) monitors.
I also just tested using a USB-C to HDMI cable I had on hand and my ASUS monitor gets detected perfectly with EDID at up to 1440p 144Hz (which is expected in HDMI).
EDIT: After testing with the LG 1440p 165Hz monitor (LG Ultragear 27GR75Q-B), it surprisingly works perfectly despite being very similar to the ASUS one(s)ā¦
Iāll include the monitor EDID and update my comment over GitLab hopping it can help diagnose the issue over Linux as it strangely works on Windows
edid-decode (hex):
00 ff ff ff ff ff ff 00 1e 6d 4d 5c 33 6c 06 00
04 21 01 04 b5 3c 22 78 9d 8c b5 af 4f 43 ab 26
0e 50 54 21 08 00 d1 c0 61 40 01 01 01 01 01 01
01 01 01 01 01 01 09 ec 00 a0 a0 a0 67 50 30 20
3a 00 58 54 21 00 00 1a 00 00 00 fd 0c 30 a5 03
03 46 01 0a 20 20 20 20 20 20 00 00 00 fc 00 4c
47 20 55 4c 54 52 41 47 45 41 52 0a 00 00 00 ff
00 33 30 34 4e 54 43 5a 43 43 39 31 35 0a 02 17
02 03 31 71 23 09 06 07 e2 00 6a 83 01 00 00 e3
05 c0 00 e6 06 05 01 53 53 2e 48 10 04 03 01 1f
13 3f 40 6d 1a 00 00 02 05 30 a5 00 04 53 2e 53
2e 56 5e 00 a0 a0 a0 29 50 30 20 35 00 58 54 21
00 00 1a 5a a0 00 a0 a0 a0 46 50 30 20 3a 00 58
54 21 00 00 00 6f c2 00 a0 a0 a0 55 50 30 20 3a
00 58 54 21 00 00 1a 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01
70 12 79 03 00 03 00 14 3d 11 01 84 ff 09 9f 00
2f 80 1f 00 9f 05 76 00 02 00 04 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 f3 90
Block 0, Base EDID:
EDID Structure Version & Revision: 1.4
Vendor & Product Identification:
Manufacturer: GSM
Model: 23629
Serial Number: 420915 (0x00066c33)
Made in: week 4 of 2023
Basic Display Parameters & Features:
Digital display
Bits per primary color channel: 10
DisplayPort interface
Maximum image size: 60 cm x 34 cm
Gamma: 2.20
DPMS levels: Standby
Supported color formats: RGB 4:4:4, YCrCb 4:4:4, YCrCb 4:2:2
Default (sRGB) color space is primary color space
First detailed timing does not include the native pixel format and preferred refresh rate
Display supports continuous frequencies
Color Characteristics:
Red : 0.6855, 0.3085
Green: 0.2646, 0.6679
Blue : 0.1503, 0.0576
White: 0.3134, 0.3291
Established Timings I & II:
DMT 0x04: 640x480 59.940476 Hz 4:3 31.469 kHz 25.175000 MHz
DMT 0x09: 800x600 60.316541 Hz 4:3 37.879 kHz 40.000000 MHz
DMT 0x10: 1024x768 60.003840 Hz 4:3 48.363 kHz 65.000000 MHz
Standard Timings:
DMT 0x52: 1920x1080 60.000000 Hz 16:9 67.500 kHz 148.500000 MHz
DMT 0x10: 1024x768 60.003840 Hz 4:3 48.363 kHz 65.000000 MHz
Detailed Timing Descriptors:
DTD 1: 2560x1440 143.973257 Hz 16:9 222.151 kHz 604.250000 MHz (600 mm x 340 mm)
Hfront 48 Hsync 32 Hback 80 Hpol P
Vfront 3 Vsync 10 Vback 90 Vpol N
Display Range Limits:
Monitor ranges (Range Limits Only): 48-165 Hz V, 258-258 kHz H, max dotclock 700 MHz
Display Product Name: āLG ULTRAGEARā
Display Product Serial Number: ā304NTCZCC915ā
Extension blocks: 2
Checksum: 0x17
Block 1, CTA-861 Extension Block:
Revision: 3
Basic audio support
Supports YCbCr 4:4:4
Supports YCbCr 4:2:2
Native detailed modes: 1
Audio Data Block:
Linear PCM:
Max channels: 2
Supported sample rates (kHz): 48 44.1
Supported sample sizes (bits): 24 20 16
Video Capability Data Block:
YCbCr quantization: No Data
RGB quantization: Selectable (via AVI Q)
PT scan behavior: Always Underscanned
IT scan behavior: Always Underscanned
CE scan behavior: Always Underscanned
Speaker Allocation Data Block:
FL/FR - Front Left/Right
Colorimetry Data Block:
BT2020YCC
BT2020RGB
HDR Static Metadata Data Block:
Electro optical transfer functions:
Traditional gamma - SDR luminance range
SMPTE ST2084
Supported static metadata descriptors:
Static metadata type 1
Desired content max luminance: 83 (301.833 cd/m^2)
Desired content max frame-average luminance: 83 (301.833 cd/m^2)
Desired content min luminance: 46 (0.098 cd/m^2)
Video Data Block:
VIC 16: 1920x1080 60.000000 Hz 16:9 67.500 kHz 148.500000 MHz
VIC 4: 1280x720 60.000000 Hz 16:9 45.000 kHz 74.250000 MHz
VIC 3: 720x480 59.940060 Hz 16:9 31.469 kHz 27.000000 MHz
VIC 1: 640x480 59.940476 Hz 4:3 31.469 kHz 25.175000 MHz
VIC 31: 1920x1080 50.000000 Hz 16:9 56.250 kHz 148.500000 MHz
VIC 19: 1280x720 50.000000 Hz 16:9 37.500 kHz 74.250000 MHz
VIC 63: 1920x1080 120.000000 Hz 16:9 135.000 kHz 297.000000 MHz
VIC 64: 1920x1080 100.000000 Hz 16:9 112.500 kHz 297.000000 MHz
Vendor-Specific Data Block (AMD), OUI 00-00-1A:
Version: 2.5
Minimum Refresh Rate: 48 Hz
Maximum Refresh Rate: 165 Hz
Flags 1.x: 0x00
Flags 2.x: 0x04
Maximum luminance: 83 (301.833 cd/m^2)
Minimum luminance: 46 (0.098 cd/m^2)
Maximum luminance (without local dimming): 83 (301.833 cd/m^2)
Minimum luminance (without local dimming): 46 (0.098 cd/m^2)
Detailed Timing Descriptors:
DTD 2: 2560x1440 59.950550 Hz 16:9 88.787 kHz 241.500000 MHz (600 mm x 340 mm)
Hfront 48 Hsync 32 Hback 80 Hpol P
Vfront 3 Vsync 5 Vback 33 Vpol N
DTD 3: 2560x1440 99.946436 Hz 16:9 150.919 kHz 410.500000 MHz (analog composite, sync-on-green, 600 mm x 340 mm)
Hfront 48 Hsync 32 Hback 80 Hpol N
Vfront 3 Vsync 10 Vback 57 Vpol N
DTD 4: 2560x1440 119.997589 Hz 16:9 182.996 kHz 497.750000 MHz (600 mm x 340 mm)
Hfront 48 Hsync 32 Hback 80 Hpol P
Vfront 3 Vsync 10 Vback 72 Vpol N
Checksum: 0x01 Unused space in Extension Block: 24 bytes
Block 2, DisplayID Extension Block:
Version: 1.2
Extension Count: 0
Display Product Type: Standalone display device
Video Timing Modes Type 1 - Detailed Timings Data Block:
DTD: 2560x1440 164.957741 Hz 16:9 257.169 kHz 699.500000 MHz (aspect 16:9, no 3D stereo, preferred)
Hfront 48 Hsync 32 Hback 80 Hpol P
Vfront 3 Vsync 5 Vback 111 Vpol N
Checksum: 0xf3
Checksum: 0x90
@Alex_S: I keep using it 3 days a week at work without any issuesš
Not sure if I mentioned it already, but I disable the Frameworks internal display and work only on the 2 external 1440p monitors.
I did not try to update the dock with LVFS, as it works just fine.
Iām also using stock ubuntu 22.04 with 6.5 kernel (not OEM). Booting from an external USB-C M.2 drive. Surprisingly also no problems here.
(Private use is with Arch Linux - but that never gets connected to the docking station)
Today at work I checked for updates with LVFS, and indeed there is one available:
Hope that answers your question.
PS: The update itself also worked fine
Yes, Iāve updated everything and have retested today.
OS: Fedora 39
Kernel: 6.8.8-200.fc39.x86_64
Bios: 03.05
Dock: CalDigit TS4
Iām still getting a freeze right around the time gnome is starting or shutting down. So I have to undock before I want to boot/shutdown.
I did not try the patch mentioned here because I donāt have the time: Dock Compatibility (AMD) - USB-C / Thunderbolt - #38 by Mario_Limonciello
On another note, @Matt_Hartley have you tested running Bluefin on your FW13 and plugged it into any of the hubs/docks suggested here? Wonder how that compatibility is fairing.
Installed Fedora 40. Same problem.
@Alex_S Docks are the bane of my existence. lol
As a hard and fast rule, generally, ANKER stuff is solid (usually). Iād connect them to the higher power consuming ports, through. Pushing webcams, USB headsets or external drives is fine.
Donāt run video through your dock. Use HDMI or DP expansion cards as we control that narrative and we do not for docks. Most issues we see are folks pushing HDMI or DP through a dock, we have no control there and it rarely works.
And to avoid another common issue, use DP to DP expansion card or HDMI to HDMI expansion card, do not use adapters.
My issue is not framework specific. Guy with a Thinkpad gets the same exact issue, apparently caused by a zero-division in the driver: External monitor prevents logout/reboot / Kernel & Hardware / Arch Linux Forums
It was fixed 3 weeks ago in upstream. But it has not made it into the 6.8 and 6.9 kernels yet. I found that thread because my dmesg keeps spamming this message permanently when Iām running a game:
...
[drm] Mode Validation Warning: Viewport size failed validation.
[drm] Mode Validation Warning: Viewport size failed validation.
[drm] Mode Validation Warning: Viewport size failed validation.
...
No one requested it back to stable until now. Itās not an automatic process. Iāve sent out a request:
https://lore.kernel.org/stable/e1937591-708b-4fe9-a43c-2027ddc1c657@amd.com/T/#u
On this topic, I can now agree. Video randomly no longer works through my Cable Matters USB-C hub, but it works fine through the HDMI expansion card.