Rodney_ has quit [Read error: Connection reset by peer]
uvos__ has joined #maemo-leste
<uvos__>
freemangordon: thats nice but without wider integration with the init system (makeing dsme redundant in the first place in the case of systemd) none of the actual benefits are realized by this
Rodney_ has joined #maemo-leste
Daanct12 has quit [Quit: WeeChat 4.2.1]
<freemangordon>
uvos__: we can't do that over the night
<freemangordon>
not to say we have higher-prio tasks first
<freemangordon>
also, elogind!=systemd, no?
Daanct12 has joined #maemo-leste
<freemangordon>
BTW, what is the benefit of system over dsme?
<freemangordon>
*systemd
<Wizzup>
can we not like go over this once every few weeks :D
<freemangordon>
well, we are old people, memories are aging... :)
<Wizzup>
what I mean is we're not going to use systemd in the next half year at least, so there's really no point for people to keep bringing it up
<freemangordon>
I think that even SFOS guys who use systemd are still keeping dsme
<uvos__>
i was just mentioning that we have a problem that there are various paths to shutdown, wich skip various parts
<uvos__>
i just mentiond systemd would solve this, not trying to spark a debate
<uvos__>
all the discussions about this thus far have also been about different problems that would be solved by systemd so its not repetative
<uvos__>
freemangordon: a comment on the upower situation would be more usefull
<dsc_>
"it behaves like desktop scrolling without a scrollbar" <== what does this mean? :p
<freemangordon>
uvos__: I can't understand what the issue is
<freemangordon>
seems I have missed something
<uvos>
freemangordon: upower the using code is non-trivial and beocomeing increasingly so (with the need to add support for devices with mulitple batteries, like the pinephone with keyboard or the mapphones with lapdock etc)
<uvos>
freemangordon: but its duplicated in mce and in the power status applet
<uvos>
freemangordon: the mce module dosent really do anything
<uvos>
freemangordon: its just enableing the led patterns (which i propose the status applet could do) and dose the early low voltage shutdown for mapphones (which dosent really belong in mce - but needs to be discussed)
DFP has joined #maemo-leste
<uvos>
(the module i added)
<uvos>
so the proposal was to remove the mce code to eliminate the duplication
<freemangordon>
the code that shuts-down on low battery?
<uvos>
yes so this code is a duplication of the code in upower (that also shuts down on low battery) but with the twist that we have a problem that the upower code is not sufficant in all cases
<freemangordon>
status applet cannot do, as it runs on behalf of user
<uvos>
the status applet is the wrong place anyhow
<freemangordon>
mhm
<freemangordon>
mce is the right place as it has all the info
<uvos>
but its not mces job either
<freemangordon>
I would say it is
<uvos>
upower allready dose this
<uvos>
but manly it shutsdown is to late
<freemangordon>
does it have inhibitors?
<uvos>
no which is where the disscussion came to systemd
<uvos>
systemd has system wide inhibitors that blocks all sources of shutdown
<freemangordon>
ah, so upower asks systemd to shutdown?
<uvos>
wich is mutch better
<uvos>
it asks logind
<uvos>
wich asks systemd
<freemangordon>
and dsme asks elogind/systemd as well
<uvos>
elgoind is a stub that dosent do the same things, yes
<freemangordon>
so I don't see where the issue with dsme in that scenario is
<sicelo>
so i'm the one who started this ... my question (not particularly related to mce or status) was - our code (in mce and status) picks the first battery and first charger, randomly
<uvos>
dsme isent a problem
<uvos>
its just redundant in a systemd system
<freemangordon>
then why you brought it to the table - that was my question :)
<uvos>
since systemd can do watchdogs, can do inhibit and can supervise deamons and can reboot when restarting deamons fails
<uvos>
afaik all features dsme brings
<sicelo>
so i was wondering if we should rather switch to upower's composite device, DisplayDevice. that way upower has already aggregated all the batteries
<freemangordon>
sicelo: I don;t see why not
<Wizzup>
that was super buggy before, but maybe with all the module blacklists it is not
<freemangordon>
uvos: does systemd support HW WDs?
<sicelo>
alternative, is ... if we care about there being more than one battery (some users do), then let's not pick a battery randomly, and rather find a way to present all of them
<uvos>
not sure what that is, it supports runlevels ofc
<uvos>
one of wich is active at boot
<uvos>
h
<freemangordon>
no, this is what is the boot reason
<freemangordon>
power button, alarm, reset, etc
<uvos>
i dont know, but currenly we have no way cross device way to query this so we need something else for this anyhow
<sicelo>
Wizzup: ok. maybe i can experiment with DisplayDevice again and test in VM, D4, and N900. shouldn't be an issue though, i think. but i can think of pinephone people who may want to display their additional battery ... but maybe that could go to a widget or something
<freemangordon>
uvos: yeah, anyway, nothing will happen RN, so lets not waste time discussing it
<uvos>
sure but you understand how the disscusion whent there
<freemangordon>
:nod:
<freemangordon>
sicelo: did anyone test upstream upower?
<sicelo>
not with Leste, no. but even our version has DisplayDevice, so we don't necessarily need to upgrade
<Wizzup>
sicelo: it's not an issue *now* that you have blacklisted the modules
<Wizzup>
but it definitely used to be
<inky>
folks i have this question. is leste working on some device which has shared memory between gsm and ... and the rest.
<sicelo>
ah, i completely understand :-)
<inky>
do we have some kernel patches to prevent allocator to use some memory?
<inky>
to not corrupt gsm memory?
<Wizzup>
inky: is the memory is shared, then no, there is no iommu in the phones
<Wizzup>
if
<Wizzup>
but the pinephone should have this isolated completely
<inky>
or on our devices gsm is just connected via usb?
<Wizzup>
I don't know if the droid modem has access to the ram
<Wizzup>
it can be connected over usb and also have dma
<Wizzup>
(through another way)
<inky>
so we never had such a problem. i wonder if android kernels have such problem or postmarketos.
<sicelo>
freemangordon: we do need to keep the upower fork as long as we don't have another way to deal with 'broken' fuel gauges as found in N900 and Droid 4. ideally (and upower people insist) those should be handled kernel-side, but again, kernel isn't really a place for 'hacks.' between a rock and hard place
<sicelo>
inky: what problem?
<inky>
my friends were having similar problems with their embedded system, but they have fpga, not gsm, that shares the memory. and at some point the kernel allocator uses the memory which is shared with fpga.
<inky>
so i immediately thought of the phones, and if this is solved somehow in the phones.
<sicelo>
Wizzup: so i think i'll work on switching mce and status item to DisplayDevice ... and we see how it goes. later on, if some device shows up where something doesn't work correctly, we'll see how to fix that device so it plays nice with DisplayDevice
<Wizzup>
ok, if you want to, it does take some flexibility away from our side, if there are some kernel issues we will have to resolve them before being able ot use a device
<Wizzup>
like mce might just decide to power off something based on displaydevice
<Wizzup>
are we sure this is the purpose of the displaydevice?
<Wizzup>
it sounds like this might change on the use case
<Wizzup>
i.e. if you connect some external battery some way, it might show that battery instead
Daanct12 has quit [Quit: WeeChat 4.2.1]
Daanct12 has joined #maemo-leste
<sicelo>
DisplayDevice is an aggregate of all supplies reported in /sysfs. So if two, or more batteries are available to power the system, DisplayDevice will take all of them into account
<uvos>
yeah but how is the question
<sicelo>
average, and some extra decisions in the code. e.g. if one battery is charging, DisplayDevice is charging, etc.
<uvos>
iirc on the pinephone with keyboard
<uvos>
its fine for isntance if either of the batteries is empty as long as the other has charge
ceene has quit [Ping timeout: 272 seconds]
<uvos>
on the mapphoen with lapdock its fine if the phone battery is empty but its not fine if the latpdock battery is empty regardless of the charge of the phone battery
<uvos>
can we cover this
<uvos>
that sort of thing
<Wizzup>
my inclination is a more conservative if it aint broken don't fix it, but I'm happy if you want to explore the displaydevice avenue, I am just not sure if it's meant for what we want it to be
<Wizzup>
It sounds like it's mostly meant for *displaying*
<sicelo>
uvos: the question in the case of mapphones is ... does it appear as another battery? if not, then upower/mce/etc. can't do anything about it because they simply don't know anything about the lapdock's battery. for pinephone, the keyboard's battery is added as a real battery in /sys, hence kernel/upower knows it's there
<Wizzup>
yes, we'll have to assume for the sake of the argument that it is added as battery in sysfs
<uvos>
sicelo: on android android can report the lapdock power state
<uvos>
so its exposed somehow
<uvos>
no driver on mainline atm but thats different story ofc
<sicelo>
i guess then atm there's nothing that can be done for it. if it ever has a driver, then i'd suppose it would show up in /sys. DisplayDevice wouldn't be able to ensure who goes empty first
<Wizzup>
right, but can we/mce rely on upower's judgement on when to power down due to low bat?
<Wizzup>
on upowers displaydevice judgement
<sicelo>
Wizzup: i understand. it's just i thought relying on an aggregated battery (even if not perfect) is somewhat more reliable than picking the first one that shows up, especially for pinephone. but maybe let's see it when the pinephone is more popular/active in Leste, since we don't really have other devices with multiple batteries yet (besides N900 bogus ones)
<uvos>
i gues in the lapdock case we dont need to power down when the lapdock battery is empty, android just warns you and kicks you out of lapdock mode
<uvos>
the deivce remains alive ofc
<uvos>
its just that the lapdock display dies
<Wizzup>
sicelo: well if you blacklist the other ones you get the most reliable :P
<sicelo>
haha, but in pinephone, which one is that? :-D
<Wizzup>
probably the phone battery
<Wizzup>
since it will charge itself using the keyboard one
<uvos>
yeah but then you dont know how mutch charge you have
<Wizzup>
so it will be set to 'charging' I assume
<uvos>
why not leave mce alone for now (untill i come around to removeing it entirely)
<sicelo>
ok ... but then, the problem here is also that .. how does upower decide which is battery #1?
<uvos>
and display the composit device in the applet
<sicelo>
e.g. if you boot the PP with the keyboard contraption attached...
<uvos>
sicelo: for mce pinephone we would just blacklist everything except the internal battery
<uvos>
the applet shows display device
<uvos>
and we need to move the activation of the led patterns into the applet since otherwise it will have the full pattern activated at bogus times
<uvos>
(any time the keyboard battery is not empty and thus keeping the internal one at 100%)
<sicelo>
yeah. anyway, maybe let's leave the status item alone as well for the time being. no pp people have complained yet, i think :-)
Livio has quit [Ping timeout: 272 seconds]
ceene has joined #maemo-leste
udder has quit [Quit: die in fire]
udder has joined #maemo-leste
Daanct12 has quit [Quit: WeeChat 4.2.1]
ceene has quit [Remote host closed the connection]
ceene has joined #maemo-leste
ceene has quit [Remote host closed the connection]
<sicelo>
i suppose something wasn't working fine all along, so the LEDs didn't really turn on each time. however, in recent kernels (e.g. 6.8) they now are always turned on, which seems correct according to the DTS