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
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.
This commit is contained in:
parent
8e4cc1d777
commit
637221129b
2 changed files with 24 additions and 3 deletions
12
aports/device/fp6-device-tweaks/91-fp6-no-ssc-sensors.rules
Normal file
12
aports/device/fp6-device-tweaks/91-fp6-no-ssc-sensors.rules
Normal file
|
|
@ -0,0 +1,12 @@
|
|||
# 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}=""
|
||||
Loading…
Reference in a new issue