Framework
Laptop 13 AMD Ryzen 7040
Twenty distinct exact-model owners include five running Omarchy, with detailed Arch power measurements and current BIOS 3.20 outcomes.
Bottom line
Five Framework Laptop 13 AMD Ryzen 7040 owners have documented six direct Omarchy reports, so this is no longer an inferred Arch compatibility case. The ordinary laptop hardware has a credible Linux baseline, but firmware and upgrade combinations still shape reliability. Direct Omarchy reports include intermittent freezes with the Framework 13 Pro display, Qt rendering blur after lid-close resume and unexplained crashes. Other reports concern Omarchy itself — locking, media packages and Btrfs cleanup — and should not be mistaken for Framework hardware defects.
Existing owners have a strong reason to try Omarchy, but should update deliberately: keep a recovery path, check Framework's current BIOS notes, confirm which display and battery modules are installed, and test repeated lid-close, hotkey and dock cycles before relying on the machine. Used buyers should prefer a known-good configuration with the 61Wh battery and decide whether they want the original 60 Hz panel's lower demands or the 2.8K panel's cleaner 2:1 Linux scaling. Port position matters for displays and USB4.
What is reported
12 findings with cited evidenceInstallation and firmware
Five exact-model owners reached running Omarchy systems, and a Debian owner completed an encrypted graphical installation. Firmware-specific reports separately document deleted custom UEFI entries, a long BIOS 03.16 boot, a frozen BIOS settings page and one Fedora BIOS 3.20 update that hung for 8.5 hours before the battery drained, then resumed and completed after the machine began charging again.
The evidence supports a real Omarchy path, not a guarantee that every firmware operation is routine. Keep the default EFI fallback intact, attach power for firmware updates and read the current Framework release thread before changing BIOS versions.
Desktop and graphics
An exact Linux notebook and an original Linux review describe a stable Radeon desktop after early firmware fixes. Direct Omarchy reports later found Qt application content becoming blurry after a physical lid cycle and intermittent full-system freezes after installing the Framework 13 Pro display.
The Radeon graphics path is broadly usable, but a working fresh boot does not settle lid recovery or every display upgrade. The Pro-display freeze remains unresolved and should not be generalized to the original panel.
Internal display and brightness
The original 2256-by-1504 panel is documented in a working Arch-family setup and an independent review. A Debian owner saw unstable automatic brightness under Wayland, one Omarchy owner reproduced Qt blur only after physical lid close and another reported freezes after upgrading to the Framework 13 Pro screen.
The original and newer panels are different buying and upgrade decisions. The 2.8K panel offers clean 2:1 scaling, but the only direct Omarchy Pro-screen report in this corpus is unresolved and negative.
Keyboard, hotkeys and backlight
Keyboard input and backlight control are present in working Linux and Omarchy systems. The Pro-display Omarchy report ties intermittent freezes to volume or brightness keys, while the Debian report found brightness control unreliable in its Wayland session but normal under Xorg.
Ordinary typing is not the problem. On an upgraded display, explicitly test media keys, brightness keys and keyboard-backlight control before trusting the configuration for daily work.
Touchpad and pointing
The maintained Ryzen 5 Linux notebook reports the machine working out of the box, and Framework's current Fedora guide enables tap-to-click normally. That same guide retains an optional workaround for customer-reported lag or stutter that Framework says it has not reproduced internally.
There is a positive exact-model baseline, but no retained Omarchy report isolates touchpad behavior. Treat the optional workaround as a response to a reported symptom, not a default installation step.
Fingerprint and biometrics
The exact Linux notebook records fingerprint enrollment failing on old reader firmware and working after the firmware update. The original Linux review likewise says current firmware is important for the reader.
The reader has a Linux path, but none of the five direct Omarchy owners tests login enrollment. Update the reader through fwupd before treating a failed first enrollment as a permanent hardware limit.
Wi-Fi and Bluetooth
The Ryzen 5 notebook measured connected use with both the original RZ616/MediaTek adapter and a later Intel AX210. A Debian owner also reported Bluetooth working during initial use.
Wireless has direct exact-model Linux evidence, though not an isolated Omarchy network test. The RZ616 may need the correct regulatory domain to expose its full band and rate support.
Speakers, microphone and audio
A Debian owner reported working audio, and several Linux owners said BIOS 3.20 completed with normal or improved speaker output. Framework's Fedora guide still carries optional fixes for 3.5 mm jack buzz and headset-microphone routing.
Speaker playback, the headphone jack and headset input are separate checks. None of the direct Omarchy reports isolates all three.
Camera
The exact-model ArchWiki marks both the original and second-generation webcams working. None of the five direct Omarchy owners documents a video-call test.
This is a positive Arch compatibility result, not an Omarchy call-quality verdict. Test the camera and microphone together in the application you use, including after suspend.
Suspend and resume
One Ryzen 5 configuration reached the S0i3 low-power state and lost about 4.7% charge during roughly 12 hours of s2idle. Another machine intermittently hung while moving from s2idle to hibernation on BIOS 03.17 and 03.20. Direct Omarchy reports add lid-triggered Qt blur and a stale lock process that could allow an unlocked resume.
Basic modern standby can work, but wake quality, hibernation and session locking are different failure surfaces. Test several lid cycles and verify that the session is actually locked after wake.
External displays and docks
A DisplayPort monitor recovered after a post-update cable replug, a NixOS system logged USB-C cable-property errors without a visible failure and BIOS 03.16 removed USB-C DisplayPort output across two ports, several cards and two kernels. BIOS 3.20 later lists a dock-startup black-screen fix.
The port, expansion card, dock, firmware and kernel are all part of the result. Only three bays can carry a display signal, while both rear bays provide USB4.
Battery, power and thermals
The Ryzen 5 notebook measured roughly 3.1 to 4.5 watts at idle, 5.5 to 6.1 watts during light browsing and about 4.7% overnight s2idle loss. A Ryzen 7 review measured 12.1 hours of web browsing on the 61Wh battery, but also 46 to 49 dB(A) under demanding load. Separate Linux reports document charge-threshold and cycle-count failures, while one Omarchy owner reported crashes across all three power profiles without isolating a cause.
Battery capacity, software version, display and workload matter more than a single runtime number. The strong measured ceiling is not an Omarchy result, and the fan-control request does not prove heat caused the reported crashes.
Changes over time
14 dated events- Debian owner completes an encrypted install
Audio and Bluetooth appeared to work, while automatic brightness behaved poorly in Wayland and normally in Xorg.
- DisplayPort output returns after a cable replug
A monitor stopped working immediately after a firmware update and recovered when the owner reconnected it.
- Unavailable custom UEFI entries are deleted
BIOS 03.05 removed custom entries when their drive was unavailable, while the default EFI fallback remained discoverable.
- Ryzen 5 owner records a working Arch-family baseline
The maintained notebook documents working hardware, component fixes, S0ix state and repeated power measurements across Arch and NixOS configurations.
- Linux charge-control path regresses
User-space charge thresholds held on BIOS 03.03 and stopped holding on 03.04 in one NixOS report.
- BIOS 03.16 breaks one USB-C display path
An Arch owner lost USB-C DisplayPort output across two ports and two kernels while boot time grew beyond three minutes.
- First direct Omarchy report records unexplained crashes
The owner saw intermittent crashes across all three CPU profiles and asked for automatic fan control without establishing a causal link.
- Physical lid cycle blurs Qt application content
The Omarchy owner reproduced the problem after closing the lid, but not after choosing lock or suspend from the menu.
- Linux battery cycle count wraps after 255
Linux tools reported 65 cycles while the embedded controller reported 321 on BIOS 03.17.
- BIOS 3.20 adds newer chassis support and fixes
Framework added Pro chassis component compatibility and listed fixes for SED boot, battery status, one dock startup path and audio volume.
- Five routine BIOS updates and one prolonged hang
Five Linux owners completed the update without lasting failure. A Fedora owner's update hung for 8.5 hours, temporarily stopped booting and charging after the battery drained, then resumed and completed once charging returned.
- Killing a stale lock process restores session locking
The direct Omarchy report traces failed manual, idle and pre-suspend locks to a lingering hyprlock process, not to Framework hardware.
- Pro display upgrade is followed by intermittent freezes
An Omarchy 3.8.4 owner reported hard freezes after some volume or brightness key presses, with kernel page-fault and soft-lockup traces.
- Hibernation failure persists across firmware
One machine intermittently hung during the s2idle-to-hibernation transition on BIOS 03.17 and 03.20.