KB: Phone not/barely charging from power supplies when keyboard is not full

[Phalio]

You can manually control how much current each battery gets. The kb battery has a current limit exposed in sysfs,

/sys/class/power_supply/ip5xxx-charger/constant_charge_current

By default it is 2.3 amps, which seems to be about all the usb interace can muster. If you lower it to something like 1.5amps, then you can raise the limit on the internal battery, and the current will be shifted the the internal battery. If you don't feel like doing this manually I've written a daemon that manages the interaction between the main battery and the kbd battery, available here https://github.com/estokes/pinephone-kbpwrd

Thank you so much, it works!!! Now I can get the phone battery to charge even at high usage with the phone drawing around 1.55A, setting the keyboard input limit to 0.5A in that case still results in a net +0.4A making the percentage go up! Interestingly it looks like the phone current only increases by exactly half the amount the keyboard current decreases, seemingly making it less efficient. For example, decreasing the KB current by 0.8A only increases the PP current by 0.4A:

Code:

| KB limit | PP           | KB           |
|----------+--------------+--------------|
| KB off    | -0.35A       | 0A           |
| 2.3A     | 0.1A         | 2.4A         |
| 1.5A     | 0.5A  (+0.4) | 1.6A  (-0.8) |
| 0.5A     | 1.2A  (+0.7) | 0.2A  (-1.4) |

I see Megi even linked to your project on his website, I must have missed that. Or perhaps it was added after I last visited that specific page. I’ve made some tests using kbpwrd and written down observations, but I suppose I should put that in a GitHub issue. Thanks again for your reply, not knowing how to solve this had been bugging me for weeks!

---

My issue is solved and this is all I need to know to use the keyboard without issues, so I’ll mark this as solved. But there are some other related open questions I still have that would be nice to get the answers to, so I’ll leave them here just in case anyone can answer them.

1. I came to the conclusion that the PP’s current value seems to be unsigned and the kbpwrd readme confirms this, calling it a kernel bug. Does that mean that it would be possible to read the actual value and this bug just has to be fixed? If so, is it likely to be fixed, has it always been there and is it known what exactly is causing it?

2. Aside from the charge current difference I described in the table above (why does that happen?), when the KB battery charges the PP, the KB’s absolute current value is always a lot greater than the PP’s, for example: KB -1.4A 3.5V, PP +0.6A 4.2V (light load, PP drawing 0.35A). Where is this difference coming from? Or rather, where is it going?

3. Is my assumption correct that, when the PP is being charged, the value of the PP’s current_now is the sum of the amount of power the PP’s parts currently draw, being the (apparently negative) current value of the PP when it’s not getting any external power, plus the amount of power it receives externally? Which would mean that to get the actual current the PP is being supplied with, one has to subtract the (negative) current value it displays when not being supplied with power? For example, with the values in question 2, to get the actual total current value the PP gets, one would have to add the 0.35A the PP displays while not charging to the 0.6A it displays while charging (without changing hardware load), making it get 0.95A in total.

4. There are two input limit values on the PP side: axp20x-usb/input_current_limit and axp20x-battery/constant_charge_current. As per Megi’s FAQ, I’ve changed the former, and kbpwrd’s code seems to also only include that one. By default, the former is set to 0.5A and the latter to 1.2A. Setting the former to greater than 1.2A as suggested (1.5A) and as done by kbpwrd, the latter limit seems to still apply, limiting it to 1.2A. Should that one also be changed? What’s the difference between the two? I guess the former could be the limit of what the pins may transfer and the latter what the PP battery takes. So the PP battery would take at most 1.2A, but the remaining power could still be supplied directly to the PP’s SoC. The PP’s current value seems to cap at around +1.2A, so I guess that would make sense. But in the example where the PP was drawing 1.55A, it displayed a value of (definitely positive) 0.4A. If my assumption from question 3 is correct, that would mean it would get a total of 1.95A from the charging cable through the pins, which is a lot higher than both limit values that were set to 1.5 and 1.2. The same appears to happen when charging from the KB battery.

5. I upgraded to kernel 5.17 from Manjaro testing one or two days after its release, getting KB capacity reporting for the first time. I believe during the first days, the percentage seemed to constantly fluctuate, it’s stable now with frequent very short deviations. But it still seems to be quite random. Plugging the cable in or out makes it change to a completely different percentage. And then plugging it in or out again to yet another value. It also doesn’t seem to increase or decrease linearly. It makes huge jumps, only going down to 50% right before it stops charging for being empty for example. But displaying a low percentage when charging in this state. It definitely doesn’t look that related to the OCV value to me. Since I have no idea how this guessing of its capacity works, I don’t know if this is to be expected and if it for example improves automatically over time, and if so if I could do something to provide optimal conditions for this process and how long it might take.

6. According to Megi’s FAQ, plugging it into a computer USB port is a bad idea. Is that simply because it would supply so little power that it would be useless, or would it actually be bad, like taking more power than it should instead of merely taking the default minimum? My experience with the non-PD 5V 3A supplies might suggest the latter.