Open torwag opened 3 years ago
Currently oxide doesn't have an auto power off feature, so I think you are talking about auto suspend.
I like the rest of the idea though. Likely will add it as part of the auto power off code, since rtcwake will be required for both.
Since this has just happened to me again, I wondered: would it be possible to permit a running Xochitl to shutdown/auto-suspend?
Since this has just happened to me again, I wondered: would it be possible to permit a running Xochitl to shutdown/auto-suspend?
If you are using the chroot feature, it should already handle suspends: https://github.com/Eeems-Org/oxide/blob/master/applications/system-service/application.cpp#L477-L488
That said, oxide already has an automatic suspend, so I dont' recommend mixing it with the xochtil one. The oxide one works no matter what application is active. The xochitl one only works if you have xochitl as the active application.
@Eeems thanks for the quick response. It's more about the auto-shutdown after 12h and displaying the correct status on the screen if that happens. If I understood it correctly: as soon as oxide suspends, xochitl is also suspended and can therefore not issue any sleep or shutdown signals? Also, why does it only work in chroot mode? I would have expected it to be the other way round.
@Eeems thanks for the quick response. It's more about the auto-shutdown after 12h and displaying the correct status on the screen if that happens. If I understood it correctly: as soon as oxide suspends, xochitl is also suspended and can therefore not issue any sleep or shutdown signals?
Correct, as soon as the device suspends, xochitl is stopped and no longer running. Also, since oxide is handling the suspend it doesn't setup the normal wake to power off that xochitl does.
Also, why does it only work in chroot mode? I would have expected it to be the other way round.
Handling of xochitls suspend is the only thing that works in chroot mode due to how xochitl isn't using systemd to suspend and is instead using the direct sysfs interface.
I guess the title says it all. Right now, with autosuspend off, the battery will be completely drained. The rM seems to have a safety feature during charging, which avoids turning on the rM below a certain battery level (pretty much known from Android devices too). However, the rM does not indicate charging or activity during that stage. That means people fear they have a broken or bricked device, esp. as the device powers off and the last image (possible oxide) remains on the eink-screen. I am not sure if it powers of controlled or simply power off mid-running due to power loose.
How to fix this right now: After about 5-10min charging, one can turn on the rM again.
What to do: A watchdog should control the battery level and if it drops below a certain threshold being operated on battery: a) the rM should be shutdown in an "ordered way" (saving, housekeeping, shutdown) and power off. b) this "ordered way" should contain a power-off screen to notify the user that no reactions can be expected and that the device need to be charged first c) The watchdog could send warnings starting from a slightly higher threshold (blinking battery icon, notification, etc.) to create awareness that the device need to be charged very soon.
EDIT: corrected the wording... auto poweroff -> autosuspend