~mil/sxmo-tickets#594: 
Enhancement: Consider using iio-sensor-proxy for rotation and proximity monitoring

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

Status
RESOLVED IMPLEMENTED
Submitter
Sicelo
Assigned to
No-one
Submitted
1 year, 1 month ago
Updated
3 months ago
Labels
No labels applied.

~earboxer 1 year, 1 month ago

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

~sicelo 9 months ago

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:

  1. the 'normal' iio subsystem way
  2. the ssccli way, specific to SDM845
  3. 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 :-)

~sicelo 9 months ago*

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 of plugdev

~proycon REPORTED IMPLEMENTED 3 months ago

Register here or Log in to comment, or comment via email.