Our initramfs can't properly charge - it will always boot normally and therefore drain the battery if you can't take it out.
AFAIK we could figure out whether we should go into the charging mode by looking at the kernel parameters. When we should charge, we could display a battery icon shortly, then shut the display (or even the whole device?) off. I haven't really done research on this topic, please correct me!
Bonuspoints for a nice charging animation and display of current charging percent (I recommend to write something like that in C/C++ with osk-sdl's stack).
Just some thoughts on what this might be and how to implement it, I'm not an expert here just rambling based on how I think this would work from a device-agnostic perspective:
For devices with notification LEDs, you could pulse the LED to indicate that the device is in 'charging mode'.
It seems like this 'mode' would have to implement as many power management options as possible, supported by the kernel. Like setting CPU frequency to lowest supported by CPU, shutting off display, turning off radios, etc. The other bit is knowing when to break out of 'charging mode' and boot pmOS. Initramfs can just loop (with
These would be VERY device-specific. That's probably OK though, since the device package could provide a 'enable_charge_mode.sh' or something that does as much as it can to reduce power, and that gets called by initramfs if battery level is sleep) on battery level and when it is higher than some amount then it can break out and boot pmOS.
For reference: qualcomm lk adds androidboot.mode=charger to the kernel cmdline when it's supposed to go to charger mode (see lk code)
I'd be up for making the charging animation/status application if you want any help with that
Yes please, every helping hand is welcome! 馃憤
I would also do it / help when I'm done getting my panel to work on mainline as I'm sick of my 3.4 framebuffer :/
I was looking into this, i think we should do something like androids healthd (pressing power button shows percentage then shuts off display and holding it reboots to full mode)
can someone test this
#include <iostream>
#include "SDL2/SDL.h"
#include "SDL2/SDL_power.h"
int main ( int argc, char *argv[] )
{
int percent;
if (SDL_GetPowerInfo(NULL, &percent) != SDL_POWERSTATE_UNKNOWN)
std::cout << percent;
}
Quick reference for the comment from @opendata26:
Put the content into a file called main.cpp and compile with g++ main.cpp -static $(sdl2-config --cflags) $(sdl2-config --libs) -lstdc++. Output file is called a.out which can be run like a normal executable.
And on FP2 mainline kernel with pmOS ramdisk it returns -1.
Keep in mind that the solution here should not depend on an Android
kernel (or features found only in Android kernels).. since that
conflicts with the goal to move to mainline for all (or most, or as
many as possible) devices, and we already have some devices that do
not use Android kernels!
On Sun, Oct 15, 2017 at 02:11:24PM -0700, Luca Weiss wrote:
And on FP2 mainline kernel with pmOS ramdisk it returns
-1.--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/postmarketOS/pmbootstrap/issues/776#issuecomment-336741977
I guess the simplest charging implementation just disables the display, enables the notification led and sets the CPU in the lowest power mode (or deep sleep mode or something)
@MartijnBraam yea that's what I suggested above as the lowest common denominator that most devices should support. Any animations for charging would, IMHO, possibly defeat the purpose since they'll be software rendered on some devices (causing high[er] CPU utilization).
Yeah we can splash a simple program that shows that its charging (and that its running pmos) and then after a few seconds go into low power mode so it charges fast. I've had tablets that won't even charge when the screen was on so that defeats the purpose of the charging mode.
@z3ntu
On the N900, it appears that SDL_GetPowerInfo() is returning SDL_POWERSTATE_UNKNOWN
SDL2 source code on where it gets the percentage from: https://github.com/spurious/SDL-mirror/blob/bc7c1157eac35a076862a1e1f9692cad0328e801/src/power/SDL_power.c#L50-L55
Hmm the only one of that list that probably works for arm platforms is SDL_GetPowerInfo_Linux_sys_class_power_supply (which should work on a calibrated n900 at least)
Yea, we would have to use SDL_GetPowerInfo_Linux_sys_class_power_supply, since upower isn't available/running in initramfs, armhf doesn't support apm or acpi (upower too?).
on my uncalibrated n900, /sys/class/power_supply is empty.. I don't seem to recall that always being the case though.. I wonder if some module isn't loaded. Can you (@MartijnBraam or @pavelmachek ) confirm on your N900?
threw together a prototype here it is! At the moment it works kind of... meh. Also, it's the code to get the battery is written from scratch, didn't realize SDL had a thing for that. I'll revise it tomorrow but I've gotta get to be sometime soon :P
@z3ntu battery percent support isn't even implomented in mainline
Is this two problems in one? 1st (quite serious): playing dead with battery in. 2nd: getting quick charge by turning off unused stuff.
Handling battery on N900 is not easy: There are three devices to work with, and some maths is involved. Easiest option would be do it from place where python is available, as we already have required libraries in python. Add "unicsy-demo" to your image, then take a look at hardware.py.
(It also contains useful functions for controlling the RGB LED.)
@opendata26 I know, just wanted to throw that in as I had mainline running at that moment.
@IanS5 Nice start for an application. My thoughts in no particular order
/sys/class/power_supply/BAT*/ devices now which would only work in a sane ecosystem, this is the android ecosystem unfortunatly. On hammerhead its power_supply/battery/fast, found in /sys/class/power_supply/ac/charge_type in hammerhead kernel)Would probably be a good idea to keep the battery percentage path in a config file along with paths things to lower battery usage and their values
We can autodetect the values, just not by guessing device name but checking the /sys/class/power_supply/*/type file to check if it is battery.
MartijnBraam, looking into it, SDL_GetPowerInfo would work, it runs through all power methods until it finds one that works
@IanS5: Wow, that was quick!
@pavelmachek: I recommend, that we do not put python2 in the initramfs. It shouldn't be a problem to translate working python battery code to C and I'll be happy to help with that. (Here's the hardware.py he was referring to.)
just updated with a few of @MartijnBraam's suggestions. Some of the bigger ones I'm going to get to later (probably over the weekend).
@ollieparanoid do want this to be part of the postmarketOS github? or should it just stay on my account.
For the reference, SDL code is at https://hg.libsdl.org/SDL/file/ec9b9e71f51b/src/power/linux/SDL_syspower.c .
Ok, I agree python is too big for initramfs. But we should definitely not put battery handling logic into application. On linux-kernel, "libbattery" was suggested before... and I guess it is time to start it.
Ok, I started something, it is at.
https://github.com/pavelmachek/libbattery
My battery on n900 is currently uncalibrated (and charging), still it gets some kind of estimation:
Battery -1 %
Seconds -1
State 1
Voltage 3.88 V
Battery 63 %
@pavelmachek Why not just use SDL2? We already have to include SDL2 in the initramfs for osk-sdl
SDL will not work on complex hardware (such as N900), and does not provide advanced features (battery temperature, estimate charge from voltage, for example).
@IanS5 wrote:
@ollieparanoid do want this to be part of the postmarketOS github?
Yes! I have imported your repo and given you and @pavelmachek write access. If someone else needs write access just tell me, remember that you can use pull-requests, so not everyone needs to have the write access responsibility.
@pavelmachek: Sorry, he was first, so I went with this repo. You have both provided code for different code areas anyway (@IanS5 did GUI work, you did code that interacts with the N900 hardware as I understood), so I recommend that you two work out a folder structure and merge the code, either in the chat or in a new issue.
Let me know if you're stuck somewhere, I'd be happy to help! Both your efforts already look promising, I would not have though that this issue would get so much feedback o/
New location (remember to click "watch" to get notifications if you're interested):
https://github.com/postmarketOS/charging-sdl
So... I'm closing this issue, so we can this repo's bug tracker and open up multiple issues.
Most helpful comment
@IanS5 Nice start for an application. My thoughts in no particular order
/sys/class/power_supply/BAT*/devices now which would only work in a sane ecosystem, this is the android ecosystem unfortunatly. On hammerhead itspower_supply/battery/fast, found in/sys/class/power_supply/ac/charge_typein hammerhead kernel)