| uvos | freemangordon: Wizzup: so sicelo correctly raises some issues whith the battery management in leste, it is not ideal that mce and the battery applet duplicate so mutch code and the code is quite defficant in various non-standart setups | 18:37 |
|---|---|---|
| uvos | mostly i think the way to solve this is to improve the code in the applet, and compleatly remove all the battery handling code in mce | 18:39 |
| uvos | mce currently dose two things with the battery state: it enables and disables various patterns and, in a module i added, dose low voltage shutdown. | 18:40 |
| uvos | the upower module in mce provides other internal interfaces on mces datapipes, but none of these go anywhere | 18:40 |
| Wizzup | I think the dbus interface is also used by other programs is it not | 18:41 |
| uvos | no | 18:41 |
| uvos | it provides no external dbus interface whatsever | 18:41 |
| uvos | only internal interfaces are provided | 18:41 |
| uvos | the handling of the enableing and disabeling is imo a ui thing, mce also dosent look at the modests email store to enable the email pattern | 18:41 |
| uvos | etc | 18:41 |
| uvos | so this imo should go into status menu item | 18:42 |
| uvos | the low voltage shutdown is a bit more tricky | 18:42 |
| uvos | its there to avoid the unbootable mapphone problem | 18:43 |
| uvos | its there to avoid the unbootable mapphone problem | 18:43 |
| uvos | but really mce is the wrong place to do this, for one mce cant even prevent this state in all cases, since it cant monitor the voltage during boot or shutdown | 18:43 |
| sicelo | the battery stuff was all in mce, at least under Fremantle. however, i'm not necessarily insisting on sticking to the past | 18:44 |
| uvos | no | 18:44 |
| uvos | it was in battd or so | 18:44 |
| uvos | the old mce battd module did the exact same things the upower module dose | 18:44 |
| uvos | ie almost nothing | 18:44 |
| sicelo | there's no such thing in fremantle, unless i have completely forgotten it :-) | 18:44 |
| Wizzup | I think it makes more sense to make the decisions in mce than in the status applets | 18:44 |
| uvos | for the notification light? | 18:45 |
| uvos | imo this is ui no? | 18:45 |
| sicelo | we used to need to kill mce to do stuff like, for example, hotswapping the battery, or doing i2c stuff directly on the fuel gauge | 18:45 |
| uvos | regardless modern mce and the battd module we replaced dose almost nothing | 18:45 |
| sicelo | even SFOS' mce is still doing battery stuff, most of it | 18:45 |
| uvos | no | 18:46 |
| sicelo | ? | 18:46 |
| uvos | we pulled the sfos upower module | 18:46 |
| uvos | thats the modern mce upower moudle | 18:46 |
| uvos | its the same | 18:46 |
| uvos | ok maybe they have some other module that also deals with the battery | 18:46 |
| uvos | any how | 18:46 |
| uvos | right now leste mce dose nothing with the battery except the notification light and my hack | 18:46 |
| sicelo | status menu item seems a weird place to do shutdowns and LED management | 18:47 |
| uvos | shutdowns i agree | 18:47 |
| sicelo | anyway i'm open to anything :-) | 18:47 |
| uvos | the led i dissagree | 18:47 |
| uvos | the led is just a extension of the gui really | 18:47 |
| uvos | so it should be left to the gui | 18:48 |
| uvos | ofc mce deals with the hal to make the led blink | 18:48 |
| uvos | all other patterns besides the device-on and shutdown patterns are also handelded by various gui programs | 18:48 |
| uvos | https://github.com/maemo-leste/mce/blob/bb33009c12236580074472c1b7f9967707467403/modules/battery.c | 18:50 |
| uvos | here is the old mce battery module btw | 18:50 |
| uvos | you will note it also dosent do anything besides the notification light | 18:50 |
| uvos | all the reall stuff is handled in "BME" which is where mce is getting its info from here | 18:51 |
| sicelo | ah right, I'm confusing bme with mce now :-D | 18:53 |
| sicelo | upower is our 'bme' now | 18:54 |
| uvos | yes - point is that the mce upower code is mostly pointless | 18:55 |
| sicelo | for the mapphone shutdown problem, ideally we need upower to be more configurable than it is. unfortunately changing upower is not really (i mean upstream), so doing these things there means you'll forever carry a fork | 18:57 |
| sicelo | for N900, which has same problem if not calibrated, i came up with a kernel hack, and I've been toying with the idea of bringing it over to Leste | 19:01 |
| sicelo | https://gitlab.com/postmarketOS/pmaports/-/commit/4b54fc7f83f9e08e2a80bbeb6a97f871748bf7c6 | 19:01 |
| uvos | mapphones have a low voltage shutdown in kernel | 19:01 |
| uvos | its just too low | 19:01 |
| sicelo | yes, i have seen it | 19:01 |
| uvos | makeing configurable via sysfs would not be so hard | 19:01 |
| uvos | no idea how popular that would be upstream tho | 19:02 |
| sicelo | yes, was about to suggest that, as a cmdline option | 19:02 |
| sicelo | i think carrying such a patch is easier/better than forks of userspace stuff. for some reason, it seems userspace is less forgiving | 19:03 |
| uvos | any idea how phosh/plamo handle low voltage shutdown? | 19:03 |
| sicelo | they don't | 19:04 |
| sicelo | upower takes care of that directly | 19:04 |
| uvos | ok so they have the same issues | 19:04 |
| sicelo | what issues? | 19:05 |
| uvos | devices with unrealiable battery reporting hw/ devices with special needs for whatever reason haveing problems with unconfigurable upower | 19:06 |
| sicelo | the interesting thing is ... most devices are well-behaved as far as upower is concerned | 19:06 |
| sicelo | i think the newer fuel gauges are smarter ... e.g. they can do their own capacity estimation | 19:07 |
| sicelo | so for those distros, using upower is absolutely seamless, same as on a regular laptop | 19:07 |
| uvos | hmm ok | 19:08 |
| uvos | cant say that upower works very well on my laptop | 19:08 |
| uvos | but i digress | 19:08 |
| sicelo | so you're saying status_battery should monitor battery. when reaching low state, status_battery requests mce to show appropriate led pattern? | 19:09 |
| sicelo | makes sense to me | 19:10 |
| uvos | yes | 19:10 |
| uvos | and low voltage shutdown needs to go somewhere | 19:10 |
| uvos | not sure where | 19:10 |
| sicelo | upower :-) | 19:10 |
| sicelo | anyway, at first it was sounding like you meant the status item should handle the LED itself. maybe Wizzup and fmg can agree with the updated understanding | 19:11 |
| * Wizzup upgrades maedevu to be a unprivd container | 19:13 | |
| sicelo | for the low voltage issue, I'd definitely vote for a kernel patch (hack?) to set the low voltage threshold on mapphones, and we'd import my pmos patch for n900. then we can use regular upstream upower and everything immediately works normally | 19:15 |
| sicelo | and mce is relieved of that duty :-) | 19:15 |
| sicelo | Wizzup: so | 19:16 |
| sicelo | downtime (maedevu)? | 19:17 |
| sicelo | btw guys ... the kernel build for linux-omap 6.1.80 keeps failing | 19:19 |
| sicelo | uvos: and please do a changelog for mce so we can get the latest code built | 19:21 |
| uvos | sicelo: i have | 19:23 |
| uvos | yeah kernel failing | 19:24 |
| uvos | have to look | 19:24 |
| sicelo | oh just seen that you have. thanks! | 19:24 |
| Wizzup | sicelo: just a few mins @ downtime | 19:27 |
| uvos | looks like omap4-droid3-xt862.dts is broken | 19:30 |
| uvos | Wizzup: dident you have rebased droid3 somewhere? | 19:30 |
| uvos | device tree that is | 19:30 |
| Wizzup | uvos: yes | 19:43 |
| Wizzup | I think I linked you to it | 19:43 |
| Wizzup | maybe check maemo-6.6-buildeb or tag maemo-kernel-6.6.2 | 19:45 |
| sicelo | uvos: out of curiosity, what issues does upower cause on your laptop | 21:17 |
| uvos | sicelo: after suspend upower fails to continue updateing battery state of charge untill reboot, causing the device to eventually hard shutdown when the battery bms cuts out, acpi -bi still works fine at all times | 21:34 |
| uvos | its probubly not upowers fault, but some bug in the device firmware or less likely kernel acpi code | 21:35 |
| sicelo | yes sounds like not directly upower's fault | 21:42 |
| sicelo | it'd be interesting to change upower's logind request for shutdown and make it invoke dsme instead :-P | 21:43 |
| sicelo | or who does shutdown in maemo btw? | 21:44 |
| uvos | depends | 21:44 |
| uvos | can be mce | 21:44 |
| uvos | usually mce i would say | 21:44 |
| sicelo | the actual shutdown? isn't it dsme ... i think that's one of the last things to die | 21:44 |
| sicelo | haven't really looked at the code though | 21:45 |
| sicelo | mmm, lel ... that's bot for logging? | 21:45 |
| uvos | yes | 21:46 |
| uvos | thats bad | 21:46 |
| uvos | Wizzup: ^^^ | 21:46 |
| Wizzup | I did this | 21:46 |
| sicelo | maybe it's the maedevu stuff | 21:47 |
| sicelo | ah, yes | 21:47 |
| uvos | sicelo: so iirc usually systemui calls mce who calls dsme who ultimatly calls the ini systems shutdown who calls reboot() syscall | 21:47 |
| uvos | sicelo: evetually migrateing everything to use logind would be better | 21:48 |
| uvos | since right now we have the issue that various shutdowns result in different behavior, some skip the emergency call check etc | 21:48 |
| uvos | with logind if and when we do switch to systemd we can have things like emergency call hold a systemd shutdown inhibit | 21:49 |
| Wizzup | lel: welcome back | 21:49 |
| uvos | which will prevent shutdown by all means incl "shutdown" in xterm | 21:49 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!