fp6-img/aports/device/fp6-device-tweaks/91-fp6-no-ssc-sensors.rules

# FP6: the sensors are IIO devices on APPS-owned buses, and nothing serves the
# Qualcomm sensor core (SSC) registry on this image (no hexagonrpcd). iio-sensor-
# proxy 3.9 still tags fastrpc-adsp for its libssc drivers: ssc-light/ssc-compass
# from its own 80- rule, ssc-accel/ssc-proximity from pmOS's 90- rule. The libssc
# compass discover() then probes the registry for ~100 s in a nested main loop,
# inside find_sensors(), before the daemon's per-type claim bookkeeping exists:
# a ClaimProximity dispatched in that window hits g_ptr_array_add(NULL) +
# driver_set_polling(NULL), the client stays registered and proximity polling
# never starts for anyone (HasProximity true, ProximityNear stuck false). A
# second claim in the window crashes the daemon in its claim handler. Drop the
# tags. This file must sort after 80- and 90-.
SUBSYSTEM=="misc", KERNEL=="fastrpc-*", ENV{IIO_SENSOR_PROXY_TYPE}=""
fp6-device-tweaks 5: drop iio-sensor-proxy's SSC tags, so proximity polling starts 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 21:24:20 +02:00			`# FP6: the sensors are IIO devices on APPS-owned buses, and nothing serves the`
			`# Qualcomm sensor core (SSC) registry on this image (no hexagonrpcd). iio-sensor-`
			`# proxy 3.9 still tags fastrpc-adsp for its libssc drivers: ssc-light/ssc-compass`
			`# from its own 80- rule, ssc-accel/ssc-proximity from pmOS's 90- rule. The libssc`
			`# compass discover() then probes the registry for ~100 s in a nested main loop,`
			`# inside find_sensors(), before the daemon's per-type claim bookkeeping exists:`
			`# a ClaimProximity dispatched in that window hits g_ptr_array_add(NULL) +`
			`# driver_set_polling(NULL), the client stays registered and proximity polling`
			`# never starts for anyone (HasProximity true, ProximityNear stuck false). A`
			`# second claim in the window crashes the daemon in its claim handler. Drop the`
			`# tags. This file must sort after 80- and 90-.`
			`SUBSYSTEM=="misc", KERNEL=="fastrpc-*", ENV{IIO_SENSOR_PROXY_TYPE}=""`