Changes since v1:
- source directly instead of using "command -v" as much as possible,
I couldn't get the sources in deviceprofile cases to return a proper
exit code so they still use "command -v".
- avoid leaving deviceprofile var set in interactive shells from
sxmo_init.sh
- small fixup to warning message if deviceprofile not found
This allows Sxmo to drop an external dependency on which.
Anjan's note: This is also faster due to being a shell built-in
Signed-off-by: Jami Kettunen <jami.kettunen@protonmail.com>
Signed-off-by: Anjandev Momi <anjan@momi.ca>
The wait command will wait for all process known to the shell if no
arguments are passed, so in these cases looping does nothing.
Signed-off-by: Stacy Harper <contact@stacyharper.net>
It offer a "mutex" way to manage the is_idle and can_suspend status:
$ MUTEX_NAME=can_suspend sxmo_mutex.sh lock "Dont want to…"
$ MUTEX_NAME=can_suspend sxmo_mutex.sh list
SSH is connected
MPD is playing music
Playing with leds
Dont want to…
$ MUTEX_NAME=can_suspend sxmo_mutex.sh free "Dont want to…"
$ MUTEX_NAME=can_suspend sxmo_mutex.sh list
SSH is connected
MPD is playing music
Playing with leds
I removed "can_suspend" and "is_idle" hooks to make one unique
"check_state_mutexes" one. This is triggered lazyly by the
idle_locker daemon.
We will tend to use "lock" and "free" action inside some scripts (check
sxmo_leds.sh and sxmo_proximitylock.sh) but for retro-compatibility and
for things like ssh session, we keep this script to periodically check
some conditions.
$ MUTEX_NAME=can_suspend sxmo_mutex.sh hold
Will check if no reason are present of wait until it happen.
$ MUTEX_NAME=can_suspend sxmo_mutex.sh holdexec echo foo
Will check if no reason are present of wait until it happen to exec the
command.
- Use one single sxmo_led.sh script
$ sxmo_led.sh blink red
$ sxmo_led.sh blink red blue
$ sxmo_led.sh set red 100
$ sxmo_led.sh set red 100 blue 0 green 100
This script got a simple mutex check to behave consistently while
spamed.
Blinking leds now return to initial state. Make it more easy to use
with long running leds. Plus it also solve the issue of invisible
blinking led if the color already is used.
- Free leds of sxmo lock state
The goal here is to not rely on long running leds for screen lock state.
The typical use case is when the user want to lock the screen while
playing a video. Having a blue led in the eyes really is annoying in
this kind of cases.
Another issue is when the phone is in crust, then the mixup of green
+ red give a not simple yellow. Or when we make a color to blink above
already used leds.
As sxmo now rely on an idle daemon that slowly move it to crust, having
long running leds isnt that mandatory now.
It will also make it more easy for other script to notice the user. By
example, we dont have that much merged leds now.
To avoid this, we would rely more on blinkind leds:
Move to unlock: blinking yellow
Move to lock: blinking blue
Move to off: blinking purple (blink periodically purple while in off)
Move to crust: blinking red
Additionnaly, I added a icon in the status bar to make it more
explicit if the phone stay locked for a while
- Drop rtcwake that conflict with blinking led and are pretty useless
Signed-off-by: Stacy Harper <contact@stacyharper.net>
Signed-off-by: Maarten van Gompel <proycon@anaproy.nl>
