Linux on the Framework Laptop

We love Linux at Framework. We decided from the start of Framework Laptop development to offer the DIY Edition without an operating system pre-loaded to give you the option to bring your favorite Linux distribution. There has been immense interest in this configuration, with it outselling pre-configured systems with Windows 10 by a wide margin. We provided pre-release hardware to developers and maintainers at Fedora, elementary OS, NixOS, and Arch to make the Linux experience as smooth as possible, and we’ve been impressed by the incredible variety of Linux distros (and OpenBSD too!) being used by all of you.

Since we planned for Linux support from the outset, we made sure to use hardware that is well-supported and has drivers available. There are just a few areas where support is brand new and making its way into different distributions. Intel 11th Gen Core Processors, Intel AX210 WiFi (which is optional on the DIY Edition), and our Goodix-based fingerprint reader are the three items that require a newer kernel or packages than many distros currently ship. We recommend using 5.12 or newer for a kernel to get solid platform, WiFi, and bluetooth functionality, along with libfprint 1.92.0 or newer for the fingerprint reader. All of the other hardware like speakers, microphones, headphones, webcam, hardware privacy switches, keyboard media keys, ambient light sensor, and all of the Expansion Cards should work completely.

The extremely active and vibrant Linux subforum in the Framework Community is the best place to go for the latest guides and advice around each distro. Here is a quick overview of a few of the most popular ones:

Ubuntu

Our hardware is too new for the Ubuntu 20.04 LTS release. In the meantime, we recommend using Ubuntu 21.04. This is recent enough to be fully functional out of the box with the exception of the fingerprint reader. You can follow the instructions provided by Davis_Ladd in the Community for guidance on how to get that working.

Fedora

Geoff Marr, Matthew Miller, and others at Fedora have been helping us get excellent support. Our WiFi is too new for the default Fedora 34 images, but if you can plug in external networking, you can update your packages to get a newer kernel and libfprint to get everything working, including the fingerprint reader! An alternative is to download a Fedora 34 Respin image, which has these updated packages already. We expect Fedora 35 to be fully functional out of the box when it launches later this year.

Arch

Foxboron at Arch has a pre-production unit and is helping us with support there. You can check out the thread on the Framework Community and also the page on the Arch wiki for more detail.

If you’re looking for instructions on another distro, check out the Community. If you’ve gotten another distro up and running, feel free to start a thread there too!

28 Likes

Got this via email as well. Great communication on the part of Framework (says this Linux fan).

4 Likes

My experience, after getting over the basic hardware support humps, is that the biggest challenges are:

  1. Battery life. This requires some real effort to tune, and I’m still poking around days later to see how I can squeeze out more efficiencies
  2. HiDPI support in Linux is just… rough. The oddball resolution of the Framework display (2256x1504) isn’t suited to full 2x scaling (1128x752), and fractional scaling, particularly with multi-monitor, mixed DPI setups, is a bit painful to set up and has lots of gotchas, whether you’re using Wayland or Xorg.

I’d love to see a 160-170 PPI (e.g. 1920x1280) panel option in the future that I could buy as an aftermarket downgrade. The Linux world is still years away from handling HiDPI gracefully, and we’d probably get longer battery life as a side-effect.

2 Likes

interesting, I am using a multimonitor setup with swaywm and am having no issues with dpi scaling at all, bunch of weird resolutions too, the framework screen obvisously, as well as an ultra wide at 3440x1440, and an 1920x1080p monitor, all are scaled perfectly, think I had to apply either 1.1 or 1.2 scale factor to the framework screen, but that’s easy enough.

Just had to add this to my swayconfig
output eDP-1 scale 1.2

this is likely a Desktop environment issue more than a framework/linux as a whole issue.

3 Likes

It absolutely is. Gnome works differently than KDE works differently than a sway-based setup, and each works differently if it’s Wayland versus Xorg. And in the case of Wayland, it depends on if individual applications are Wayland native or using the XWayland backend.

If anything that just reinforces my point that the Linux desktop situation for HiDPI is a hot mess of gotchas and inconsistencies. :slight_smile:

As just one example, Remmina on Xorg using the xrandr solution results in incorrect scaling of the remote screen (presumably due to the wrong resolution being detected, though I’ve not dug into it too deeply).

On Wayland Remmina works correctly, but then in, say, Signal things look blurry (because Wayland support in Electron isn’t enabled by default) and screensharing doesn’t work at all because Signal hasn’t integrated with pipewire. Of course, I could at least try enabling Wayland support in Signal, but then in Gnome window decorations don’t work thanks to the CSD/SSD food fight.

1 Like

Are the drivers for everything in the gentoo-sources or Linux firmware packages on the default gentoo repository also dues the diy come with a fingerprint sencer with they keyboard

I really hope this one gets ironed out somehow. Hearing from others in the forum about how little battery life they get out of Linux right now makes me want to use Windows for a while longer

3 Likes

Agreed about battery life. That’s my biggest hesitation about moving to a Linux laptop.

4 Likes

Would make sense to also offer openSUSE with it.

Wow framework on arch wiki, amazing!

2 Likes

@George_Hart @gs1

BTW, it’s worth checking the battery thread. I’m reasonably confident, at this point, that we’ve figured out the right combination of base settings and conditions needed to get battery life on Linux comparable to that of Windows.

The challenge with Linux has always been that a) things often aren’t properly configured out of the box, and b) finding the right settings can be a bit of a needle-in-the-haystack exercise.

So it’s not that Linux can’t perform as well as Windows (my old X1C5 performed better under Linux than it did under Windows!), it’s just that it doesn’t happen automatically, which is certainly frustrating.

2 Likes

Well there’s a lot of posts to go through but thanks for mentioning Brett

I’ve added some more sections to the Archlinux wiki page:

  • Tips for dealing with the HiDPI display. (My setup is a bit “retro” in that I use my own X11 window manager (that doesn’t support HiDPI) with no desktop environment.)
  • How to enable two/three finger click for right/middle click.
  • Making xbacklight work. (It did not work for me out of the box.)

Other than that, installation was smooth sailing. I haven’t tried to play with bluetooth or the fingerprint reader though, since I don’t use them.

1 Like

Thanks for the update - question for you: any particular reason you don’t use bluetooth? I mean, I can imagine life w/o bluetooth but .

I don’t want to get too off topic here, but I just don’t have any use for it I guess. The only peripheral I use with my laptop are my headphones, and those are specifically wired. (I specifically got a phone that has a headphone jack.) There’s nothing else I’d use bluetooth for.

1 Like

Agreed - thanks for the answer nevertheless. :slight_smile:

1 Like

Thank you framework, and I’m placing an order as we speak!
I don’t need a “Linux” key but I’d love the Windows key replaced with something more universal. Please

4 Likes

+1

Or, even more “framework-ish.” :wink:

2 Likes

Have you guys tried “playing” with eGPU on your Frame.Work’s Linux? It’s not an issue with Frame.Work, but rather an issue with Linux itself. For Win10 the eGPU is a real plug and play. For Linux it’s a nightmare. :frowning:
Especially considering mobility aspect – your OS should automatically adjust to use either built-in gpu or eGPU. Win10 does it smoothly. With Linux – good luck( at least with Ubuntu 21.x). I have even tried multiple automated scripts that dynamically regenerate X.org config during the boot based on the eGPU availability. Unfortunately, these scripts do not work all the time properly. Also, it’s not a plug and play experience – you have to shutdown Linux and attach or detach eGPU in order to regenerate the X.org config for your new setup( well there is a ugly workaround – kill the X session and re-run these scripts manually and then restart your X-session). Compare to Win10 experience – you need it – you plug eGPU, Win10 automatically switches to eGPU. You don’t need it – you unplug it. And Win10 automatically switches back to Intel’s GPU. No reboot needed. Also, as far as I know eGPU with NVidia and Wayland are incompatible, you have to use X.
P.S. Sorry for emotional post, I’ve wasted 1.5 days to make eGPU work at least in such ugly way under Linux. :rage: I was not pissed off even with my ex-girlfriend to such extent.

I would love to see what distributions people are running on their laptops and with what hardware?