Debian Stable and the Framework 16
dataplane.org
dataplane.org
I only discovered the InstallingDebianOn page after reading this article but the laptop is working fine without making any of the changes. Notably the graphics don't freeze and crash, Audio doesn't have static, and palm detection works out of the box. Plus fwupd reports everything with firmware available is using the latest version.
https://wiki.debian.org/InstallingDebianOn/FrameWork/Laptop1...
All of the gripes I have so far result from KDE, fractional scaling, and Wayland. KDE, for whatever reason, doesn't have a configuration panel built in for handling gestures. My usual fusuma + xdotool approach for sending XF86Back/XF86Forward keys when swiping don't work with Wayland. X11 apparently doesn't do partial scaling so Wayland is needed. Wayland leaves all sorts of visual artifacts. When two monitors are involved, one with no scaling and the other with fractional scaling, I get all sorts of visual issues.
Up until now I've been holding out and using 1080p displays. I figured surely in 2024 HiDPI would be a smooth experience on Linux.
Wish it had Bluetooth or wifi of it's own. It'd be awesome to build a remote controlled laptop!
Super notable, the Embedded Controller runs Linux Project's Zephyr. Love to see it! Not just an open source platform, an open source platform based around an absolutely top of class embedded OS.
I mean, I'm 100% converted if only they have trackpoint :>
My experience, having just bought a framework 13 with AMD internals a couple of months ago (and letting them build it for me), has been a purely flawless one with ubuntu 24.04. Everything just works and I love being able to swap the ports and the ethernet adapter as needed. The fan rarely makes a sound at all and it's blazing fast compared to the similarly spec'd system 76 darter pro it replaced (though it was a few years old). Battery life is "fine" but not amazing but charging is pretty quick, so it's still a bit of an improvement over the darter.
s/skilled/willing if not happy to fart around in their os config rather than doing actual work/
It's fun to mess around but we should manage expectations. It likely won't be trouble free.
Keyboard wakeup doesn’t—it’s due to the same problem as TFA describes for the 16 except for the 13 the Framework folks have submitted (the moral equivalent of) TFA’s fix to the kernel. Apparently firmware 3.06, currently in beta, is expected to finally solve the problem on the AMD 13.
S3 is unsupported (thanks AMD), and s0ix battery drain is higher than I’d like (IIRC like half a week in suspend with 64GB RAM).
Out of the box, the Wi-Fi/Bluetooth connectivity is also subpar, but that’s an issue common to the MediaTek cards AMD pushes on laptop manufacturers nowadays, not specific to Framework. (And it’s fixed by a $25 component swap.)
> S3 is unsupported (thanks AMD)
My AMD laptop (not a Framework) seems to have no issues with sleeping though (although I don't know what power state it is in).
The official line at the moment is that some kind of firmware bug led to something other than the keyboard signalling the same interrupt line. So at the moment keyboard wakeup needed to be disabled to get reliable sleep. We’ll see if the latest firmware update[1] works out (and how long it takes to come out of beta).
> I don't know what power state [an unspecified AMD laptop] is [sleeping] in
That’s the crux of the issue[2], though. It’s either suspend-to-RAM (S3; dump hardware state to RAM and power off most of the hardware including the CPU) or suspend-to-idle (S0ix or “Modern Standby”; try to put most of the external hardware in low-power states, downclock the CPU, and hope nothing wakes up). Apple did get their S0ix equivalent (“Power Nap”) right enough that most don’t complain; in PC-land, reports of laptops cooking themselves in bags due to inadvertent[3] wakeups from S0ix are everywhere.
I cannot find the exact CPU generation cutoffs at the moment, but the problem is that the CPU manufacturers are responsible for a good part of firmware development, and they no longer offer support for S3 at all—the corresponding procedure may be removed from the ACPI bytecode completely, or they may leave it there but declare it buggy and unreliable (usually truthfully). The only exception I know of is Linux-certified ThinkPads, because apparently Lenovo has enough weight to throw around that they can get special treatment.
[1] https://community.frame.work/t/framework-laptop-13-ryzen-704...
[2] https://blog.jeujeus.de/blog/hardware/laptops-will-not-sleep...
[3] Not clear how much of this is Windows looking for updates regardless of the user’s desire.
> kernel: ACPI: PM: Waking up from system sleep state S3
> kernel: CPU1 is up
> kernel: smpboot: Booting Node 0 Processor 1 APIC 0x1
> kernel: Enabling non-boot CPUs
> kernel: ACPI: PM: Low-level resume complete
So of course it might be not a "real" S3, but I didn't have a chance to test how long the laptop battery can last in suspended mode.
PM: suspend entry (s2idle)
Filesystems sync: 0.012 seconds
Freezing user space processes
Freezing user space processes completed (elapsed 0.003 seconds)
OOM killer disabled.
Freezing remaining freezable tasks
Freezing remaining freezable tasks completed (elapsed 0.002 seconds)
printk: Suspending console(s) (use no_console_suspend to debug)
atkbd serio0: Disabling IRQ1 wakeup source to avoid platform firmware bug <-- this is the Framework workaround
pcieport 0000:00:08.3: quirk: disabling D3cold for suspend
ACPI: EC: interrupt blocked
ACPI: EC: interrupt unblocked
OOM killer enabled.
Restarting tasks ...
done.
random: crng reseeded on system resumption
PM: suspend exitStill, it's a really nice laptop.
###
On top of disabling the wake sources, systemd >= 256 made some changes that broke sleep. (Relating to trying to freeze user.slice when you have NFS mounted or anything running in KVM.) If you're finding the machine takes a long time to sleep and refuses to wake up (frozen on unlock screen), reboot and check `journalctl -b-1` for messages about failing to freeze user.slice. If found, add:
# In /etc/systemd/system/systemd-suspend.service.d/disable_freeze_user_session.conf
[Service]
Environment="SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false"
Tracked here: https://github.com/systemd/systemd/issues/33083###
People said the speakers were bad. I don't really care about audio quality but... they're bad. If you're willing to use Pipewire (default with Gnome on Debian 12, easy to install for KDE/etc; see https://wiki.debian.org/PipeWire) there's an Easy Effects profile that cleans it up _a lot_.
Install Easy Effects (I'd recommend the flatpak as it has rnnoise included whereas the apt package doesn't; which is useful for mic filtering if you do calls) and load one of the profiles people have posted. I think I use this one: https://community.frame.work/t/guide-yet-another-easyeffects...
Makes the audio _way_ better.
(Potential gotcha: If you install Easy Effects from one source, start it, then try another source... It's still running in the background and the new instance you start will just bring it forward. Make sure you _fully_ exit before wasting hours trying to compile it because for some reason RNNoise isn't working in your flatpak.)
###
Had some issues with some apps starting to a black screen when the dGPU was installed. In KDE you can change the shortcut properties, under "Advanced Options" to uncheck "run using dedicated graphics card". Otherwise find some way to set `DRI_PRIME=0`.
You can force apps onto the dGPU by setting `DRI_PRIME=1` before running. This can be included on, e.g., Steam game launch options if desired.
###
Fingerprint scanner works but is kinda poorly supported in sddm/kde.
Install `fprintd libpam-fprintd`. Enroll with `fprintd-enroll yourusername`. Run `fprintd-verify` to validate it works.
From there you can run `sudo pam-auth-update` and enable the fingerprint scanner. The weirdness is "in sddm, you need to hit enter to attempt the login then when it seems to freeze put your finger on the scanner" type stuff. You'll figure it out.
###
The colour profile for the screen's been extracted from the Windows drivers and is available at: https://gitlab.com/samokosik/framework-icm-profile
Put it in `/usr/share/color/icc/colord/`. Run `colormgr get-profiles` to get the profile id (something like icc-bighexstring). Run `colormgr get-devices` to get the laptop screen's id (something like eDP-1).
Add the profile to the screen with `colormgr device-add-profile <device> <profile>`.
(For KDE can also install colord-kde to get this in your system settings.)
###
For hardware monitoring, Framework has a lm sensors config available.
Install lm-sensors. Then download https://raw.githubusercontent.com/FrameworkComputer/lm-senso... and place it in /etc/sensors.d/.
Run `sudo sensors-detect` to pick up all the sensors, then `sensors` should display all your temps/voltages/etc.
###
There's some USB PD weirdness. If you're trying to run docks/external displays/etc and getting flickering, disconnects, or other weirdness try giving them their own power supply rather than powering through the laptop.
###
LibreOffice has some nasty scaling issues with mixed-DPI displays (with the F16's internal display being fairly high res, you may run into this).
If you start it with `WAYLAND_DISPLAY=` set, it will force it into X11 mode where the server handles the scaling rather than the client (or the other way around?) and it's functional again.
I have a desktop system with a newish amd cpu and had the same issues as discussed on the github issue.
It wasn't a complaint about the FW16 so much as "If you're a typical HN person running Debian on it, here's some things that you might run into and may be helpful."
Apologies to anyone that gets through that whole formatting mess only to find this at the end.