| sicelo | i want to make a (simple) dbus 'server'. what languages are easy enough to learn and do this? i know python can do it, but hopefully something lighter than it if possible | 16:24 |
|---|---|---|
| sicelo | specifically, i want to spoof upower ... so upower clients will talk to this fake 'server.' it will/should provide all the expected interfaces/responses | 16:25 |
| sicelo | the why: on N900 that has broken USB, upower will always want to shutdown the device, because battery capacity, charge_now, and power_now are always reported as 0% (due to our bq27200) | 16:27 |
| sicelo | unfortunately getting upower (freedesktop) patches accepted can be like climbing Everest, so I'm looking for alternatives. A lot of stuff nowadays relies on upower, so it's not easy to just, for example, handle the battery via own scripts | 16:29 |
| pabs3 | upower reads kernel interfaces right? perhaps you could fake those? | 16:30 |
| pabs3 | or block upower's access to them | 16:30 |
| sicelo | kernel people don't like reporting fake info, so i wouldn't be able to upstream that either :-) | 16:33 |
| sicelo | and i actually agree with the kernel people | 16:34 |
| pabs3 | I was thinking overlayfs mounted on /sys diverting some files to /dev/null or similar :) | 16:35 |
| sicelo | mmm, i can have a look at that. never tried it before | 16:35 |
| pabs3 | not upstreamable either, but not much to maintain, just an additional command before upower runs | 16:36 |
| Wizzup | sicelo: maybe patch your upower locally? | 16:37 |
| pabs3 | hmm, I feel like the kernel does a lot of working around broken hardware, so I'm surprised they would reject supporting ways to fake info | 16:37 |
| sicelo | Wizzup: yes, that's the simplest option, but ... i want this to work on postmarketOS. not very easy to carry patched packages there too, which is somewhat understandable - you might break some other device out of the 200+ they support | 16:39 |
| sicelo | https://gitlab.com/postmarketOS/pmaports/-/merge_requests/4117#note_1407737504 | 16:39 |
| sicelo | pabs3: the thing is - somewhat usable info is available once the device is connected to a charger (and better still, calibrated). the problem only occurs when you don't have USB port on the N900 | 16:40 |
| sicelo | so i thought spoofing upower would be way easier solution - i can easily confine it to N900 (and Droid 4, where it can be useful too), and leave everything else in vanilla state (kernel, upower, etc.) | 16:45 |
| sicelo | it's somewhat easy to do in python - in fact i'd have close to no work at all, since python-dbusmock already has the code/functions specific to upower | 16:47 |
| joerg | aiui there's no way to upstream patches for broken hardware that would beak the system for everybody who doesn't have that particular hardware defect in their device | 19:14 |
| joerg | ask pali | 19:24 |
| joerg | he wrote the bq27xxx.ko iirc, and also iirc this module falls back to some more primitive and generic (LUT for bat voltage -> bat state of charge?) method to find out what's battery status, when the BQ27200 reports CI=1 (callibration incorrect) | 19:27 |
| * joerg wonders what you get from upower when you unload (modprobe -r ?) the bq27200.ko completely | 19:30 | |
| joerg | I might be wrong and the module been completely different name. Sorry, I don't have the module handling battery here, this system still running genuine (braindead) BME | 19:45 |
| joerg | I'm pretty sure I suggested (requested) module parameters to adjust battery-design-capacity, end-of-discharge-voltage etc, sinc4e people were using all sorts of frankenstein battery contraptions, like 3* AA MiMH or the like | 19:48 |
| joerg | NiMH even | 19:49 |
| joerg | https://mg.pov.lt/maemo-ssu-irclog/%23maemo-ssu.2014-12-13.log.html#t2014-12-13T16:25:19 ... https://mg.pov.lt/maemo-ssu-irclog/%23maemo-ssu.2014-12-13.log.html#t2014-12-13T17:23:15 | 20:59 |
| joerg | bq27x00_battery is the module name | 21:00 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!