LjL has quit [Read error: Connection reset by peer]
LjL has joined #maemo-leste
xmn has joined #maemo-leste
xmn has quit [Ping timeout: 252 seconds]
joerg has quit [Ping timeout: 255 seconds]
joerg has joined #maemo-leste
ceene has joined #maemo-leste
joerg has quit [Read error: Connection reset by peer]
joerg has joined #maemo-leste
fab_ has joined #maemo-leste
DFP has joined #maemo-leste
antranigv_ has joined #maemo-leste
antranigv has quit [Ping timeout: 260 seconds]
antranigv_ is now known as antranigv
parazyd has quit [Quit: parazyd]
parazyd has joined #maemo-leste
akossh has joined #maemo-leste
xmn has joined #maemo-leste
DPA has quit [Changing host]
DPA has joined #maemo-leste
parazyd has quit [Ping timeout: 264 seconds]
ungeskriptet7 has joined #maemo-leste
ungeskriptet has quit [Ping timeout: 264 seconds]
ungeskriptet7 is now known as ungeskriptet
parazyd has joined #maemo-leste
ceene has quit [Ping timeout: 252 seconds]
fab_ has quit [Quit: fab_]
fab_ has joined #maemo-leste
mighty has joined #maemo-leste
mighty has quit [Client Quit]
LeePen has quit [Read error: Connection reset by peer]
LeePen has joined #maemo-leste
uvos has joined #maemo-leste
<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
<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
<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.
<uvos>
the upower module in mce provides other internal interfaces on mces datapipes, but none of these go anywhere
<Wizzup>
I think the dbus interface is also used by other programs is it not
<uvos>
no
<uvos>
it provides no external dbus interface whatsever
<uvos>
only internal interfaces are provided
<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
<uvos>
etc
<uvos>
so this imo should go into status menu item
<uvos>
the low voltage shutdown is a bit more tricky
<uvos>
its there to avoid the unbootable mapphone problem
<uvos>
its there to avoid the unbootable mapphone problem
<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
<sicelo>
the battery stuff was all in mce, at least under Fremantle. however, i'm not necessarily insisting on sticking to the past
<uvos>
no
<uvos>
it was in battd or so
<uvos>
the old mce battd module did the exact same things the upower module dose
<uvos>
ie almost nothing
<sicelo>
there's no such thing in fremantle, unless i have completely forgotten it :-)
<Wizzup>
I think it makes more sense to make the decisions in mce than in the status applets
<uvos>
for the notification light?
<uvos>
imo this is ui no?
<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
<uvos>
regardless modern mce and the battd module we replaced dose almost nothing
<sicelo>
even SFOS' mce is still doing battery stuff, most of it
<uvos>
no
<sicelo>
?
<uvos>
we pulled the sfos upower module
<uvos>
thats the modern mce upower moudle
<uvos>
its the same
<uvos>
ok maybe they have some other module that also deals with the battery
<uvos>
any how
<uvos>
right now leste mce dose nothing with the battery except the notification light and my hack
<sicelo>
status menu item seems a weird place to do shutdowns and LED management
<uvos>
shutdowns i agree
<sicelo>
anyway i'm open to anything :-)
<uvos>
the led i dissagree
<uvos>
the led is just a extension of the gui really
<uvos>
so it should be left to the gui
<uvos>
ofc mce deals with the hal to make the led blink
<uvos>
all other patterns besides the device-on and shutdown patterns are also handelded by various gui programs
<uvos>
you will note it also dosent do anything besides the notification light
<uvos>
all the reall stuff is handled in "BME" which is where mce is getting its info from here
<sicelo>
ah right, I'm confusing bme with mce now :-D
<sicelo>
upower is our 'bme' now
<uvos>
yes - point is that the mce upower code is mostly pointless
<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
<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
<uvos>
mapphones have a low voltage shutdown in kernel
<uvos>
its just too low
<sicelo>
yes, i have seen it
<uvos>
makeing configurable via sysfs would not be so hard
<uvos>
no idea how popular that would be upstream tho
<sicelo>
yes, was about to suggest that, as a cmdline option
<sicelo>
i think carrying such a patch is easier/better than forks of userspace stuff. for some reason, it seems userspace is less forgiving
<uvos>
any idea how phosh/plamo handle low voltage shutdown?
<sicelo>
they don't
<sicelo>
upower takes care of that directly
<uvos>
ok so they have the same issues
<sicelo>
what issues?
<uvos>
devices with unrealiable battery reporting hw/ devices with special needs for whatever reason haveing problems with unconfigurable upower
<sicelo>
the interesting thing is ... most devices are well-behaved as far as upower is concerned
<sicelo>
i think the newer fuel gauges are smarter ... e.g. they can do their own capacity estimation
<sicelo>
so for those distros, using upower is absolutely seamless, same as on a regular laptop
<uvos>
hmm ok
<uvos>
cant say that upower works very well on my laptop
<uvos>
but i digress
<sicelo>
so you're saying status_battery should monitor battery. when reaching low state, status_battery requests mce to show appropriate led pattern?
<sicelo>
makes sense to me
<uvos>
yes
<uvos>
and low voltage shutdown needs to go somewhere
<uvos>
not sure where
<sicelo>
upower :-)
<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
* Wizzup
upgrades maedevu to be a unprivd container
<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
<sicelo>
and mce is relieved of that duty :-)
<sicelo>
Wizzup: so
<sicelo>
downtime (maedevu)?
<sicelo>
btw guys ... the kernel build for linux-omap 6.1.80 keeps failing
<sicelo>
uvos: and please do a changelog for mce so we can get the latest code built
<uvos>
sicelo: i have
<uvos>
yeah kernel failing
<uvos>
have to look
<sicelo>
oh just seen that you have. thanks!
antranigv_ has joined #maemo-leste
antranigv has quit [Ping timeout: 260 seconds]
<Wizzup>
sicelo: just a few mins @ downtime
<uvos>
looks like omap4-droid3-xt862.dts is broken
<uvos>
Wizzup: dident you have rebased droid3 somewhere?
<uvos>
device tree that is
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
<Wizzup>
uvos: yes
<Wizzup>
I think I linked you to it
<Wizzup>
maybe check maemo-6.6-buildeb or tag maemo-kernel-6.6.2
antranigv_ has quit [Ping timeout: 255 seconds]
antranigv has joined #maemo-leste
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
Livio has joined #maemo-leste
System_Error has quit [Ping timeout: 260 seconds]
xmn has quit [Ping timeout: 256 seconds]
System_Error has joined #maemo-leste
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
System_Error has quit [Remote host closed the connection]
<sicelo>
uvos: out of curiosity, what issues does upower cause on your laptop
System_Error has joined #maemo-leste
xmn has joined #maemo-leste
Livio has quit [Ping timeout: 252 seconds]
<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
<uvos>
its probubly not upowers fault, but some bug in the device firmware or less likely kernel acpi code
<sicelo>
yes sounds like not directly upower's fault
<sicelo>
it'd be interesting to change upower's logind request for shutdown and make it invoke dsme instead :-P
<sicelo>
or who does shutdown in maemo btw?
<uvos>
depends
<uvos>
can be mce
<uvos>
usually mce i would say
<sicelo>
the actual shutdown? isn't it dsme ... i think that's one of the last things to die
lel has quit [Read error: Connection reset by peer]
<sicelo>
haven't really looked at the code though
<sicelo>
mmm, lel ... that's bot for logging?
<uvos>
yes
<uvos>
thats bad
<uvos>
Wizzup: ^^^
<Wizzup>
I did this
<sicelo>
maybe it's the maedevu stuff
<sicelo>
ah, yes
<uvos>
sicelo: so iirc usually systemui calls mce who calls dsme who ultimatly calls the ini systems shutdown who calls reboot() syscall
lel has joined #maemo-leste
<uvos>
sicelo: evetually migrateing everything to use logind would be better
<uvos>
since right now we have the issue that various shutdowns result in different behavior, some skip the emergency call check etc
<uvos>
with logind if and when we do switch to systemd we can have things like emergency call hold a systemd shutdown inhibit
<Wizzup>
lel: welcome back
<uvos>
which will prevent shutdown by all means incl "shutdown" in xterm
Livio has joined #maemo-leste
fab_ has quit [Quit: fab_]
Gary__ has joined #maemo-leste
Gary_ has quit [Ping timeout: 268 seconds]
Gary_ has joined #maemo-leste
Gary__ has quit [Ping timeout: 260 seconds]
diejuse has joined #maemo-leste
akossh has quit [Quit: Leaving.]
gnarface has quit [Quit: Leaving]
mdz has joined #maemo-leste
joerg is now known as Guest3697
Guest3697 has quit [Killed (calcium.libera.chat (Nickname regained by services))]
joerg has joined #maemo-leste
gnarface has joined #maemo-leste
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
mqlnv has joined #maemo-leste
Livio has quit [Ping timeout: 260 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
System_Error has quit [Remote host closed the connection]