FreeBSD on the Framework Laptop

Author: Jonathan Vasquez <>
Last Updated: 2022-05-17-1710
Currently On: FreeBSD 13.1-STABLE #1 stable/13-n250869-2430388070f: Tue May 17 11:51:35 EDT 2022     root@leslie:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
Machine: Framework Laptop @ Batch 6 (Ordered on November 20, 2021). Tempo 92HD95B Audio Codec Version.
BIOS: 3.07


2022-05-17-1710 ET

The machine has been pretty stable for the past few weeks. I was able to actually get X11 working properly now in a way that is quick, fully accelerated, and doesn't seem to be periodically crashing (under any DE running under X11). Check the graphics section (under troubleshooting) for what you'll need. Also, after disabling PS/2 Emulation in the BIOS (check the touchpad scrolling section below), I haven't experienced any further gesture loss. I'm still keeping an eye out though.

2022-05-09-1632 ET

Since graphics/drm-510-kmod is now in ports (in preparation for 13.1-RELEASE), I was able to downgrade my machine from 14-CURRENT to 13-STABLE and take advantage of this. Essentially everything in this post remains the same other than that I'm now on 13-STABLE and can benefit from a stable ABI, more tested changes, and future hardware support commited to this branch. The same caveats apply for all the hardware on this machine. The good news is that now people running this laptop can get a "working" machine without having to go to 14-CURRENT. Further updates on this post will be done on 13-STABLE.


TLDR: The machine is in a highly experimental state and not production ready. Prepare for random crashes caused by the graphics and wireless drivers (and maybe other random stuff that I'm not aware of). Also be prepared to lose out on a good set of functionality (sleep / resume, hibernation, bluetooth, some sound scenarios (headsets via USB. 3.5mm works), etc .. read the report for more info). Depending on how many sacrifices you are willing to make, it is usable to a large extent, and with a lot of work and patience you'll get there (I'm writing this on FreeBSD 13.1-STABLE as we speak). Given that I haven't been happy with the state of Linux for many years now (including the way the OS is packaged, designed, and licensed), and given that I've also been a huge fan and advocate of ZFS for about 10 years now (I spent about 6+ years working on support for Installing Gentoo Linux on OpenZFS (including bliss-initramfs), I'm willing to take the hit and come on over to FreeBSD. OpenZFS is a requirement for me at this point for me to be truly happy in every capacity (desktop/server), and since my server has actually been on FreeBSD the past few years now (:D), I've grown to love FreeBSD and the way that it is architected, designed, and administered. This is despite the fact that Linux essentially has perfect hardware support for the Framework Laptop. Hopefully FreeBSD will get there eventually, it will be glorious.


It's been a hell of a ride ;). I'll be writing down my notes as I keep tackling down the issues.

I ordered this Framework Laptop on November 20, 2021 and was marked as part of Batch 6. It's currently configured with 1x USB C, and 3x USB A Expansion Cards. I also have an HDMI Expansion Card, and another USB C Expansion Card on the side in case I want to switch it up. I use the USB C port for charging primarily but also to connect my Anker PowerExpand+ 7-in-1 Dongle, which has 1x Gigabit Ethernet, 1x USB-C PD Port (Charging) 1x SD Card Reader, 1x Micro SD Card Reader, 2x USB A 3.0 Ports, and 1x HDMI Port). This machine has the Tempo 92HD95B Audio Codec for people that want to further identify the model.

Desktop (sway on Wayland)

Desktop Screenshot

Desktop (Plasma on X11)

Desktop Screenshot

System Status Overview


Test Report Results

ugen1.2: <Framework HDMI Expansion Card> at usbus1

and the following in xrandr:

DP-3 connected primary 1024x768+0+0 (normal left inverted right x axis y axis) 597mm x 336mm
   1440x576      50.00
   1024x768      60.00*
   1440x480      60.00    59.94
   832x624       74.55
   800x600       72.19    75.00    60.32    56.25
   720x576       50.00
   720x480       60.00    59.94
   640x480       75.00    72.81    66.67    60.00    59.94
   720x400       70.08

This is what it should be (via the Anker HDMI's port):

DP-4 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 597mm x 336mm
   2560x1440     59.95*+  99.95  
   1920x1080     60.00    60.00    50.00    59.94    30.00    29.97  
   1280x1024     75.02    60.02  
   1440x900      59.90  
   1152x864      75.00  
   1280x720      60.00    50.00    59.94  
   1440x576      50.00  
   1024x768      75.03    70.07    60.00  
   1440x480      60.00    59.94  
   832x624       74.55  
   800x600       72.19    75.00    60.32    56.25  
   720x576       50.00  
   720x480       60.00    59.94  
   640x480       75.00    72.81    66.67    60.00    59.94  
   720x400       70.08 

Both of these scenarios also have the laptop's monitor active as a second display.

I also saw the following error message repeated many times in dmesg, which weren't there before using the HDMI Expansion Card:

[drm ERROR :intel_dp_get_link_train_fallback_values] Link Training Unsuccessful
ugen1.9: <Razer Razer USB Sound Card> at usbus1
uaudio0 on uhub1
uaudio0: <Razer Razer USB Sound Card, class 0/0, rev 2.00/0.0e, addr 27> on usbus1
uaudio0: Play[0]: 48000 Hz, 2 ch, 24-bit S-LE PCM format, 2x2ms buffer.
uaudio0: Record[0]: 48000 Hz, 2 ch, 16-bit S-LE PCM format, 2x2ms buffer.
uaudio0: Record[0]: 16000 Hz, 2 ch, 16-bit S-LE PCM format, 2x2ms buffer.
uaudio0: No MIDI sequencer.
pcm3: <USB audio> on uaudio0
uaudio0: HID volume keys found.
ugen1.4: <Generic Laptop Camera> at usbus1

flipping the physical camera kill switch yielded the following:

ugen1.4: <Generic Laptop Camera> at usbus1 (disconnected)
ugen1.4: <Generic Laptop Camera> at usbus1
ugen1.4: <Generic Laptop Camera> at usbus1 (disconnected)
ugen1.4: <Generic Laptop Camera> at usbus1

via Anker PowerExpand+ 7-in-1 USB-C PD Ethernet Hub

Internet via the MiFi M2000 4G/5G Hotspot (Calyx Institute)

Known to be problematic on FreeBSD (in general)

These are particular features that apparently are known to be problematic on FreeBSD in general, so I'm not necessarily expecting support for these to ever be implemented, but I'm optimistic. Just keep this in mind since you'll need to be prepared to live without them.

Issues / Workarounds / Misc


You will need to be on at least 13.1-RELEASE to get this working, and you'll need to install (or build) graphics/drm-510-kmod. For the past month, I was getting random crashes whenever using X11 (regardless of DE) and massive slowdowns. Any environment under X11 was essentially unusable, forcing me to experiment with sway / Wayland. sway basically never crashed on me and was stable and quick. After some debugging under X11, I noticed that even though I was using i915kms (it was loaded and working), /var/log/Xorg.0.log mentioned that it wasn't using it. The intel driver was missing (xf86-video-intel which we don't need since we are using i915kms, so make sure you don't have xf86-video-intel installed), and while the modesetting driver seemed to load, it obviously wasn't working properly. Once I added the following lines to my /usr/local/etc/X11/xorg.conf.d/10-video.conf, the 3D acceleration was fully working, it was fast, and so far I haven't had any crashes under X11 (or any DE under it). The magic line primarily being Option "AccelMethod" "SNA". Without that line, you'll see the slow behavior. I'll need more time to fully test its stability, but this is very promising.

Section "Device"
        Identifier  "Card0"
        Driver      "modesetting"
        BusID       "PCI:0:2:0"
        Option      "AccelMethod"       "SNA"

Once I added those lines and started KDE again, I saw that the Graphics processor line under System Settings -> About this system changed from Mesa Intel Xe Graphics to llvmpipe.

KDE also seems to be detecting all my monitors in System Settings -> Display and Monitor now (still via the Anker Dongle's HDMI port). FreeBSD doesn't detect my monitor if I plug it in via the Framework Laptop's HDMI Expansion Card.


The FreeBSD iwlwifi driver (at least for this laptop) is definitely not production ready and highly experimental. On this particular card, I was unable to set a static IP on the device since doing so would crash the machine. From the bug reports (linked above), the maintainer is aware about the issue regarding the card maintaining outdated states. Another troubling issue is that the card struggles a lot to actually associate or even receive a DHCP address from the router. There are many times where the card will work fine, but sometimes it could take a lot longer for it to work or refuse to work. For the router in my house, it seems to have taken a "liking" to it so now it works a lot better where as before it didn't (Nothing changed, other than many reboots, and just time..), however I went to a friend's house yesterday and it refused to associate to the router completely. Even after spending a few hours trying to get it to work with a correct configuration, it simply refused. However, when I enabled my phone's WiFi hotspot, the card was able to connect to my phone instead.. The phone was just sharing the friend's router's connection lol. I actually tried a separate USB 2.0 Wireless Adapter running at the rtw0 interface (TP-Link adapter with Realtek Driver), and this adapter would associate with my home network, but it doesn't receive a DHCP request. A static ip also doesn't work with it but it also doesn't crash the system.


This works mostly fine usually. Sometimes the connections get pretty sluggish (for both Ethernet and Wireless), like if it isn't working at full performance (even if it's full duplex).

Touchpad (Tapping / Scrolling / Right Click)

Mismatched Touchpad ID / Casing in libinput

There are two issues. The first is a mismatched touchpad ID that is in the libinput qwirks shipped by upstream.

For my current device, the number was off by 1, and also the "TouchPad" has an upper case letter on my machine, but upstream's has a lower case.

You'll need to correct this in /usr/local/share/libinput/50-framework.qwirk:

[Framework Laptop Touchpad]
MatchName=PIXA3854:01 093A:0274 TouchPad

Activating more gesture support (tapping, etc) in libinput


The second issue is that you still need to get the gestures (two finger tap (right click), tap to click, etc). I was able to do this by placing the following test into /usr/local/etc/X11/xorg.conf.d/40-libinput.conf:

Section "InputClass"
        Identifier "libinput touchpad catchall"
        MatchDriver "libinput"
        MatchIsTouchpad "on"
        MatchDevicePath "/dev/input/event*"
        Option "Tapping" "on"

This got everything that I needed to work. You won't be able to tweak the settings in the KDE settings (If you use KDE), but since everything worked, I'll take the win.

sway w/ Wayland

Place this in your sway.conf:

input type:touchpad {
       dwt enabled
       tap enabled
       middle_emulation enable
       tap_button_map lrm
       scroll_method two_finger
Touchpad scrolling (and other gestures) stopped working

There was an issue I was experiencing where the machine's touchpad would lose various gesture support (like scrolling, right clicks, middle clicks, etc). On Linux, this would happen after I resumed from sleep, and would require me to reload the hid-multitouch driver (via a script of course ;D). On FreeBSD, this also seems to happen but in my case I was simply rebooting sway a few times and my touchpad lost support. Doing a kldunload hmt caused the module to be unloaded by the kernel, and I noticed the kernel automatically reloaded it back, in this case, saving me a load call. After that the touchpad started working again. I re-investigated the issue and found this community thread and a post by framework. I've turned off PS/2 Emulation in the BIOS and now I'm testing. I'll update this section if I notice any further issues (or lack of). So far so good..



Sound for Chromium / Firefox

I noticed that when listening to audio via Firefox, pressing the Fn keys to mute / increase / decrease volume, properly triggered that action and Firefox respected that decision. However, Chromium only respected the increase / decrease volume keys, but ignored muting completely. I've left a comment at this Bug Report.