Commit graph fp6-img/aports/device/fp6-device-tweaks/APKBUILD
Author SHA1 Message Date
bbad150335
aports: our own packages are GPL-3.0-only, as the repository is
Some checks failed
image / image (push) Has been cancelled
fp6-charging-mode, fp6-device-tweaks, fp6-vendor-blobs and catcrafts-fp6-repo
declared license="MIT"; their contents are ours and GPL-3.0-only, as LICENSE
says since c9bac2c. No pkgrel bump: the field reaches the published packages
at each package's next bump.
2026-10-16 23:08:14 +02:00
7191410852
fp6-device-tweaks 6: run ModemManager in its quick suspend/resume mode
Deep suspend on the FP6 is ended every few seconds by the modem's QMI
indications that ModemManager subscribes to: signal info on a 5 dB delta,
system info, DSD system status (16 + 3 of 25 deep cycles on 2026-10-14).
ModemManager already has the answer: started with
--test-quick-suspend-resume it sets the modem "terse" on logind's
PrepareForSleep (those subscriptions off, calls and texts still delivered)
and synchronises on resume. On the dev phone a logind-driven deep cycle
then runs to its 60 s alarm with the modem registered and imsd up, where
none of 21 did before.

Ship the flag as a drop-in. It does nothing while the sleep targets stay
masked, and is the modem side of the suspend policy when they go.
2026-10-14 18:03:13 +02:00
dabfb4f4e3
fp6-device-tweaks 5-r1: restart drop-in comment matches the no-SSC rule
The drop-in's header still presented the boot-time libssc crash as live;
the udev rule from the previous commit removes the probe that caused it.
Comment only, no behaviour change; bumped so the rebuilt package carries
it.
2026-09-25 00:04:52 +02:00
637221129b
fp6-device-tweaks 5: drop iio-sensor-proxy's SSC tags, so proximity polling starts
All checks were successful
image / image (push) Successful in 1h45m14s
iio-sensor-proxy 3.9's own rules tag fastrpc-adsp with ssc-light and
ssc-compass, and pmOS's 90- rule adds ssc-accel and ssc-proximity. On
this image nothing serves the SSC registry (no hexagonrpcd), so the
libssc compass discover() probes it for 100 s in a nested main loop,
from find_sensors() in the daemon's name-acquired handler, before the
per-type delayed-invocation arrays exist. A ClaimProximity dispatched
in that window (Plasma sends one at every daemon start) hits
g_ptr_array_add(NULL) and driver_set_polling(NULL): the client is
registered, polling never starts, every later claim is treated as
"already active", and ProximityNear stays false with HasProximity
true. A second claim in the window dereferences the NULL array in the
claim handler and the daemon crashes, which is the boot-time crash the
restart drop-in was papering over.

Clear the tags on the fastrpc devices after both rules. The daemon
then skips the probe, starts in under a second and polls on claim.
Verified on the dev phone 2026-09-24 with the near-level DTB (near
level 25, combined-stable's DTS carry): no assertions or crash at
boot, and monitor-sensor logged one "Proximity value changed: 1"/"0"
pair per hand pass. The near level itself comes from that kernel;
without it the daemon declines the sensor before any of this matters.
2026-09-24 23:09:38 +02:00
970a44f93d aports/fp6-device-tweaks: stop the modem-gnss 30 s restart loop
Some checks failed
image / image (push) Has been cancelled
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
2026-08-24 19:44:18 +02:00
30f2778fc4 audio: select the pipewire backend explicitly and ban the pulse one
Full-system audit findings: without an explicit provider selection the
image installed real PulseAudio (Plasma Mobile hard-path), which claims
the card and ships a wireplumber fragment disabling hardware.audio -
zero sinks forever. Mirror the dev phone's world: pipewire backend meta
+ pipewire-pulse + echo-cancel in extra_packages, pulse meta banned via
apk conflict in fp6-device-tweaks. The two hand-made /etc audio
fragments (wireplumber no-ACP rule, AEC pair for VoLTE speakerphone)
move into soc-fairphone-fp6-audio.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-09 00:32:11 +02:00
ff69f4d913 fp6-no-suspend -> fp6-device-tweaks: + the three IMU-critical /etc files
Full-system audit on the flashed phone found the IMU dead: the journal's
documented reinstall-loss trio (inv-icm42600-spi modules-load - fallback-only
SPI node never coldplugs; the accel poll udev rule for auto-rotate; the
iio-sensor-proxy libssc-crash restart drop-in). All device-critical, none
personal - now packaged.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-09 00:03:09 +02:00