Hi
For basic sensors (proximity and accelerometer), sxmo currently queries sysfs directly.
While this works for the majority of devices, it will not for a few 'important' devices, notably those based on SDM845 SoC (think Oneplus 6/6T), because their sensors are not exposed over the kernel's iio framework, and it does not appear that this will happen in the very near future due to the way those sensors are hooked on the SoC. However, there are already WIP patches to support them in iio-sensor-proxy [1].
Less importantly, the Nokia N900 (which also has basic support in sxmo) has a proximity sensor that is also not registered on the iio bus, but in the input framework. While writing a driver to expose it over iio would be somewhat trivial, the kernel maintainers recommend that this particular sensor really belongs in input subsystem [2]. I currently have WIP patches for supporting it in iio-sensor-proxy as well [3].
Thus, it might be worthwhile for sxmo to consider switching to iio-sensor-proxy at some point too.
[1] https://gitlab.com/dylanvanassche/iio-sensor-proxy/-/commits/ssc/ [2] https://lore.kernel.org/linux-iio/ZVevR_ajeB1jfDS9@tp440p.steeds.sam/T/#u [3] https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/merge_requests/375
Alternatively for SDM845 devices, we can use libssc's ssccli with these patches: https://codeberg.org/DylanVanAssche/libssc/pulls/22
and a cleaned up version of this change to sxmo_proximitylock.sh
https://paste.sr.ht/~earboxer/ebb08a8782e52ae54653491004eabf7bff1a6352
while that's true, it means, for example, that if Nokia N900 support is added, sxmo would needs to know about 3 different ways to talk to proximity sensor, for example:
- the 'normal' iio subsystem way
- the ssccli way, specific to SDM845
- the evdev way, specific to devices such as N900 (and Google/Asus Nexus 7)
Now wait until another device shows up, needing a 4th way!
iio-sensor-proxy already abstracts these sensors. There's a client, which I think an sxmo implementation would need to use since direct dbus calls cannot work (sensors need to be claimed before being accessed, and shell scripts cannot hold such claim because they're short-lived).
I'll write a proof-of-concept patch and will see if I can get it working
PS: the merge request https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/merge_requests/375 did get merged :-)
Update: autorotation did not work on the N900 out of the box, even though the accelerometer is exposed on kernel's iio subsystem, and has all the paths required in the autorotation script. The issue was most likely due to the 'gravity' setting, and I do not know where that can be found. With
iio-sensor-proxy
, it works at first go.Patch submitted: https://lists.sr.ht/~mil/sxmo-devel/patches/51350
NB:
1.
iio-sensor-proxy
needs to be manually added to autostart services (rc-update add iio-sensor-proxy default
)
2.
out of the box,iio-sensor-proxy
does not allow the regular user to 'claim' sensors, which is needed in order to monitor them. The following PolicyKit rule is needed:polkit.addRule(function(action, subject) { if (action.id == "net.hadess.SensorProxy.claim-sensor" && subject.isInGroup("plugdev")) { return polkit.Result.YES; } });
It should be saved as
/etc/polkit-1/rules.d/01-sensorproxy.rules
. I am not sure what group is better recommended instead ofplugdev