| Filename | Latest commit message | Latest commit date |
|---|---|---|
Jorijn van der Graaf
637221129b
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. |
||
| .. | ||
| callaudioshim | ||
| catcrafts-fp6-repo | ||
| fp6-charging-mode | ||
| fp6-device-tweaks | ||
| fp6-login-screen-schema | ||
| fp6-vendor-blobs | ||
| linux-postmarketos-qcom-milos | ||
| soc-fairphone-fp6-audio | ||