Two field units got no fingerprint sensor from fingerprintd 0.2.3's
manifest: its focal64 line pinned the sha256 of one Android build's
trustlet (16.82.0, the dev phone's), and Fairphone re-signs that trustlet
every release, so the pin matches exactly one of the six builds seen. A
user on 16.100.0 had to edit the manifest by hand; another ended up with
a file QTEE refuses.
The extractor now tries the active slot's partitions first
(androidboot.slot_suffix from the kernel command line): for a signed
image only the running TZ's own slot is guaranteed to load. An mbn line
may give '-' instead of a hash, which means structural verification
only: ELF64 header, every segment present at the size its program header
declares, page-aligned offsets, a sane total. The loader in TZ verifies
the signature and the per-segment hashes itself and refuses a damaged or
foreign image (one flipped byte -> ERROR_ELF_SIGNATURE_ERROR, measured),
so the whole-image hash added fragility and no protection. A real sha256
is still honoured, and the sha256 of what was installed is logged either
way.
--refresh re-derives mbn dests even when a file exists, replacing it
only with an image that verifies; consumers call it from
post-install/post-upgrade so a fresh 'apk add' needs no reboot and a
hand-placed or wrongly pinned trustlet is replaced on the next upgrade.
Verified on the dev phone (busybox): malformed inputs are refused with a
reason (missing, truncated or oversize segment; non-ELF, ELF32 or short
mdt; a garbage offset), both slots reassemble to the known-good hash, a
foreign file survives a plain run and is replaced by --refresh, a failed
refresh keeps the old file, pins still work, and the real post-upgrade
path re-derived the installed trustlet with the daemon restarting on it.
Record: fp6 repo journal/blobs/ and journal/fingerprint/, 2026-09-11.
Until now both were pinned here by version and sha256, so every release
of either needed a commit and an image run, in the right order
(fingerprintd 0.2.4 would have taken: push, wait for the registry, pin,
push). The pin gated fresh installs only: every installed phone already
takes the newest registry package on 'apk upgrade'.
registry-fetch.py resolves the newest version of each group (imsd + its
systemd unit; fingerprintd + systemd + agent, the subpackages at the
anchor's version, or it fails) and verifies the way apk does on the
phone: the index signature against the key catcrafts-fp6-repo ships --
the signer's name must be that key's too -- each apk's control checksum
against the index, and its data segment against the control's datahash.
Anything that fails is not written. The resolved versions and sha256s go
into the release's build-info.txt, so an image still names its exact
packages.
Tested against the live registry: it resolves imsd 0.3.3-r0 and
fingerprintd 0.2.3-r0 with sha256s identical to the five pins this
removes; a wrong key, a key of another name, a tampered control segment,
a corrupt or swapped data segment, a truncated file and a missing
subpackage are each refused with a reason.
Same string as the kernel commit, for the three compiled aports this image
builds itself: -march=armv8.6-a+fp16fml+aes+sha3+sm4 -mtune=cortex-a720
appended to CFLAGS (and CXXFLAGS for libcamera). abuild builds these with
Alpine's GCC; the string is gcc's own -march=native expansion on the phone
re-based on armv8.6-a, and it assembles on GCC 15 with binutils 2.45.1 and
on GCC 16 (whose -mcpu=cortex-a720 expansion binutils 2.45 rejects). On the
phone itself gcc -flto, g++ and clang all compile, link and run it.
The base stops at 8.6 on purpose: this phone exposes neither SVE nor MTE
(userspace autovectorised for SVE2 would SIGILL), and not WFxT either.
pkgrel bumps so apk upgrade delivers the rebuilt binaries.
Two field units got no fingerprint sensor from fingerprintd 0.2.3's
manifest: its focal64 line pinned the sha256 of one Android build's
trustlet (16.82.0, the dev phone's), and Fairphone re-signs that trustlet
every release, so the pin matches exactly one of the six builds seen. A
user on 16.100.0 had to edit the manifest by hand; another ended up with
a file QTEE refuses.
The extractor now tries the active slot's partitions first
(androidboot.slot_suffix from the kernel command line): for a signed
image only the running TZ's own slot is guaranteed to load. An mbn line
may give '-' instead of a hash, which means structural verification
only: ELF64 header, every segment present at the size its program header
declares, page-aligned offsets, a sane total. The loader in TZ verifies
the signature and the per-segment hashes itself and refuses a damaged or
foreign image (one flipped byte -> ERROR_ELF_SIGNATURE_ERROR, measured),
so the whole-image hash added fragility and no protection. A real sha256
is still honoured, and the sha256 of what was installed is logged either
way.
--refresh re-derives mbn dests even when a file exists, replacing it
only with an image that verifies; consumers call it from
post-install/post-upgrade so a fresh 'apk add' needs no reboot and a
hand-placed or wrongly pinned trustlet is replaced on the next upgrade.
Verified on the dev phone (busybox): malformed inputs are refused with a
reason (missing, truncated or oversize segment; non-ELF, ELF32 or short
mdt; a garbage offset), both slots reassemble to the known-good hash, a
foreign file survives a plain run and is replaced by --refresh, a failed
refresh keeps the old file, pins still work, and the real post-upgrade
path re-derived the installed trustlet with the daemon restarting on it.
Record: fp6 repo journal/blobs/ and journal/fingerprint/, 2026-09-11.
The FP6 is 4x Cortex-A520 + 4x Cortex-A720 and this image boots nothing
else, so pass the compiler KCFLAGS="-march=armv8.6-a+fp16fml+aes+sha3+sm4
-mtune=cortex-a720". The stock arm64 build gives the compiler no arch flag
at all (so one image can boot any Armv8 board).
The string is what `gcc -march=native` derives on the phone, re-based on
armv8.6-a so clang can express the same set (clang has no flagm2/rcpc2/
frintts tokens; it reaches them through the architecture level). 8.6 is the
highest level whose mandatory set the phone exposes: 8.7 would assume WFxT
and 9.x SVE2, and neither is in its hwcaps or ID registers. clang emits
identical code for this and for -mcpu=cortex-a720+nosve+nomemtag; the
difference is only which system features (SPE, ETE, TRBE, FPAC) it knows
about, none of which generate code.
Verified on eef717f978f1 with the aport config: builds with zero warnings,
same module set as r100 (417), compat vDSO untouched, boots the dev phone
with a clean dmesg and a GREEN selftest. Record:
fp6 journal/base/captures/2026-09-05-mcpu-a720-verification.md.
Pin the registry's imsd 0.3.3-r0. The media leg plays AMR narrowband and
G.711 as well as AMR-WB, so calls from landlines and other narrowband
gateways ring instead of being refused with 488; a refused INVITE no longer
flashes the dialer; the offer lists AMR-NB after AMR-WB; CODECS=<list>
overrides the codec set for bench work. 0.3.3 over 0.3.2: the media leg
resolves the audio user once and thread-safely — a getpwnam race between
the mic and playout threads could start both PipeWire helpers in
/run/user/0 and answer a call into static.
Verified on the dev phone 2026-09-08 with the registry apks: 0.3.2 exposed
the race on an incoming call (found by this very check), 0.3.3 carries the
fix; the code path had sixteen bench calls that evening (PCMA and AMR-NB in
both directions, default AMR-WB unchanged).
CI run 52 failed at minute 57 with `fp6-vendor-blobs-extract: FAILED` from
abuild's checksum verification: 9575e55 changed the extractor and left its
sha512sums entry alone. Nothing was installed or published; latest is the
run-51 image.
Fix the sum, and stop paying an hour to learn it. check-aports.sh sources
every APKBUILD under aports/ and compares the committed sha512sums of its
local source files (scripts, units, configs, patches, including ones in a
subdirectory) against the files themselves. build.sh runs it before
pmbootstrap touches anything, so this class of mistake now fails in the first
seconds of a run and prints the line to paste. Aports whose sums build.sh
regenerates with pmbootstrap checksum are read from build.sh and skipped, so
the two lists cannot drift.
Verified: the checker reports exactly the run-52 mismatch on the tree as
pushed and nothing on the tree as fixed; a scratch copy with one corrupted
sum is caught; the fixed aport builds under abuild in an alpine:edge
container (the only complaint was the throwaway signing key at the index
step, which the CI's pmbootstrap flow does not have).
The daemon's own package CI publishes it to the registry the same way imsd's
does, so the image takes it from there: the exact apk a user later gets via
apk upgrade, sha256-pinned, re-signed for the chroot. Section 3b now fetches
both sets, and every fetched file must have a pin -- the check used to be
`grep . | sha256sum -c`, which an empty pin list would have sailed through
with nothing checked.
Three apks: the daemon, its systemd units, and the session agent, which does
nothing until a user writes ~/.config/fingerprintd/fingers.conf. The daemon
needs the kernel aport's CONFIG_QCOMTEE=m (pkgrel 101) and fp6-vendor-blobs
1-r2's mbn directive to reassemble the trustlet, both built in this run;
0.2.3 says >=1-r2 so a mismatched pair is refused rather than installed.
The CI publish step skips fingerprintd-* like imsd-*: registry-sourced, not
ours to republish. README: fingerprint in the list, and the two things a user
will otherwise report as a dead sensor -- the lock screen listens for 60
seconds after it appears, and a held press is what the matcher was measured
on -- plus the untested question of stock Android's own fingerprints after
using this.
Verified on the dev phone (fp6 repo journal/fingerprint/, 2026-09-05): the
registry 0.2.2 package enrols through Plasma's Users page and unlocks the
lock screen; 0.2.3 differs by the dependency and a post-upgrade restart. The
image build itself, with the fprintd purge inside the chroot, runs first in
CI.
The fingerprint stack needs /dev/tee0, and the pmOS config has never built the
driver -- so every session so far has loaded an out-of-tree module. That has
been recorded since 2 September as the release blocker, on the reading that
drivers/tee/qcomtee/Kconfig's `select QCOM_TZMEM_MODE_SHMBRIDGE` would flip
tzmem out of Generic mode and drag a boot+selftest round with it.
It does not. QCOM_TZMEM_MODE_SHMBRIDGE is a member of a choice block, and
Kconfig cannot select a choice member -- the statement is inert, and silently
so. Setting CONFIG_QCOMTEE=m and running olddefconfig against the tree
produces exactly one line of difference and leaves CONFIG_QCOM_TZMEM_MODE_
GENERIC=y, which is the mode every fingerprint measurement was taken on.
The driver is already in the base tree; the only reason it was out-of-tree
here was that nothing enabled it. Verified on the dev phone: the module built
from this config carries ZERO module parameters against the research build's
95, matching vermagic, and the phone boots on it with modules-load.d bringing
it up, /dev/tee0 present, fingerprintd ready and the enrolled template
loading. So the shipped module is upstream code on the tested tzmem mode.
Not pushed. Whether to ship QCOMTEE with tzmem in Generic mode is a separate
question with a real answer -- journal/tee warns about that mode -- and it is
now sequenceable on its own instead of forced by a select that does nothing.
The fingerprint matcher is a proprietary OEM-signed trustlet, and it is not
shipped as one file: QTEE images live in the modem partition's image/ as an
ELF header+hashes file plus one payload per program header, and the loader
wants each payload written back at its segment's p_offset. So the existing
file directive cannot reach it.
An mbn directive does, with the same guarantees file has: the sha256 is of
the reassembled image, a mismatch tries the next partition, and an unverified
image is never installed. Reassembly is not a concatenation -- segments are
page aligned but not contiguous, gaps stay zero, and two pairs of focal64's
nine segments share an offset, so they are written in index order and the
later one wins, exactly as the bring-up repo's reassemble.py does.
Verified on the dev phone against the hash QTEE has actually accepted since
August: 3600472 bytes, sha256 1930c490..., reassembled from the phone's own
modem_a. The retry path was verified too, with a deliberately wrong first
partition -- which is how the variable clobber got caught: POSIX sh has no
locals, and reassemble() taking rdir= rewrote its caller's copy to the mount
path, so the second partition would have been searched at $MNT/$MNT/...
The fast path needed teaching as well: mbn's dest is the fifth field, and a
first boot would otherwise have exited early and extracted nothing.
Not pushed. The consumer fragment lives in the fingerprintd package.
Run 50 got past the key copy and the re-sign, then died on the move into
pmbootstrap's packages dir: abuild created that directory from inside the
chroot, so it belongs to the chroot user (uid 12345) and the build user
cannot write there. Install the files via sudo with the directory's own
owner and mode 0644, as abuild would have left them, and fail with a clear
message if the directory is missing instead of creating a wrongly-owned one.
Run 49 died in section 3b: pmbootstrap's abuild-keygen runs inside the
chroot as its own user (uid 12345), so the key in config_abuild/ is 0600 to
that uid and the build user cannot read it; openssl dgst -sign exited 1 and
apk-resign.py swallowed its stderr. Take a private copy via sudo for the
duration of the re-sign, and make the script name an unreadable key and let
openssl's stderr through instead of hiding it.
The imsd repo's package CI is now the only producer of the imsd apk. The
image installs the exact registry package users get via 'apk upgrade'
(pinned version + sha256 of the registry files), so the two can no longer
diverge and the payload-parity rule between two packagings is gone.
pmbootstrap has no knob for a third-party repository, and after the main
'apk add' it re-adds every package in its local packages dir by file path,
which makes apk verify the package's own signature. Registry packages are
signed with per-run keys nobody keeps (phones trust the registry-signed
index), so apk-resign.py replaces the signature stream with one from this
run's abuild key; control and data streams stay byte-identical and the
identity checksum equals the registry's. Verified on the host with apk
3.0.8: originals UNTRUSTED, re-signed OK, checksums equal.
The publish step skips imsd-*: those files came from the registry.
The imsd repo now owns its apk packaging (packaging/aport/, imsd commit
17e0f6b); build.sh copies the aport out of the same pinned checkout it
archives, so daemon and packaging can never skew. The local
aports/modem/imsd copy is gone.
0.3.1 ships the ims-pdn-up hardening (mmcli errors logged verbatim per
attempt, connect attempts gated on network registration, IMS_IP_TYPE
configurable) — the field-debugging fix for undecodable bearer failures
(journal/users/tu11ebukk), tested on the dev phone. build-info.txt now
derives the imsd version from the aport instead of hardcoding it.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The preset fix (6ecc1dc) makes the unit run, but multi-user is too late: the
sound card probes at ~21 s, hard-fails (-2, no retry) on the missing ACF, and
the extractor's amp rebind at ~60 s cannot re-form a card whose machine
driver already failed. Re-probing the machine driver does re-form it, but a
late-formed card has a dead capture path - the wcd9378 TX sequencer refuses
PS0 (act_ps 0x3) until the next boot. So rebinding after the fact can never
fully win; extraction has to happen before the drivers probe.
- fp6-vendor-blobs.service: DefaultDependencies=no, run after remount-fs and
before systemd-udev-trigger, so blobs exist before module coldplug.
multi-user stays a second Wants as a post-udev retry if the early run
failed (by-partlabel/make-dynpart-mappings fallbacks need udev).
- aw88261-acf.manifest: add 'rebind platform sound' so the fallback path at
least recovers playback the same boot (capture then heals on reboot).
- fp6-vendor-blobs.post-upgrade (pkgrel 1): systemctl preset + immediate
extract, so installs of the 2026-08-24 image (unit shipped disabled, no
version bump to deliver the preset) finally heal via plain apk upgrade.
- soc-fairphone-fp6-audio pkgrel 1: carries the manifest change.
Verified on the dev phone with the exact staged bytes (sha256-compared):
simulated fresh install (ACF removed, reboot) extracts at 13.3 s, coldplug
probes the amps at 15.1 s, card init at 20.9 s loads the ACF cleanly, and a
1 kHz speaker-to-mic loopback passes on that same first boot with zero TX
sequencer warnings; next boot takes the all-dests-present fast path in 25 ms.
Evidence: fp6 repo journal/blobs/, 2026-08-29.
Assisted-by: Claude:claude-fable-5
The package installs a multi-user.target.wants symlink, but that alone does
not survive image build: pmbootstrap runs systemctl preset-all, which removes
manually-installed .wants links for any unit whose preset does not enable it.
The 2026-08-24 image therefore shipped the service as
'disabled; preset: disabled' and it never ran, so aw88261_acf.bin was never
extracted from the stock vendor partition and a fresh install came up with no
sound card at all.
Reproduced and verified on the dev phone: with no preset file installed,
systemctl preset leaves the unit disabled; with it, the unit comes back enabled
and stays enabled across a full preset-all.
Investigation and evidence: fp6 repo journal/blobs/, 2026-08-28.
Assisted-by: Claude:claude-fable-5
New package fp6-vendor-blobs: a manifest-driven systemd oneshot that
copies proprietary blobs out of the stock Android partitions on first
boot. pmOS installs flash only boot+userdata, so every installed unit
still carries the stock vendor/dsp partitions - the device duplicates a
file it already contains, for its own operation, and nothing proprietary
is distributed by us. Partitions are mounted read-only (ext4 additionally
with noload - not even a journal replay touches the stock data), every
copy is sha256-pinned and a miss fails loudly, and the consuming devices
are unbound and re-probed afterwards so the feature works the same boot.
The rebind is unconditional by design: aw88261 binds on a bare i2c
chip-id probe and requests the ACF only at ASoC card init (~21 s, after
SoundWire enumeration), so a bound device can still be one that lost the
firmware race - and that failed request is never retried.
soc-fairphone-fp6-audio (pkgver 4) stops shipping the blob, installs the
manifest fragment instead, and re-runs the extractor from
post-install/post-upgrade so upgrades restore the file immediately (the
old package version removed it on upgrade). License drops back to plain
BSD-3-Clause - nothing proprietary left in the package.
Verified on the dev phone (fp6 repo journal/blobs/captures/
2026-08-24-first-boot-extractor-verification.txt): first-boot extraction
+ same-boot audio, mid-session post-upgrade recovery, and the everyday
fast-path no-op; committed files byte-identical to the tested deployment.
Assisted-by: Claude:claude-fable-5
pmOS's modem-gnss.service runs two qmicli calls, and the second --
--loc-set-nmea-types=all -- can never succeed on this modem: the LOC
engine answers QMI error 94 'NotSupported' to both get and set. That is
a permanent capability gap, not the boot race Restart=on-failure exists
for, so the unit failed and restarted every 30 s for the whole uptime
(restart counter 25 after 13 minutes; 165 over one evening). Its
StartLimit does not stop it either: 10 restarts at RestartSec=30 span
~303 s, just past StartLimitInterval=300.
Ship a drop-in that tolerates that one command's failure. The boot-race
retry stays armed -- a LOC service that is genuinely not up still fails
the first ExecStart. Nothing is lost: ModemManager issues its own
set-NMEA-types and takes the same 94 regardless, and location comes from
the Position Report path our modemmanager patches add.
Byte-identical to the drop-in verified on the dev phone (sha256
b0b5f71b0f25c3c5a8fc9e926f187412a6711da95f773234065f37ddcc1d3c6d):
across a reboot the unit runs once, Result=success, 0 restarts.
Assisted-by: Claude:claude-opus-5
su scrubs the environment, so the escape hatch from the previous commit
never reached the build user (verified: libcamera still built crossdirect
and failed identically).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
crossdirect's /native bridge breaks under local podman (cc: cannot execute
cc1: posix_spawnp ENOENT in meson setup) while qemu-only builds work fine;
the env flag routes the affected packages (libqmi/MM/libcamera + a new
explicit imsd pre-build, since install has no per-package flag) through
--no-cross. Identical package output, slower build; kernel stays
cross-native. CI behavior unchanged when the env is unset.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The pmOS gitlab truncates clones under load (early EOF / invalid
index-pack); the pip install runs in the root branch before clone_retry
exists, so give it its own 3-attempt loop.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Charger-insertion boots (androidboot.mode=charger, ABL-appended) divert to
a minimal charging.target instead of the full UI, ending the dead-battery
bootloop: ADSP charging/USB-PD runs, splash+panel killed ~6-10s in via an
initramfs hook, modem+cdsp stopped, radios/sensors suppressed, CPU capped.
Power key reboots to a normal boot, volume-up shows battery status,
volume-down enables USB ssh, unplug powers off. Measured >= breakeven on a
100mA-classified SDP port, strongly net-positive on real chargers.
Suspend duty-cycling (~13mA floor) exists behind an off-by-default flag:
resume from deep suspend intermittently kills the UFS link (hibern8 exit
failed ret=5) - do not enable until that kernel bug is fixed.
Byte-identical to the deployment verified on the dev phone 2026-08-24
(journal/power: r5 armed tests, crash autopsies, measurements).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Divide the softISP statistics window into 16x12 zones and, when a white
point locus is tuned, vote only with zones whose implied gains lie within
zoneGateMargin of the locus - a large coloured light source can no longer
drag the white balance. Validated on-phone 2026-08-24: keyboard-scene A/B
shows a ~1700 K estimate shift caused solely by the gate (desk renders
neutral instead of blue); torch-toggle stability equal or better than r8
(settle 1.35-1.79 s, ON-edge repeatability +-0.011, CCM churn 21 vs 30
switches); AF regression clean. Evidence:
journal/camera/captures/2026-08-24-awb-zonegate-validation.md
Assisted-by: Claude:claude-fable-5
The package declared BSD-3-Clause while shipping aw88261_acf.bin, a
verbatim proprietary Awinic blob extracted from the stock vendor
partition - an affirmative false claim about the file. Mark the license
compound (BSD-3-Clause AND proprietary) and document per-file provenance;
the durable fix (FairBlobs adoption or install-time on-device extraction)
is tracked in the audio journal.
Assisted-by: Claude:claude-fable-5
pkgver 7.1.2 -> 7.2.0; config regenerated from the pmOS 7.2.0-r0 config
plus the FP6 bring-up fragment (same enables as before), olddefconfig'd
against the rebased combined-stable.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
milos-linux combined-stable now carries the camera-main merge
(af49850e65bd): camss C-PHY support, the IMX896 main sensor, the DW9784
AF controller and the board DTS for all three (the VL53L3 ToF node is
DTS-only for now, its driver is future work). Kernel config gains
CONFIG_VIDEO_IMX896=m + CONFIG_VIDEO_DW9784=m - the camss core, CAMCC
and CCI are on since the ultra-wide commit, and the libcamera side
(IMX896 tuning, contrast AF, AWB stabilization) already ships since
aport r8.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
gitlab.freedesktop.org's on-demand archive endpoint 503/504s for hours
at a stretch: runs #25, #27, #30 and #31 all died in 'abuild checksum'
fetching the pinned libqmi tarball, outlasting the 3x30s in-run retry.
git clone is served from a different code path and holds up (verified
against all three repos while the archive endpoint was flaky), so clone
libqmi/ModemManager/libcamera (retried) and git-archive the pinned refs
into the aports, the same way the kernel and imsd tarballs are already
produced. The pins stay single-sourced in the APKBUILDs.
libcamera gains a checksum step: its committed sums were for the
fd.o-served tarball, and git-archive output is not byte-identical.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The softISP AWB is pure gray world, so panning swings ColourGains with
the frame average (white wall renders green when the frame is
warm-dominated, dark desk renders red when cool-dominated) and the CCM,
interpolated over a CT estimated from those gains, amplifies and
quantizes the swings.
Patch 0015 (ours, original work) adds optional per-sensor Awb tuning to
the simple IPA: a piecewise-linear locus of calibrated illuminant white
points in gain space that the gray-world estimate is clamped to
(clampMargin), a per-stats-frame EMA on the applied gains (damping)
with a fast-converge path for persistent illuminant changes, and CT
interpolated from the applied gains' position along the locus - on the
same scale as the tuning file's ccms table - instead of the generic
estimateCCT(). Tuning files without whitePoints keep the previous
behaviour exactly, so every other sensor is unaffected.
imx896.yaml gains the locus from the stock tuning blob's 10-point
per-illuminant AWB calibration (white points and their exactly
reciprocal gain triplets, cross-validated): the 7 on-locus points as
nodes, the 3 fluorescent points admitted via clampMargin 0.35. The
5000 K label is the blob's own proven anchor; 2856 K (A) is locked by
the fluorescent trio projecting onto the 2856-5000 chord at ~3960 K
(TL84); the rest are geometry-derived approximations.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Raw-RDI dark frames (phone face-down, minimum analogue gain) put the
pedestal at exactly 64 in 10-bit (mean 63.98, median 64, p1/p99 63/65)
= 4096 on the 16-bit scale. The softISP's dynamic estimate ran at 48;
the 16-code residual was amplified by the CCM into colour casts in
dark image regions.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Adds imx896.yaml (CCMs for 2800/4000/5750 K) so the main camera gets
real colour instead of the uncalibrated fallback. The matrices are
numeric calibration data read out of the stock Android tuning blob -
measured spectral response of this sensor, not authored expression -
and are shipped by the project owner's decision, consistent with the
vendor-derived data this image already carries. Durable replacement is
to measure our own from a colour chart.
Note the file lists Adjust/Agc/Af as well as BlackLevel/Awb/Ccm: a
sensor-specific tuning file REPLACES the fallback's algorithm list, so
omitting them silently disables auto-exposure and autofocus.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Hardware finding from the first r4 run on the phone: the focus-loss
detector compared the settled scene against the maximum sharpness
recorded during the sweep, which was measured under a different AGC
state. On the FP6 that maximum read 4848088 and the same position two
stats frames later read 1995445, so the detector fired immediately and
the lens swept forever. Patch 0014 takes the reference after the lens
settles and requires four consecutive out-of-band frames.
Verified on the phone: r4 re-swept without end, r5 completes one sweep
and stays put.
The DW9784 VCM works and libcamera discovers it through the sensor's
ancillary link, but nothing in the software ISP ever moves it. Backport
the out-of-tree autofocus work onto v0.7.2:
- 0007-0009 are Vasiliy Doylov's focus control, contrast autofocus and
focus-loss detection from the softisp-playground branch;
- 0010 is Pavel Machek's Librem5-tested robustness work (centre-window,
brightness-normalised sharpness, two-phase sweep, settle skip),
squashed and adapted;
- 0011-0013 are ours: the lens write no longer sits inside the
no-frame-start-emitter branch, the lensless-camera paths are guarded,
and AfMode is advertised with a continuous default so that stock
applications get autofocus without sending AfTrigger.
Provenance and the adaptations made to each patch are recorded in the
patch commit messages.
Teaches the software ISP's AGC the IMX896 gain law
(gain = 16384/(16384-code), inverted from the vendor driver and
round-tripped against all 3009 vendor gain-table entries, max error
0.049%) and adds the sensor properties (1.0um unit cell, test-pattern
map). Same shape as the OV13B10 pair; both verified to apply and
compile on v0.7.2 after 0001-0004.
The extracted-CCM tuning yaml is deliberately NOT packaged yet - the
color matrices come from the vendor Chromatix blob and the licensing
call is open (see the camera journal).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Run #25 died at 'pmbootstrap checksum libqmi' on a bare HTTP 503 from
gitlab.freedesktop.org. That host serves three of this pipeline's inputs
(libqmi, modemmanager and now libcamera), and its 503s are transient - it
answered 200 again minutes later - so a hiccup there should cost a retry,
not a 2-hour run.
Same shape as clone_retry, applied to the checksum and build calls that
fetch sources. The kernel and imsd checksums need no retry: their tarballs
are generated locally by this script.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
34cfc09 added aports/temp/libcamera but never taught build.sh to copy it,
so run #24 built the image with pmOS's stock 99990.7.2-r1 and published no
libcamera package at all. Copy it like libqmi/modemmanager (upstream aport
deleted first - duplicate pkgnames are a pmbootstrap hard error) and build
it explicitly so the -r2 apk reaches the registry publish step.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Kernel config: CONFIG_VIDEO_OV13B10=m + CONFIG_VIDEO_DW9714=m — the camss
core, CAMCC and CCI were already enabled; the sensor and VCM drivers were
the only missing pieces. The camera carries themselves land via
milos-linux combined-stable (merge of the 'camera' topic branch,
nondescriptpointer's 5 patches, authorship preserved).
libcamera: new temp/ aport overriding pmOS 99990.7.2-r1 with -r2, adding
nondescriptpointer's OV13B10 sensor helper (gain = code/128, enables the
software-ISP AGC/AWB) and sensor properties patches on top of the pmOS
0.7.2 APKBUILD. Patch sha512s re-recorded from the actual files (his
APKBUILD diff carried stale hashes); all four patches verified to apply
against the v0.7.2 tarball.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Run 22 failed with 'catcrafts-fp6-repo: Could not find it in pmaports
or any APKINDEX': build.sh copies each overlay aport explicitly and
this one was never in the list, so pmbootstrap could not resolve the
new extra_packages entry.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The catcrafts-fp6-repo aport (signing key + repositories entry) existed
but nothing installed it: images shipped with the CI-built packages
baked in and no update channel, so 'apk upgrade' never delivered new
kernel/imsd builds despite CI publishing every apk to the registry.
Add it to extra_packages and document the registry in the README.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The stale-rpmh-votes GMU wedge (GMU fw init timeout under bursty GPU
use) is fixed in kernel builds from combined-stable >= 2026-08-14 by
carrying upstream 'drm/msm/a6xx: Fix stale rpmh votes after suspend'
(d9108bfdb746, drm-msm msm-next). This push also triggers the image
rebuild that picks the fix up.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
