| 1 |
# Hardware target: Framework Laptop 13 (AMD Ryzen AI 300) |
| 2 |
|
| 3 |
The second device Alloy is being written against, and the first that is not Intel. This document records what the machine is, what it changes about assumptions the FW12 doc could make, and which of those changes are measured rather than assumed. Companion to [STACK.md](STACK.md), [HARDWARE-FW12.md](HARDWARE-FW12.md), [MIGRATION-FW13.md](MIGRATION-FW13.md), and wiki `alloy-fw13-migration`. |
| 4 |
|
| 5 |
Per-device docs are the pattern, and this is the FW13 one. |
| 6 |
|
| 7 |
## What has and has not been tested |
| 8 |
|
| 9 |
**Alloy has never run on this machine.** Every figure below was measured from the machine's own running system, Pop!_OS 24.04 with kernel 6.17.9 under COSMIC on Wayland. Sysfs, EDID, `lspci`, and `fwupdmgr` do not care which distribution asks them, so the hardware facts carry; anything that depends on Alloy's own image, on sway, or on how a panel looks to a person does not, and is marked unverified. |
| 10 |
|
| 11 |
The one reboot that settles the unverified half is the boot test in `alloy-fw13-migration`: boot the SanDisk install medium, stop at disk selection, write nothing. |
| 12 |
|
| 13 |
Identifiers, for anyone matching this file to a machine: `Framework / Laptop 13 (AMD Ryzen AI 300 Series)`, board `FRANMGCP05`, BIOS 03.05. |
| 14 |
|
| 15 |
## Display |
| 16 |
|
| 17 |
This is the section with the most at stake, because fw13 is the second data point behind a constant fitted to one. |
| 18 |
|
| 19 |
- **Native panel:** BOE `NE135A1M-NY1`, 13.5 inch 2880x1920 (3:2), reported by EDID as 285x190 mm. |
| 20 |
- **Measured density:** 256.7 PPI from the detailed timing descriptor. The basic-parameter fallback (29x19 cm, whole centimetres) gives 252.2 PPI. Both matter because `panel_millimetres` prefers the descriptor and falls back to the centimetres. |
| 21 |
- **What the generator will seed: 1.75x.** `scale_for` computes `ppi / PPI_PER_SCALE` and snaps to the nearest rung of `SCALES`. 256.7 / 148.0 = 1.734, and 252.2 / 148.0 = 1.704. Both round to 1.75, so the seed does not depend on which half of the EDID is readable. Unverified: nobody has looked at it. |
| 22 |
- **The rule survives its second panel, arithmetically.** Fitting the constant to fw13 instead would give 256.7 / 1.75 = 146.7 against the 148.0 that fw12 produced, a 0.9 percent disagreement, well inside a quarter-step rung. That is a prediction agreeing with a prediction, not a validation: 1.75 has not been judged crisp by eye the way 1.25 was on the FW12. What it does mean is that `PPI_PER_SCALE` reads as a rule rather than a fitted constant, and the boot test is the thing that can still falsify it. |
| 23 |
- **Logical geometry at each candidate rung**, since the FW12 argument turned on usable columns: 1.5x gives 1920x1280, 1.75x gives 1646x1097, 2.0x gives 1440x960. Even at 1.75 the panel yields more logical width than the FW12 does at its shipped 1.25 (1536x960), so the "wastes columns" objection that rejected 1.5x on the FW12 does not transfer here. |
| 24 |
- **Contrast and color:** the DESIGN-LANGUAGE.md dark-mode L stops were to be validated on FW12's matte IPS. This panel is a different make and a different class, so a pass here is a second reading and not a duplicate one. |
| 25 |
|
| 26 |
### The external output, which the installer does not seed |
| 27 |
|
| 28 |
fw13 is a desk machine much of the time. As measured today, `eDP-1` reports `connected` but `enabled=disabled` and a BenQ RD280U is live on `DP-3`: 3840x2560 at 597x397 mm, 163.4 PPI, which `scale_for` would answer with 1.0x (1.104 rounds down to the 1.0 rung, 1.25 being 0.146 away). |
| 29 |
|
| 30 |
Two things follow. |
| 31 |
|
| 32 |
`detect_outputs` seeds the connectors the kernel reports lit, falling back to the connected built-in panel when nothing is lit, which is what a text-console install with no CRTC bound produces. Seeding on the built-in panel alone would leave a lid-closed desk install with a stanza for a panel that is off and nothing for the screen being used. A monitor merely plugged into a machine being installed is connected and not enabled, so it is still not seeded. Run against this machine's own sysfs, the generator proposes `output DP-3 scale 1` and nothing for the dark panel. |
| 33 |
|
| 34 |
And 1.0x on a 163 PPI 28 inch panel is the first case where the ladder's rounding is visibly load-bearing rather than incidental. It may well be right at desk distance, where the FW12's arm's-length argument does not apply. It is worth an eye during the boot test, and it is a hint that viewing distance is the term the PPI rule leaves out. |
| 35 |
|
| 36 |
Two layers had no real hardware behind them, only the `Mock`, and only one of them can be closed from here. The sysfs layer the installer reads is closed: both EDIDs are captured byte for byte in `crates/alloy/testdata/`, and the seeding rule is tested against a two-connector machine in each lid state. The sway-JSON layer is not, and cannot be until Alloy runs on fw13 under sway with the BenQ attached, which is what `reads_this_machines_real_outputs` is waiting for. |
| 37 |
|
| 38 |
## Graphics |
| 39 |
|
| 40 |
- **AMD Radeon 840M** integrated (PCI `1002:1114` rev c3, subsystem `f111:000b`), Krackan Point silicon, driven by in-tree `amdgpu`. |
| 41 |
- **Kernel floor, answered by version rather than by observation.** amdgpu on this generation wants a recent kernel. Measured: it runs on 6.17.9 here. Fedora 43 ships the 6.17 series, so Alloy's base clears the same bar the working machine does. Nothing about this has been observed under Alloy itself. |
| 42 |
- Every graphics paragraph in the FW12 doc is Intel and none of it carries. There is no equivalent Alloy-side work implied: the compositor scales, terminal apps scale with the compositor, and there is no per-app fractional-scale story to write here any more than there was there. |
| 43 |
|
| 44 |
## CPU and the build-host consequence |
| 45 |
|
| 46 |
AMD Ryzen AI 5 340 with Radeon 840M, 6 cores and 12 threads, one socket. |
| 47 |
|
| 48 |
This is not a neutral spec line. fw13 is the only x86_64 build host in the tree: Bento's AppImages and the makeover publishes run here. Anything that takes the machine out of service, an install included, stops releases until it is rebuilt by hand, which is why the `~/Code` bootstrap work (infra) is a prerequisite for step 5 of the migration and not a nicety. |
| 49 |
|
| 50 |
## Storage |
| 51 |
|
| 52 |
One NVMe device: `nvme0n1`, WD BLACK SN7100 2TB, in the M.2 2280 slot. |
| 53 |
|
| 54 |
**There is no free second M.2 slot for storage.** The 2230 socket exists and carries the MediaTek Wi-Fi module (`c0:00.0`, behind root port `02.3`). The only PCIe root ports with nothing behind them are the USB4 ones. |
| 55 |
|
| 56 |
So the disk options for an install are the offline shrink of `nvme0n1p3`, or external. Nothing here changes that the boot test needs neither. |
| 57 |
|
| 58 |
## Firmware (fwupd / LVFS) |
| 59 |
|
| 60 |
LVFS covers this machine well. `fwupdmgr get-devices` reports, among others: |
| 61 |
|
| 62 |
|
| 63 |
|
| 64 |
| System Firmware | 0.0.3.5 | updatable, matches BIOS 03.05 | |
| 65 |
| Fingerprint Sensor | 01000334 | updatable, supported | |
| 66 |
| Laptop Webcam Module (2nd Gen) | 1.11 | updatable | |
| 67 |
| WD BLACK SN7100 2TB | 7615M0WD | updatable | |
| 68 |
| TPM | 10.6.0.4 | | |
| 69 |
| Secure Processor | 00.3e.0c.74 | | |
| 70 |
| UEFI dbx | 20230501 | flagged `needs-reboot` | |
| 71 |
|
| 72 |
Alloy's contribution is still nothing, on the argument the FW12 doc makes: no first-boot firmware check, no prompt. The dbx entry is a live example of what that stance costs and accepts, and it is the machine owner's to run. |
| 73 |
|
| 74 |
## TPM |
| 75 |
|
| 76 |
`tpm0` present, TPM 2.0 (`tpm_version_major` = 2). The TPM-bound LUKS path has hardware to run against here, which on the validated FW12 it also does; fw13 adds nothing new to the design and does give a second machine to test the enrollment on. |
| 77 |
|
| 78 |
## Fingerprint reader |
| 79 |
|
| 80 |
Goodix `27c6:609c` on the power button, exposed as a USB device and carried by fwupd as an updatable device, which is a good sign for `libfprint` coverage (`goodixmoc`). Not enrolled and not tested. |
| 81 |
|
| 82 |
The PAM stance is the FW12 doc's, unchanged and worth restating because it is easy to get wrong: the file that matters for the prompt Alloy actually tells people to type is `/etc/pam.d/polkit-1`, not `/etc/pam.d/sudo`, because Alloy documents `run0`. Lockscreen unlock goes through swaylock's stack. |
| 83 |
|
| 84 |
## Wi-Fi, Bluetooth, audio, webcam |
| 85 |
|
| 86 |
- **Wi-Fi:** MediaTek MT7925 (`14c3:0717`, `mt7925e`). Different vendor from the FW12's Intel part, so nothing Intel-specific in that file applies. In-tree driver, firmware from `linux-firmware`. |
| 87 |
- **Bluetooth:** the same MediaTek part over USB (`0e8d:0717`). |
| 88 |
- **Audio:** AMD ACP coprocessor (`1022:15e2`, `snd_acp_pci`) plus two HDA controllers (`1022:15e3` and the display-audio `1002:1640`). AMD's ACP path is not the FW12's, and audio device naming through `alloy audio`'s `pactl -f json` reader is worth one look on this machine. |
| 89 |
- **Webcam:** Framework Laptop Webcam Module (2nd Gen), `32ac:001c`, UVC. |
| 90 |
- Physical camera and microphone switches are on the chassis, as on the FW12, and remain authoritative over any software mute. |
| 91 |
|
| 92 |
## Power management |
| 93 |
|
| 94 |
`/sys/power/mem_sleep` reports `[s2idle]` and offers nothing else, so the suspend model is the same as the FW12's: s2idle only, no S3. Lid close suspends. |
| 95 |
|
| 96 |
The FW12 doc tracks s2idle drain as an open concern on Intel. That measurement does not transfer; AMD's idle behaviour is its own question and is unmeasured here, under either OS. Same standing rule applies: `power-profiles-daemon` defaults, do not layer TLP on top. |
| 97 |
|
| 98 |
## Form factor |
| 99 |
|
| 100 |
Clamshell. The entire 2-in-1 half of the FW12 doc is absent rather than shelved: no `SW_TABLET_MODE`, no hinge daemon, no stylus, no rotation, no tablet-mode input gating. Touch is not present on this panel at all. |
| 101 |
|
| 102 |
This is the easier device, and that is the point of recording it: the FW12 was picked as the most demanding first target so these questions got answered up front. fw13 asks none of them. |
| 103 |
|
| 104 |
## Expansion cards |
| 105 |
|
| 106 |
Framework's card system, same as the FW12, and the same two obligations: no UI may name a fixed port ("the left port" is wrong on a Framework), and storage-card hot-plug is a udev and userspace-mount concern that Alloy mostly does not own. |
| 107 |
|
| 108 |
## What this machine gives Alloy back |
| 109 |
|
| 110 |
fw13 currently runs systemd 255, and `run0` needs 256. Alloy task `3587c247` ("verify the run0 build scripts on a systemd 256+ host") has been parked on needing a host, and Alloy's Fedora 43 base clears it. Moving this machine hands Alloy a systemd 256+ host, its first AMD target, and its second display density in one step. |
| 111 |
|
| 112 |
## Open questions |
| 113 |
|
| 114 |
- [ ] Boot the SanDisk medium, stop at disk selection: does amdgpu bring up the panel under Alloy's kernel, and what does the display generator actually propose? Both are predicted above and neither is observed. |
| 115 |
- [ ] Glyph crispness at 1.75x fractional under sway on a 256 PPI panel. This is the judgment that the FW12's 1.25x got and fw13's 1.75x has not. |
| 116 |
- [ ] 1.0x on the BenQ RD280U at desk distance: right, or the first sign that the PPI rule needs a viewing-distance term? |
| 117 |
- [ ] Multi-output `reconcile` against real hardware, laptop panel plus external, which no machine has exercised. |
| 118 |
- [ ] s2idle drain on AMD under the Alloy image, baseline against tuned. |
| 119 |
- [ ] fprintd enroll on the Goodix part, then unlock at swaylock and at a `run0` polkit prompt. |
| 120 |
- [ ] DESIGN-LANGUAGE.md dark-mode L stops on this panel, as a second reading against the FW12's. |
| 121 |
|