Jump to content

Sxmo/Oneplus 6: Difference between revisions

From postmarketOS Wiki
m Wake From Suspend: fix link to MR
 
(29 intermediate revisions by 8 users not shown)
Line 1: Line 1:
{{Subpages|Sxmo}}
Here are some tips and tricks to ease the use of sxmo on the Oneplus6/T
Here are some tips and tricks to ease the use of sxmo on the Oneplus6/T


== Sound issues ==
== Sound issues ==
Note pipewire works very well on edge. Calls to be tested.


Sxmo images seem come with pipewire by default.
Sxmo images come with pipewire by default. There was {{issue|1534|pmaports}} with glitched audio though, in which sound volume is low and saturated (as if there were some too low gains as well as saturated ones on the sound path) or there are pops and clicks, this should be solved by {{MR|4186|pmaports}}. Further problems may be solved by https://gitlab.com/sdm845-mainline/linux/-/issues/48 .


<s>At the moment pipewire does not seem to work well (see https://gitlab.com/postmarketOS/pmaports/-/issues/1534). Sound volume is low and saturated (as if there were some too low gains as well as saturated ones on the sound path).</s> '''NOTE: [https://gitlab.com/postmarketOS/pmaports/-/merge_requests/4186 SOLVED]''' (pipewire can be kept, following is not needed).
=== Call Audio ===


To get better results it is advised to switch back to pulse (sxmo supports alsa/pulse/pipewire). You can do so by removing the constraint on pipewire and installing pulseaudio :
Still, call audio may remain a problem when on pipewire with wireplumber installed.


$ sudo apk del sxmo-common-audio-pipewire
To get better results it is advised to switch back to pulseaudio (sxmo supports both pulseaudio or pipewire). You can do so by removing the constraint on pipewire and installing pulseaudio :
$ sudo apk add sxmo-common-audio-pulse


If you use '''pmbootstrap''' to generate your image, you can add '''sxmo-common-audio-pulse''' to your extra packages, it will generate a correct image.
$ sudo apk add sxmo-utils-audio-pulseaudio
$ sudo apk del sxmo-utils-audio-pipewire
 
You may need to forcibly remove wireplumber on existing installations of postmarketos edge:
 
$ sudo apk del --force-broken-world wireplumber
$ sudo apk upgrade -a
 
If you use '''pmbootstrap''' to generate your image, you can add '''sxmo-utils-audio-pulseaudio''' to your extra packages, it should generate a correct image.


Sometimes sound stops to work in calls, it can sometimes be solved by reloading ucm files :
Sometimes sound stops to work in calls, it can sometimes be solved by reloading ucm files :
Line 27: Line 36:


Beware that it does not (intentionaly) turns on the touchscreen, you'll have to answer using the physical button.
Beware that it does not (intentionaly) turns on the touchscreen, you'll have to answer using the physical button.
You can now also use the [[Sxmo:Oneplus6#Proximity_Sensor|Proximity Sensor]].


== Lisgd ==
== Lisgd ==




Oneplus6 and Oneplus6t have round corners, and corner gestures might not work well.
Oneplus6 and Oneplus6t have round corners and a notch, therefore some gestures do not work very well.<br>
If you go to the very edge of the screen and dodge the notch they will work.
 
It is however better to fix this, by adding <code>LISGD_EDGE_SIZE="3"</code> variable in <code>~/.config/sxmo/hooks/sxmo_hook_lisgdstart.sh</code>.<br>
You need to copy it from <code>/usr/share/sxmo/default_hooks/sxmo_hook_lisgdstart.sh</code> or you can use the Hooks entry in <code>Menu->Config->Hooks</code>.


One workaround is to recompile lisgd increasing '''edgesizes''' increasing it to 100 seems to work. Here is a diff of the changes that works for me.
One workaround is to recompile lisgd increasing '''edgesizes''' increasing it to 100 seems to work. Here is a diff of the changes that works for me.
Line 55: Line 70:
  //Gestures can also be specified interactively from the command line using -g
  //Gestures can also be specified interactively from the command line using -g
</pre>
</pre>
 
(and the <code>-s</code> argument of <code>lisgd</code>).
There is now a <code>$LISGD_EDGE_SIZE</code> variable to handle this (and the <code>-s</code> argument of <code>lisgd</code>). For oneplus6 it should work well with a value of <code>2.0</code>.


== Working around the notch ==
== Working around the notch ==
Line 110: Line 124:
</nowiki>
</nowiki>


There is, however, another approach by filling in some useless items in the notch area.
'''There is, however, another approach''' by filling in some useless items in the notch area.
First make a copy the sxmo_hook_statusbar.sh
 
First:


<code>cp /usr/share/sxmo/default_hooks/sxmo_hook_statusbar.sh ~/.config/sxmo/hooks/</code>
<code>cp /usr/share/sxmo/default_hooks/sxmo_hook_statusbar.sh ~/.config/sxmo/hooks/</code>


then add a few ooooo between the battery and the wifi symbol with adding this line to the hook:


<code>sxmobar -a notch 31 ooooooooo</code>
then add a few ooooo between the battery and the wifi symbol just above the line containing
<code>sxmobar -a -f "$fgcolor" -b "$bgcolor" -t "$style" \</code>
 
with adding this line to the hook:
 
<code>sxmobar -a notch 22 oooooooooo</code>
 
Then disable tray icons in swaybar:
 
<code>
nano ~/.config/sxmo/sway
</code>


reboot and enjoy.
Scroll down to the
<code>Status Bar:</code>
section and just below <code>position top</code>
add
<code>
tray_output none
</code>
 
 
Then reboot and enjoy.


== The tristate button ==
== The tristate button ==
Line 160: Line 194:
Event: time 1690117162.771358, type 3 (EV_ABS), code 34 (?), value 2
Event: time 1690117162.771358, type 3 (EV_ABS), code 34 (?), value 2
</nowiki>
</nowiki>
=== From 3.4 kernel ===


The button reports as '''EV_ABS''' number 34 on '''/dev/input/event1''' and gives current value.
The button reports as '''EV_ABS''' number 34 on '''/dev/input/event1''' and gives current value.
Line 187: Line 219:
}
}
</nowiki>
</nowiki>
Save it as testsw.c and then compile with <code>gcc testsw.c -o testsw</code>


You can then use it directly in you bash scripts, for instance to test for the middle position :
You can then use it directly in you bash scripts, for instance to test for the middle position :
Line 194: Line 227:
</nowiki>
</nowiki>


=== Before kernel 3.4 ===
=== Using tristate to prevent locking ===


Events associated with tristate were handled differently before kernel 3.4. It was reported as an '''EV_SW'''.
Once you have the '''testsw''' binary, you can query tristate button state before doing an action.  


So if you type '''evtest /dev/input/event2''' you can follow the state of your button (note: on my installation the top position (17) does not work, but it doesn't matter because middle and bottom position work and you can infer top from them). Here is what should happen when launching '''evtest''' and playing with the switch.
If you want to prevent locking when tristate is up ('''testsw returns 0'''), modify the '''suspend_disabled''' function from '''sxmo_hook_block_suspend.sh'''


  <nowiki>
  <pre>
$ evtest /dev/input/event2
suspend_disabled() {
Input driver version is 1.0.1
     test $(testsw) -eq 0 || test -e "$XDG_CACHE_HOME/sxmo/sxmo.nosuspend"
Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100
}  
Input device name: "Tri-state key"
</pre>
Supported events:
  Event type 0 (EV_SYN)
  Event type 5 (EV_SW)
     Event code 17 (?) state 1
    Event code 18 (?) state 0
    Event code 19 (?) state 1
Properties:
Testing ... (interrupt to exit)
Event: time 1686057348.435336, type 5 (EV_SW), code 18 (?), value 1
Event: time 1686057348.435336, -------------- SYN_REPORT ------------
Event: time 1686057348.439594, type 5 (EV_SW), code 19 (?), value 0
Event: time 1686057348.439594, -------------- SYN_REPORT ------------
Event: time 1686057349.312552, type 5 (EV_SW), code 19 (?), value 1
Event: time 1686057349.312552, -------------- SYN_REPORT ------------
Event: time 1686057349.348182, type 5 (EV_SW), code 18 (?), value 0
Event: time 1686057349.348182, -------------- SYN_REPORT ------------
Event: time 1686057349.788464, type 5 (EV_SW), code 18 (?), value 1
Event: time 1686057349.788464, -------------- SYN_REPORT ------------
Event: time 1686057350.658555, type 5 (EV_SW), code 18 (?), value 0
Event: time 1686057350.658555, -------------- SYN_REPORT ------------
Event: time 1686057351.145399, type 5 (EV_SW), code 18 (?), value 1
Event: time 1686057351.145399, -------------- SYN_REPORT ------------
Event: time 1686057351.159578, type 5 (EV_SW), code 19 (?), value 0
Event: time 1686057351.159578, -------------- SYN_REPORT ------------
Event: time 1686057351.974367, type 5 (EV_SW), code 19 (?), value 1
Event: time 1686057351.974367, -------------- SYN_REPORT ------------
Event: time 1686057352.121047, type 5 (EV_SW), code 18 (?), value 0
</nowiki>
 
It should be possible to use '''evetest''' to query each position
 
evtest --query /dev/input/event2 5 18
 
The return code should be non-null if the switch is on the middle position. But if you issue that command, '''evtest''' fails with a '''Key 18 out of bounds.''' error. One dirty workaround is to recompile '''evtest''' removing the offending test. you can then test your switch for each position.
 
For instance, in my installation, I use the tristate switch to control suspend. So I added a wakelock in '''sxmo_hook_wakelocks.sh'''
 
  <nowiki>
# tristate
if lowsw || midsw ; then
    sxmo_wakelock.sh lock tristate_disabled "$DEFAULT_DURATION"
else
    sxmo_wakelock.sh unlock tristate_disabled
fi       
</nowiki>


'''lowsw''' and '''midsw''' are small utility scripts in my '''~/bin'''
You can, using the same principle, prevent the phone from ringing, or do both (creating three profiles, one for each position).
 
<nowiki>
$ cat ~/bin/midsw
#!/bin/bash
myevt --query /dev/input/event2 5 18
</nowiki>


== Vibration ==
== Vibration ==
Line 273: Line 255:
== Proximity Sensor ==
== Proximity Sensor ==


Thanks to the work by Dylan Van Assche [https://gitlab.com/postmarketOS/pmaports/-/merge_requests/4050], sensor core is now supported on SDM845. So it is possible to access the data from accelerometer, magnetometer, light sensor and proximity sensor. The latter is essential during calls so lets try to benefit from this work.
Thanks to the work by Dylan Van Assche {{MR|4050|pmaports}}, sensor core is now supported on SDM845. So it is possible to access the data from accelerometer, magnetometer, light sensor and proximity sensor. The latter is essential during calls so lets try to benefit from this work.


Everything has been installed in latest base system, you'll have to add <code>iio-sensors-proxy</code>, it can access the sensors as if they were from the <code>iio</code> subsystem.
Everything has been installed in latest base system, you'll have to add <code>iio-sensors-proxy</code>, it can access the sensors as if they were from the <code>iio</code> subsystem.
<pre>
sudo apk add iio-sensor-proxy
sudo rc-service iio-sensor-proxy start
sudo rc-update add iio-sensor-proxy default
</pre>


Once installed, proxymity sensor can be installed using <code>monitor-sensor</code>. Unfortunately it can only be run as root. But you should get something like that :  
Once installed, proxymity sensor can be installed using <code>monitor-sensor</code>. Unfortunately it can only be run as root. But you should get something like that :  
Line 315: Line 303:
</pre>
</pre>


The same logic should be applicable to the accelerometer events to enable autorotation.
instead of editing the sudoers file, you can create a custom rule containing:
 
<pre>
polkit.addRule(function(action, subject) {
          if (action.id == "net.hadess.SensorProxy.claim-sensor" &&
            subject.isInGroup("plugdev")) {
              return polkit.Result.YES;
            }
        });
</pre>
and save it in:
 
<pre>
/etc/polkit-1/rules.d/01-sensorproxy.rules
</pre>
 
see [https://todo.sr.ht/~mil/sxmo-tickets/594 this ticket]
 
 
The same logic should be applicable to the accelerometer events to enable autorotation, here is an implementation[https://git.sr.ht/~fdlamotte/sxmo-personalscripts/tree/master/item/scripts/sxmo_autorotate.sh].
 
== Wake From Suspend ==
 
Oneplus6 can wake from [[Qualcomm_Snapdragon_845/850_(SDM845/SDM850)#Waking_up_for_calls_and_SMS|calls and sms]], but as explained in the wiki page it has some issues as the processor is awaken by any event from the modem and they should be filtered (there is a [https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/1265 ModemManager MR] to do exactly this).
 
On other DE this might cause issues if the screen is turned of. But on sxmo this is not the case. So it seems safe to let the modem wake the phone by issuing (as root) :
 
<pre>
# echo enabled > /sys/bus/rpmsg/devices/4080000.remoteproc:glink-edge.IPCRTR.-1.-1/power/wakeup
</pre>
 
As we want this to be enabled at startup you can write a script in <code>/etc/local.d</code>. Mine is called <code>50-enable-wake-from-suspend.start</code> and contains :
 
<pre>
#!/bin/sh
echo enabled > /sys/bus/rpmsg/devices/4080000.remoteproc:glink-edge.IPCRTR.-1.-1/power/wakeup
</pre>
 
I've been using this past week and it has worked well ... The phone wakes (from the log) but not the screen !
 
== Leds ==
 
Oneplus6 has a notification led. It is accessible from <code>/sys/class/leds</code> where you'll find three nodes :
 
<pre>
$ ls
rgb:status  white:flash  yellow:flash
</pre>
 
White led works just fine if you enable the torch:
 
<pre>
echo 255 > /sys/class/leds/white:flash/brightness 
</pre>
 
But the notification led <code>rgb</code> works differently as it comes as one node with two controls : <code>multi_intensity</code> and <code>brightness</code>.
To get a blue led, you'll have to write :
 
<pre>
echo 255 0 0 > /sys/class/leds/rgb:status/multi_intensity
 
echo 511 >  /sys/class/leds/rgb:status/brightnessbrightness
</pre>
 
Here is a modified version of <code>sxmo_led.sh</code>[https://git.sr.ht/~fdlamotte/sxmo-personalscripts/tree/master/item/scripts/sxmo_led.sh] that uses the logic found on #op6.
 
You'll have to give the <code>input</code> user access to the leds control, this can be done with an udev script placed in:
 
<pre>
/etc/udev/rules.d/99-custom-led-permissions.rules
</pre>
 
<pre>
SUBSYSTEM=="leds", ACTION=="add", RUN+="/bin/chgrp -R input /sys%p", RUN+="/bin/chmod -R g=u /sys%p"
SUBSYSTEM=="leds", ACTION=="change", ENV{TRIGGER}!="none", RUN+="/bin/chgrp -R input /sys%p", RUN+="/bin/chmod -R g=u /sys%p"
</pre>

Latest revision as of 10:22, 13 February 2025

< Sxmo

Here are some tips and tricks to ease the use of sxmo on the Oneplus6/T

Sound issues

Note pipewire works very well on edge. Calls to be tested.

Sxmo images come with pipewire by default. There was pmaports#1534 with glitched audio though, in which sound volume is low and saturated (as if there were some too low gains as well as saturated ones on the sound path) or there are pops and clicks, this should be solved by pmaports!4186. Further problems may be solved by https://gitlab.com/sdm845-mainline/linux/-/issues/48 .

Call Audio

Still, call audio may remain a problem when on pipewire with wireplumber installed.

To get better results it is advised to switch back to pulseaudio (sxmo supports both pulseaudio or pipewire). You can do so by removing the constraint on pipewire and installing pulseaudio :

$ sudo apk add sxmo-utils-audio-pulseaudio
$ sudo apk del sxmo-utils-audio-pipewire

You may need to forcibly remove wireplumber on existing installations of postmarketos edge:

$ sudo apk del --force-broken-world wireplumber
$ sudo apk upgrade -a

If you use pmbootstrap to generate your image, you can add sxmo-utils-audio-pulseaudio to your extra packages, it should generate a correct image.

Sometimes sound stops to work in calls, it can sometimes be solved by reloading ucm files :

$ sudo alsaucm reload

Calls

Once sound problems are solved you should be able to make calls.

But as there is no proximity sensor (yet), when receiving calls, the screen stays black.

A workaround is to add sxmo_wm.sh dpms off to sxmo_hook_ring.sh .

Beware that it does not (intentionaly) turns on the touchscreen, you'll have to answer using the physical button.

You can now also use the Proximity Sensor.

Lisgd

Oneplus6 and Oneplus6t have round corners and a notch, therefore some gestures do not work very well.
If you go to the very edge of the screen and dodge the notch they will work.

It is however better to fix this, by adding LISGD_EDGE_SIZE="3" variable in ~/.config/sxmo/hooks/sxmo_hook_lisgdstart.sh.
You need to copy it from /usr/share/sxmo/default_hooks/sxmo_hook_lisgdstart.sh or you can use the Hooks entry in Menu->Config->Hooks.

One workaround is to recompile lisgd increasing edgesizes increasing it to 100 seems to work. Here is a diff of the changes that works for me.

diff --git a/config.def.h b/config.def.h
index d07f50d..feb6003 100644
--- a/config.def.h
+++ b/config.def.h
@@ -16,10 +16,10 @@ unsigned int degreesleniency = 15;
 unsigned int timeoutms = 800;
 unsigned int orientation = 0;
 unsigned int verbose = 0;
-double edgesizeleft = 50.0;
-double edgesizetop = 50.0;
-double edgesizeright = 50.0;
-double edgesizebottom = 50.0;
+double edgesizeleft = 100.0;
+double edgesizetop = 100.0;
+double edgesizeright = 100.0;
+double edgesizebottom = 100.0;
 char *device = "/dev/input/touchscreen";
 
 //Gestures can also be specified interactively from the command line using -g

(and the -s argument of lisgd).

Working around the notch

This can be done playing with gaps. On my OP6T, using SXMO_SWAY_SCALE=1 (my personal preference), the bar can be defined this way in .config/sxmo/sway

bar {
    position top
    gaps 30 30 0 40
    height 46
     
    # When the status_command prints a new line to stdout, swaybar updates.
    # The default just shows the current date and time.
    status_command sxmo_status_watch.sh -o pango
    swaybar_command /home/florent/bin/swaybar
     
     
    pango_markup enabled
     
    colors {
        statusline #ffffff
        background #00000000
        inactive_workspace #32323200 #32323200 #5c5c5c
        font "sxmo" 22
    }                                                                                                                          
}  

Then, to update the bars when rotating the screen you can use sxmo_rotate_hook.sh

case $1 in
normal)
    swaymsg bar bar-0 gaps 30 30 0 40
    swaymsg bar bar-0 height 46
    swaymsg gaps left all set 0
    swaymsg gaps right all set 0
    ;;
left)
    swaymsg bar bar-0 gaps 0 80 0 80
    swaymsg bar bar-0 height 40
    swaymsg gaps left all set 0
    swaymsg gaps right all set 80
    ;;
right)
    swaymsg bar bar-0 gaps 0 80 0 80
    swaymsg bar bar-0 height 40
    swaymsg gaps left all set 80
    swaymsg gaps right all set 0
    ;;
esac

There is, however, another approach by filling in some useless items in the notch area.

First:

cp /usr/share/sxmo/default_hooks/sxmo_hook_statusbar.sh ~/.config/sxmo/hooks/


then add a few ooooo between the battery and the wifi symbol just above the line containing sxmobar -a -f "$fgcolor" -b "$bgcolor" -t "$style" \

with adding this line to the hook:

sxmobar -a notch 22 oooooooooo

Then disable tray icons in swaybar:

nano ~/.config/sxmo/sway

Scroll down to the Status Bar: section and just below position top add tray_output none


Then reboot and enjoy.

The tristate button

Tristate button support has been included in the kernel and can be queried with evtest.

Here is what you can expect.

$ evtest 
No device specified, trying to scan all of /dev/input/event*
Not running as root, no devices may be available.
Available devices:
/dev/input/event0:	pm8941_pwrkey
/dev/input/event1:	Alert slider
/dev/input/event2:	Hall effect sensor
/dev/input/event3:	Volume keys
/dev/input/event4:	Synaptics S3706B
/dev/input/event5:	spmi_haptics
/dev/input/event6:	OnePlus 6T Headset Jack
Select the device event number [0-6]: 1
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100
Input device name: "Alert slider"
Supported events:
  Event type 0 (EV_SYN)
  Event type 3 (EV_ABS)
    Event code 34 (?)
      Value      2
      Min        0
      Max        0
Properties:
Testing ... (interrupt to exit)
Event: time 1690117156.021495, type 3 (EV_ABS), code 34 (?), value 1
Event: time 1690117156.021495, -------------- SYN_REPORT ------------
Event: time 1690117159.236794, type 3 (EV_ABS), code 34 (?), value 0
Event: time 1690117159.236794, -------------- SYN_REPORT ------------
Event: time 1690117161.762579, type 3 (EV_ABS), code 34 (?), value 1
Event: time 1690117161.762579, -------------- SYN_REPORT ------------
Event: time 1690117162.771358, type 3 (EV_ABS), code 34 (?), value 2

The button reports as EV_ABS number 34 on /dev/input/event1 and gives current value.

Here is a little C code to query the value :

#include <stdio.h>
#include <linux/input.h>
#include <fcntl.h>
    
int main (int argc, char **argv)                                                               
{   
    int fd;
    int abs[6] = {0};
    
    if ((fd = open("/dev/input/event1", O_RDONLY)) < 0) {
        perror("evtest");
    }  
    
    ioctl(fd, EVIOCGABS(34), abs);
    printf("%d\n", abs[0]);
    
    return abs[0];
}

Save it as testsw.c and then compile with gcc testsw.c -o testsw

You can then use it directly in you bash scripts, for instance to test for the middle position :

$ test $(testsw) -eq 1 && echo middle

Using tristate to prevent locking

Once you have the testsw binary, you can query tristate button state before doing an action.

If you want to prevent locking when tristate is up (testsw returns 0), modify the suspend_disabled function from sxmo_hook_block_suspend.sh

suspend_disabled() {
    test $(testsw) -eq 0 || test -e "$XDG_CACHE_HOME/sxmo/sxmo.nosuspend"
}  

You can, using the same principle, prevent the phone from ringing, or do both (creating three profiles, one for each position).

Vibration

You need to modify the hooks for vibraton to work. In fact default hooks does not set the second argument of sxmo_vibrate. To perceive something it needs to be set at least to 1000, 20000 is ok.

So to vibrate during 1s you should use :

$ sxmo_vibrate 10000 20000

There is now a $SXMO_VIBRATE_STRENGTH variable to tune the second argument, so this should not be an issue anymore ;)

Proximity Sensor

Thanks to the work by Dylan Van Assche pmaports!4050, sensor core is now supported on SDM845. So it is possible to access the data from accelerometer, magnetometer, light sensor and proximity sensor. The latter is essential during calls so lets try to benefit from this work.

Everything has been installed in latest base system, you'll have to add iio-sensors-proxy, it can access the sensors as if they were from the iio subsystem.

 
sudo apk add iio-sensor-proxy
sudo rc-service iio-sensor-proxy start
sudo rc-update add iio-sensor-proxy default

Once installed, proxymity sensor can be installed using monitor-sensor. Unfortunately it can only be run as root. But you should get something like that :

$ sudo monitor-sensor --proximity
    Waiting for iio-sensor-proxy to appear
+++ iio-sensor-proxy appeared
=== Has proximity sensor (near: 0)
    Proximity value changed: 1
    Proximity value changed: 0
    Proximity value changed: 1
    Proximity value changed: 0

Now, to integrate that to sxmo, you'll have to use a custom sxmo_proximitylock.sh[1], in this script, The analysis of the iio sensor device file has been replaced by the analysis of the output of monitor-sensor, if it outputs Proximity value changed: 1 that is because something is near ;). Here is the part that does the job (I'm certain it could be better, this is only a poc and I wanted to stick with the original sxmo logic) :

stdbuf -o L sudo monitor-sensor --proximity >> "$tmp" &
EVENTMONITORPID=$!
    
tail -f "$tmp" | while read -r line; do
    if echo "$line" | grep -q ".*Proximity value.*1"; then
        near
    elif echo "$line" | grep -q ".*Proximity value.*0"; then
        far
    elif echo "$line" | grep -q "=== Has proximity.*1"; then
        near
    elif echo "$line" | grep -q "=== Has proximity.*0"; then
        far
    fi
done &

Beware, as the scripts runs monitor-sensor using sudo you'll have to grant permission to use monitor-sensor with sudo without using password, it is a big caveheat but should be solved quickly. Here is the kind of line you have to write in your sudoers file :

%wheel ALL=(ALL) NOPASSWD:/usr/bin/monitor-sensor

instead of editing the sudoers file, you can create a custom rule containing:

 polkit.addRule(function(action, subject) {
          if (action.id == "net.hadess.SensorProxy.claim-sensor" &&
            subject.isInGroup("plugdev")) {
              return polkit.Result.YES;
            }
        });

and save it in:

 /etc/polkit-1/rules.d/01-sensorproxy.rules

see this ticket


The same logic should be applicable to the accelerometer events to enable autorotation, here is an implementation[2].

Wake From Suspend

Oneplus6 can wake from calls and sms, but as explained in the wiki page it has some issues as the processor is awaken by any event from the modem and they should be filtered (there is a ModemManager MR to do exactly this).

On other DE this might cause issues if the screen is turned of. But on sxmo this is not the case. So it seems safe to let the modem wake the phone by issuing (as root) :

# echo enabled > /sys/bus/rpmsg/devices/4080000.remoteproc:glink-edge.IPCRTR.-1.-1/power/wakeup

As we want this to be enabled at startup you can write a script in /etc/local.d. Mine is called 50-enable-wake-from-suspend.start and contains :

#!/bin/sh
echo enabled > /sys/bus/rpmsg/devices/4080000.remoteproc:glink-edge.IPCRTR.-1.-1/power/wakeup

I've been using this past week and it has worked well ... The phone wakes (from the log) but not the screen !

Leds

Oneplus6 has a notification led. It is accessible from /sys/class/leds where you'll find three nodes :

$ ls
rgb:status  white:flash  yellow:flash

White led works just fine if you enable the torch:

 echo 255 > /sys/class/leds/white:flash/brightness  

But the notification led rgb works differently as it comes as one node with two controls : multi_intensity and brightness. To get a blue led, you'll have to write :

echo 255 0 0 > /sys/class/leds/rgb:status/multi_intensity

echo 511 >  /sys/class/leds/rgb:status/brightnessbrightness

Here is a modified version of sxmo_led.sh[3] that uses the logic found on #op6.

You'll have to give the input user access to the leds control, this can be done with an udev script placed in:

/etc/udev/rules.d/99-custom-led-permissions.rules
SUBSYSTEM=="leds", ACTION=="add", RUN+="/bin/chgrp -R input /sys%p", RUN+="/bin/chmod -R g=u /sys%p"
SUBSYSTEM=="leds", ACTION=="change", ENV{TRIGGER}!="none", RUN+="/bin/chgrp -R input /sys%p", RUN+="/bin/chmod -R g=u /sys%p"