Sometimes, I will receive a wakeup from modem, but then modem (or
modemmanager) will crash, and the phone will go back to sleep before
things can recover. This has the phone stay away for 30s after such
a case.
Signed-off-by: Willow Barraco <contact@willowbarraco.fr>
This provides more information about why the system isn't suspending
than the icons in the status bar do, and can hopefully replace them
since they seem to cause a lot of confusion.
Signed-off-by: Willow Barraco <contact@willowbarraco.fr>
This should be enough information to read the logfile, and determine how
long certain mutexes were held for. Which is probably a useful statistic
if we're going to optimize power usage more.
Signed-off-by: Willow Barraco <contact@willowbarraco.fr>
Most devices use the three_button_touchscreen hooks, so it make sense to
make them the default if there isn't a device specific hooks directory.
Hopefully this will make it simpler for users to get devices running in
sxmo.
Signed-off-by: Willow Barraco <contact@willowbarraco.fr>
The xdg base dir spec specifies that /usr/local/share:/usr/share should
be used as the default, but not that they should always be included. We
set XDG_DATA_DIRS to this in sxmo_init.sh, so we would always duplicate
entries in /user/share without this.
Signed-off-by: Willow Barraco <contact@willowbarraco.fr>
This is a new approach to cleanup and fix issues we have with the
proximity lock. Discussed between Peter and me over irc.
We set "proximity[un]lock" in SXMO_STATE. This allow the input handler
to ignore power buttons while in this state. We then can't manually
change states anymore. It become possible to configure dedicated
hardware buttons trigger, or gesture trigger, to manage the current
call while in this state, by example.
The proximitylock also setup exclusive flock over the state lock
file (as other state switcher does). It prevent other state scripts to
trigger and to break the state consistency.
We stop the idle_locker to prevent 120s, and 8s timers to move the sxmo
state deeper.
When proximitylock stop, it execute back the initial state script,
to return to initial state.
I'm not sure if a user would ever want to just turn on proximity
lock, and it does kind of make the code ugly and complicated.
Signed-off-by: Willow Barraco <contact@willowbarraco.fr>
We already have a check in sxmo_hook_inputhandler.sh to disable gestures
in any state other than unlock.
Signed-off-by: Willow Barraco <contact@willowbarraco.fr>
This is not a logind support patch. Sxmo doesn't talk logind so using it
with sxmo is pretty much useless. You shouldn't use it.
At least, let's unbreak sxmo while being used with it.
The major problem is that sxmo XDG_RUNTIME_DIR fallback to its default
location when not present. This works for the graphical session, started
by tinydm, but this make ssh session and cronjobs to fails to grab sxmo
session.
We also have to set XDG_RUNTIME_DIR before probing sxmo to be sure to
use the same directory discovery rules.
There seems to be a race somewhere in sxmo_demons that can cause it to
spawn multiple copies of a task. This patch does the equivalent of using
sxmo_uniq_exec, but it doesn't require changing all the calls to
sxmo_daemons.
Signed-off-by: Willow Barraco <contact@willowbarraco.fr>
These were added a long time ago to remove the ear icon, but this is now
all done via sxmo_modemaudio.sh calls.
Signed-off-by: Anjandev Momi <anjan@momi.ca>
>From Modem menu, "Restart Modem Daemons" should restart the daemons.
Right now, it doesn't do anything if the daemons are already running.
But I think it should restart the modem daemons, not just start if not
already started, e.g., if I want to debug something, or restart
modemmanager forcefully.
Signed-off-by: Anjandev Momi <anjan@momi.ca>
This prevent the system to go to suspension while we upgrade it.
Signed-off-by: Willow Barraco <contact@willowbarraco.fr>
Signed-off-by: Maarten van Gompel <proycon@anaproy.nl>
After scratching my head about this hack, I've decided to (1) document
it in a comment and (2) make it run only when configured explicitly and
(3) removed the != modem check. Why was the != modem check there? We
want to do this all the time.
Signed-off-by: Willow Barraco <contact@willowbarraco.fr>
I'm very proud of this bluetooth menu. It allow us to manage our
connection with ease. But most of the time the only thing I want to do
is to connect to devices. Having this device dedicated submenu as extra
step, forward and backward, just to connect, is really annoying.
This add a simple mode to this bluetooth menu. It is enabled by default.
If you select a device with this mode on, you'll connect/disconnect
automatically without entering the device dedicated submenu. For this
workflows to be confortable, I also added paired/connected icons on the
the device entries.
Signed-off-by: Willow Barraco <contact@willowbarraco.fr>
Signed-off-by: Peter John Hartman <peterjohnhartman@gmail.com>
I was getting ghost wakeups *only* while plugged in, and isolated it to
the battery sending a wakeup which we weren't detecting.
Signed-off-by: Willow Barraco <contact@willowbarraco.fr>
This will allow the user to decide what to do when there are or are not
notifications. Default is the green led. Users already have control over other
led-behavior in sxmo_hook_lock/unlock/screenoff/postwake/presuspend.
They should also be able ot control whether, e.g., notification is green
or blinks or does nothing.
Signed-off-by: Willow Barraco <contact@willowbarraco.fr>
Turning on debug, I noticed that every 8s or so, it'd try to free
everything in sxmo_hook_check_mutexes.sh, which would call
sxmo_mutex.sh:free() which would call flock, grep, cut, xargs, sed, etc.
Importantly, this would also call sxmo_hook_statusbar.sh lockedby, which
sucks up a lot of CPU.
I decided to move the statusbar update out of mutex, and hvae only one
update for all of check mutexes.
Signed-off-by: Willow Barraco <contact@willowbarraco.fr>
Moreso because I have a lot of userscripts that send popups, but its
kind of annoying to get stale or old notifications when I resume from
suspend.
Signed-off-by: Willow Barraco <contact@willowbarraco.fr>
