# My Framework 13 AMD Edition

> I try to maintain a good habit by recording everything technical every time when I own a new computing device (aka computer). Currently a scratchpad :(

## Hardware & Accessories

* Setup: AMD Ryzen 5 7640U with matte display.
* 2.8K is a must-have for HiDPI.
* Expansion cards: 2 USB-C (in the rear position), 1 Type A, 1 HDMI (3rd Gen)
* MicroSD card reader (2nd Gen).
* Charger: Gigastone 100W charger -- 2C + 1A
* I also recommend pqi's [2C+2A 100W](https://tw.pqigroup.com/products/pdc100w) (owned; sold out), [3C+1A 100W](https://tw.pqigroup.com/products/pdc100wv-20241028140450) (in stock), [140W](https://tw.pqigroup.com/products/pdc140w) (in stock) charger.

## Linux kernel configuration

btw I use GNU/Linux (Pop!_OS).
* p.s. Though (the stable version of) Pop!_OS is derived from Ubuntu 22.04, I am very grateful that the team at system76 managed to update the Linux kernel to 6.12, which treats most AMD-related quirks.

My current boot parameter `/etc/kernelstub/configuration`:

* `rootflags=subvol=@`: see [Filesystem setup (BTRFS)](#Filesystem-setup-BTRFS).
* `amdgpu.abmlevel=1`: see this thread, [Adaptive Backlight Management (ABM)](https://community.frame.work/t/adaptive-backlight-management-abm/41055). 2 is marginly tolerable, 3 and 4 are too aggressive to me.
* `amdgpu.dcdebugmask=0x10`: to [disable PSR](https://docs.kernel.org/6.12/gpu/amdgpu/driver-core.html#c.DC_DEBUG_MASK). Otherwise the cursor will stutter if the screen does not refresh for a while. It may increase power usage since the original purpose is to save battery?
See also https://gitlab.freedesktop.org/drm/amd/-/issues/3647.

## Severe bug: Adrupt reboot after waking from sleep

> [!Warning] Warning (resolved)
> I experienced the issue. See related:
>
> {%preview https://community.frame.work/t/responded-laptop-crashes-and-reboot-sometimes-after-resuming-from-suspend/43786 %}
> Moving the RAM module to another slot seems to have fixed my issue.

# OS Installation

Official guides:

* Tutorial: https://guides.frame.work/Guide/Ubuntu+22.04+LTS+Installation+on+the+Framework+Laptop+13/109
* Final touch (included in the last step of the tutorial above): https://github.com/FrameworkComputer/linux-docs/blob/main/ubuntu-22.04-amd-fw13.md
* But I don't want to install OEM kernels, mainly due to GRUB, so drivers for some components (e.g., fingerprint sensor integration) most guides assume will be absent on my system

## Filesystem setup (BTRFS)

* The most informative guide I can find: https://mutschler.dev/linux/ubuntu-btrfs-20-04/ (but I skip all LUKS parts)
* https://wiki.manjaro.org/index.php/Btrfs#Familiar_with_btrfs-slang_.3F
* Do NOT enable BTRFS quotas! https://unix.stackexchange.com/questions/190405/how-does-enabling-btrfs-quotas-impact-the-system

## Useful resources

* ArchWiki, as always: https://wiki.archlinux.org/title/Framework_Laptop_13.
* A collection on resources & battery stat: https://github.com/tlvince/framework-laptop-13-amd-7640u

# Topics

## Embedded controller (EC)

Tools ~~(assuming no CrOS EC kernel module, see [this](https://github.com/FrameworkComputer/framework-system/issues/20))~~ Update to kernel 6.12 to use them:

* ectool, unofficial utility to communicate with the embedded controller: https://gitlab.howett.net/DHowett/ectool.
Usage: `ectool --interface=lpc console`
* Framework provides an official one: https://github.com/FrameworkComputer/framework-system.
Usage: `framework_tool --driver portio --console recent`
Or [use this tiny wrapper](https://gist.github.com/andy0130tw/b0e254ae0626853c34fd458773a5fe59).

> Note that you can drop `--interface=lpc` and `--driver portio` if using Linux Kernel 6.12, available for Ubuntu (Pop!_OS?) 22.04 around March 2025.

## Power management

Mega thread: [[Guide] FW13 Ryzen Power Management](https://community.frame.work/t/guide-fw13-ryzen-power-management/42988).

Currently I use [`system76-power`](https://github.com/pop-os/system76-power) from master branch (just `cargo build` and then copy the result to replace `/usr/bin/system76-power` and restart the service for it), which is included by default in Pop OS, but seemingly missing several important parameters for saving power compared to PPD.

It is rumored that [auto-cpufreq](https://github.com/AdnanHodzic/auto-cpufreq) performs really well, but I don't have time to try.

BTW I found [this reply](https://community.frame.work/t/tracking-linux-battery-life-tuning/6665/407) and it seems to be effective:

# get its current value
$ cat /sys/module/pcie_aspm/parameters/policy
[default] performance powersave powersupersave

# set its value to "powersupersave"
$ echo powersupersave | sudo tee /sys/module/pcie_aspm/parameters/policy
powersupersave

Also reducing the screen refresh rate from 60Hz to 48Hz seems to help *a lot*.

### Battery time

With these settings under 25% brightness (note that "relative brightness" is firmware dependent due to PWM parameter change in v3.09) and a moderate (e.g. Firefox editing this document with ~10 background tabs, Sublime Text) workload, I can get almost **6 hr** uptime from 80% to battery depletion. But if there is audio/video playing in the background the time would drastically reduced to ~4 hr.

See [tlvince/framework-laptop-13-amd-7640u](https://github.com/tlvince/framework-laptop-13-amd-7640u) for a comprehensive view.

## Misc issues

### Touchpad is too sensitive (X11)

Mostly can be configured via xinput. Say you want to change scrolling speed under X11 (10~50, default 15, larger is *slower*). Create a file at `/usr/share/X11/xorg.conf.d/30-touchpad.conf`:

Section "InputClass"                                                                            
Identifier "Touchpad"
Driver "libinput"
  MatchIsTouchpad "on"
  Option "ScrollPixelDistance" "25"
EndSection

Takes effect on the next login.

#### For Firefox under X11

Set `MOZ_USE_XINPUT2=1` with some tweaks in `about:config`:

| Key | Value |
| ------------------------------ | ----- |
| apz.fling_friction | 0.005 |
| apz.gtk.pangesture.delta_mode | 2 |

> A good place to enforce the env is to put in `/etc/security/pam_env.conf`:
> ```
> MOZ_USE_XINPUT2 DEFAULT=1
> ```

### HW decoding in Firefox

It is disabled by default on AMD GPUs and can be enabled with `media.ffmpeg.vaapi.enabled` set to `true`. See [gfxinfo](https://sourcegraph.com/github.com/mozilla/gecko-dev@FIREFOX_ESR_115_3_X_RELBRANCH/-/blob/widget/gtk/GfxInfo.cpp?L974). The GPU only supports H264, VP9, AV1, which can be confirmed in <about:support>.

### Totem with vaapi will result in incorrect color

[Wrong colours when playing a H.264 with gstreamer-vaapi installed](https://gitlab.gnome.org/GNOME/totem/-/issues/309).

Have tried `allow_rgb10_configs=false` but it did not work. So removing `gstreamer-vaapi` (or just using VLC :laughing:) seems to be the only workaround.

### Monitoring the power consumption

I wonder if I can monitor these data to benchmark each solution: [Measuring effective power received on a USB-C port under Linux](https://www.reddit.com/r/UsbCHardware/comments/rbwd1t/measuring_effective_power_received_on_a_usbc_port/).

Framework's EC provides some information about active PD states (negotiated voltage and current) for each port.

EC log has an estimated drain time, but I cannot utilize it without polling. The output of `ectool` is longer, but I don't know why.

The handy `powerdraw` script: https://gist.github.com/guss77/c91e1d6583fad5b5c917eafc345cb81b

### Auto-adjustment of (screen) backlight is too crude

See https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/issues/575 for inspiration.

For now, I just disabled that option in GNOME and controlled it manually.

# Sleep & Hibernation

There is some random wake up behavior observed: https://community.frame.work/t/resolved-systemd-suspend-then-hibernate-wakes-up-after-5-minutes/39392. Also, it is really annoying that closing the lid will wake up the OS from sleep.

Use [s2idle](https://gitlab.freedesktop.org/drm/amd/-/blob/master/scripts/amd_s2idle.py) script to detect problems. One common point it suggests is to add `rtc_cmos.use_acpi_alarm=1` into the boot parameter. However this is no longer required in newer (6.7+) kernels.

Note that it is not the lid open/close event itself that wakes up the system, but the extra IRQ interrupts whose effect is similar to a keystroke. So it happens even when the setting in the DM is disabled.

Disable lid wake up behavior through udev: https://community.frame.work/t/tracking-framework-amd-ryzen-7040-series-lid-wakeup-behavior-feedback/39128/45

ACTION=="add", SUBSYSTEM=="acpi", DRIVERS=="button", ATTRS{hid}=="PNP0C0D", ATTR{power/wakeup}="disabled"
ACTION=="add", SUBSYSTEM=="serio", DRIVERS=="atkbd", ATTR{power/wakeup}="disabled

## How to enable hibernation

On Pop!_OS it is possible to enable hibernation [as instructed by System76](https://support.system76.com/articles/enable-hibernation/). It is recommended that you encrypt your swap partition by enabling LUKS to prevent the secret being harvested during the hibernation. Here is my recap:

First of all, some context. Depending on your setup you might need to disable the `cryptswap` partition (or swap file) first. This swap method generates an ad-hoc key that differs at every boot, which is not suitable for our purpose. The drawback is that you need to enter the password at boot in order to unlock your swap.

Once the LUKS is set up, modify `/etc/crypttab`:

-#cryptswap UUID=(old UUID) /dev/urandom swap,plain,offset=1024,cipher=aes-xts-plain64,size=512
+swap UUID=(new UUID) none swap,plain,luks,offset=1024,size=512

Referring to the output of `lsblk -o NAME,SIZE,UUID`:

NAME                  SIZE UUID
zram0                  16G 
nvme0n1             931.5G 
├─nvme0n1p1          1024M ...
├─nvme0n1p2             4G ...
├─nvme0n1p3         893.5G ...
└─nvme0n1p4            33G ...  <-- copy this UUID to crypttab
  └─nvme0n1p4_crypt    33G ...  <-- NOT this

Also `/etc/fstab`:

-/dev/mapper/cryptswap  none  swap  defaults  0  0
+/dev/mapper/swap  none  swap  defaults  0  0

I have not encounter any problem once it is setup correctly. Note that

1. Double check your crypttab pointing to the desired swap partition **by UUID**. It will be **wiped** upon a fresh start, so you clearly do not want it to leave any ambiguity!!
2. You seemingly do not have to set the `resume` target. I do not know why, but it looks Pop!_OS handled that by default.