Arch + CalDigit TS4 Dock + XFCE4 Trials, Tribulations, and Fixes

Hey folks;

I have had a lot of trouble getting my Frame.Work 12 laptop working with Arch Linux and the CalDigit TS4 dock, so I thought it might be helpful to others for me to post the solutions I’ve come up with here.

Many of these solutions came from other posts, both in these forums and other sites. I take no credit for any of it – I’m just a monkey that did trial and error until I got it to work. I apologize that I can’t credit the actual smart people here, and I also apologize that I probably can’t help you with your own questions (but feel free to ask, you never know)…

So what problems did I have, exactly?

  • Initially, nothing on the dock worked except I think some of the USB ports and the charger
  • Eventually I got DisplayPort working but not Ethernet by updating the firmware (see below)
  • Then I got Ethernet working, but it was ignoring my wifi card even after unplugging the dock
  • Finally I got everything working
  • Trackpad wasn’t tapping to click
  • TPM module reporting interrupt not working (still unsolved)

Update Dock Firmware

This is super important for getting displayport working.

pacman -S fwupd
fwupdmgr get-updates
fwupdmgr update

There’s a complex proceedure on the 'net if you look up how to update firmware on the dock under linux – no need for that anymore, fwupdmgr can do it now.

Kernel Parameters for the Dock

The problem with the dock boils down to more PCIe devices than the system can handle in default configuration. In arch, go to:


In there, you will find a .conf file (mine is named 2023-03-31_18-02-15_linux.conf). Edit it, find the options line (it’s the line that starts with the word ‘options’), and add this to it:

pci=assign-busses,hpbussize=0x33,realloc,hpmemsize=512M nvme.noacpi=1

Breaking down what this does…

pci= means PCI parameters
assign-buses tells the kernel to override the firmware bus number assignments to do the orchestration rather than making a free for all
bpbussize has something to do with bus number reservations, I don’t really understand this one.
realloc tells the kernel to reallocate resources allocated by BIOS if they are too small – this one is very important in our case
hpmemsize sets aside memory for the hot plug bridge memory window. This has to be 512M – if it is less (say, 256M which is something else I tried) some of the devices won’t work (in my case the memory card)
nvme.noacpi some folks report this increases battery life when the laptop is suspended, your mileage may vary here, I just threw it on there to try it.

Once you edit that file, I copy it to /root just in case something ever overwrites it (I’m new to arch and I’m not sure how or if it will ever get updated) then run:

bootctl install

Trackpad Tap to Click

For some reason, I can’t find this setting in xfce4 anywhere … I could have sworn I’ve seen it before, maybe I’m missing a package. Here’s how you can make it work, though.

Install the xorg-xinput package: sudo pacman -S xorg-xinput

Use xinput list to find your track pad name. Mine was “PIXA3854:00 093A:0274 Touchpad”.

Create a file /etc/X11/xorg.conf.d/50-touchpad.conf

Put this in it, replacing my touchpad name with yours:

Section "InputClass"
        Identifier "PIXA3854:00 093A:0274 Touchpad"
        MatchIsTouchpad "on"
        Driver "libinput"
        Option "Tapping" "on"
        Option "libinput Tapping Enabled" "1"

Log out / log back in or reboot and it should work, along with two finger scrolling and two/three finger tapping for right click/middle click.

Note that if you screw this file up, your system will appear to hang on boot and you’ll need to ALT-F2 over to a command prompt to fix it. Ask me how I know :slight_smile:

TPM Error Message

I get this TPM error message on boot:

[ 1.468118] tpm tpm0: [Firmware Bug]: TPM interrupt not working, polling instead

I don’t yet have an answer for this one, it’s my quest for tomorrow. But as of right now, my system seems pretty minimally janky so I am happy. I just wanted to share these tidbits all in one place.

Thanks for everyone that’s posted info on how to get stuff working :slight_smile:



thanks for the note on updating firmware, it seems to have helped a bit. I now have one screen at 4K59.997, one at 4K30, and no Ethernet at all.

This is already using the kernel options as described.
Which resolutions and refresh rates did you get it to run at?

My dmesg does say:

8.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x4 link at 0000:00:07.3 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link)

Can you confirm that that’s what you see as well?


By manually forcing 4K60 on one screen (I’m using Sway), that screen now is working fine. The other one still stuck at 4K30, hanging off of a CalDigit USB-C DisplayPort adaptor. Works fine at 1080p, 60Hz.

Not sure where to dig further, could it just be missing Thunderbolt bandwidth?

Re. dmesg, I get the same message with a very slight variation – the link is at “0000:00:07.0” for me.

lspci reveals this to be:

00:07.0 PCI bridge: Intel Corporation Alder Lake-P Thunderbolt 4 PCI Express Root Port #0 (rev 02)

… I’m plugged into the rear right USB-C connection by way of a USB-C “expansion card” (which is really just about an inch of PCB trace to replicate the USB-C plug off the motherboard). I’ll bet that’s the difference in our PCI link numbers, you’re probably plugged into another port.

I use a single 2K monitor on display port, so I am hardly stressing the video system here or pushing the limits. I’m at 2560x1440 at 60 Hz.

So, a few thoughts here. Firstly, I have to come clean and admit I abandoned Arch. About 2 days after I posted this message, and after changing absolutely nothing, basically all my problems came back and I was ready to beat the CalDigit to pieces using the laptop.

This was my first real attempt at having an Arch system with the motivation behind it being fed up with certain aspects of Ubuntu, so I wasn’t super married to Arch and I was largely okay with Ubuntu – I can “de-Ubuntu” my ubuntu system, removing stuff like the ubuntu-advantage-tools, snapd, etc. that I personally didn’t want, so that’s what I chose to do.

I switched back to Ubuntu and followed Frame.Work’s instructions on setting it up, using the OEM kernel, and that fixed about 85% of my problems. The last 15% of my problems were fixed by getting rid of a USB hub that I was using in my old setup that was causing weird USB conflicts (usually with my mouse) and plugging everything straight into the CalDigit. As of now, I don’t have any problems whatsoever to report.

That said, I’m of course not causing the video system to even break a sweat with my single 2K monitor, so I can’t report on how well multi-monitor works.

I spoke to my friend who turned me on to Arch later and he heckled me for whimping out :slight_smile: He thinks there’s a kernel firmware package that I was missing. I’m like … 85% sure I installed ALL the kernel firmware packages since I really didn’t want to leave anything to chance, but perhaps that’s something to look at.

Another thing you could try is booting Ubuntu from a live-CD (live-USB?) and see if it fixes your problems. As I recall, a stock Ubuntu 22 install without the OEM kernel works about 95% but there’s some flakiness (i.e. freezes/drops) over the wifi card that are resolved by going to the OEM kernel. If that DOES fix your problem, and you STILL want to cling to Arch, you can compare Ubuntu’s kernel settings to your Arch settings.

The stock Ubuntu 22 kernel is a 5.x series, the oem one is a 6.x series, so the oem one will be a little more apples/apples comparison with Arch if you can maybe suss out what parameters were used to build it / what parameters are used on boot.

Anyway, I hope this helps some. Sorry to have to admit I gave up on Arch, but I was just too new to it and it was just too steep a hill for me to climb. I will definitely give it another stab in the future, though maybe with a less complex hardware setup :slight_smile:

Re. OEM kernel, here’s a link to the doc:

See section 8 “completing setup” and follow the right one for your generation of laptop.

Thanks for the extensive info - I almost went the same route today, were it not for one last hack I tried:

Take the HDMI Card out of the framework and put it in between the dock and my second screen.

Now they’re both happily running at 4K, 60Hz.

Final topology:

  • Framework 13, 12th gen
    • CalDigit TS4
      • DisplayPort Out → Left 4K screen at 59.997 Hz (close enough)
      • Thunderbolt Out → Framework HDMI Card → Right 4K screen at 60Hz

Only Ethernet left to make work now.
Arch is a learning experience.

Ha, well, glad you could figure out how to get it to work!

re. ethernet, on the CalDigit the ethernet card is epci which is unusual; a lot of docks present the ethernet card as a USB device, however CalDigit has a 2 gig ethernet port which is probably why it is epci.

I believe the problem with Arch and is the sheer number of pci things going on at the same time – lspci on my laptop plugged into the dock shows a staggering 34 devices. That’s about 10 more devices than my previous laptop in dock.

So if you look in your dmesg, in the first half or so, you may see a lot of complaints about PCI memory conflicts. I think that is the key to fixing the ethernet, resolving those somehow :slight_smile: Anyway – just my two cents, for whatever they’re worth. Good luck!!

1 Like

I just spent a while trying to get ethernet working on the CalDigit TS4 dock, and eventually discovered it was because my OS wasn’t allowing the dock to do PCIe tunneling. This page gives an excellent explanation of all of this: USB4 and Thunderbolt — The Linux Kernel documentation.

tl;dr: Check if the attached thunderbolt device is “authorized”. Here’s how:

$ for f in /sys/bus/thunderbolt/devices/*/authorized; do echo -n "$f: "; cat "$f"; done
/sys/bus/thunderbolt/devices/0-0/authorized: 1
/sys/bus/thunderbolt/devices/1-0/authorized: 1
/sys/bus/thunderbolt/devices/1-1/authorized: 1

(previously, this was 0 for one of the devices)

It turns out my device* does have hardware support for DMA protection, so I believe there isn’t any reason to not trust the device. I fixed this by adding** the udev rule from DMA protection utilizing IOMMU:

ACTION=="add", SUBSYSTEM=="thunderbolt", ATTRS{iommu_dma_protection}=="1", ATTR{authorized}=="0", ATTR{authorized}="1"

*I’m on a T14s, sorry for posting on a Framework forum, but I figured this information is useful for any Linux device trying to connect to the CalDigit TS4 docker.
**This was necessary on my OS (NixOS). It’s possible that this rule is already baked into other OSes like Arch, I didn’t check.

Only Ethernet left to make work now.

I’m not able to find the name of the chipset used in that 2.5gbit Ethernet adapter, but would bet that the linux-firmware package is needed to provide the initialisation data for the chip used by your dock.