dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
ceene has joined #maemo-leste
<freemangordon>
how am I supposed to calibrate the battery on d4, give that device shuts down on 3.5V?
<freemangordon>
*given
mardy has joined #maemo-leste
dev has left #maemo-leste [Disconnected: closed]
dev has joined #maemo-leste
akossh has joined #maemo-leste
<uvos__>
it shuts down at 3.35v wich is below the cal threshold
<uvos__>
"uvos__: what about "display stay lit while charging" setting?" is not implemented. it got lost when spinal replaced the old battery handling with the upower module. the upower module is without functionatliy (its interfaces are used nowhere and it dose nothing internaly besides read upower (except the battery guard module i added later that dose shutdown on low voltage))
<uvos__>
i plan to reintroduce the feature by taking the uevent code from kerecv, but have not done so
<uvos__>
also in defense fo spinal the old code dident work either beacuse it read a sysfs file.
<uvos__>
anyhow mce dosent know or do anything with charging or usb state really, the bug might be related to the banner appearing (this kicks mce via the dbus if iirc)
<uvos__>
otherwsie idk, i have never seen it bug out at all, please give steps to repo
Pali has joined #maemo-leste
alex1216 has joined #maemo-leste
Livio has joined #maemo-leste
Livio has quit [Changing host]
Livio has joined #maemo-leste
xmn has quit [Ping timeout: 260 seconds]
rafael2k has joined #maemo-leste
<rafael2k>
morning
<rafael2k>
I dont see the updated PP kernel in the repo, something happened in the build?
Twig has joined #maemo-leste
<freemangordon>
uvos__: IIRC upower module was pulled by me from nemo/mer/sailfish, but I might be wrong, it was long time ago :). Not important though.
<freemangordon>
ok, I'll capture a video next time it happens and will try to gather some dbus traces, maybe
<freemangordon>
re battery it seems there are some temporary voltage drops which lead to those shutdowns
<freemangordon>
maybe some spike filtering shall be done, dunno
<freemangordon>
now charging in android, to see what it will do
<freemangordon>
uvos__: also, do you know which module/code reads battery eeprom in android?
Pali has quit [Ping timeout: 264 seconds]
alex1216 has quit [Ping timeout: 264 seconds]
alex1216 has joined #maemo-leste
alex1216 has quit [Client Quit]
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
alex1216 has joined #maemo-leste
pere has quit [Ping timeout: 252 seconds]
pere has joined #maemo-leste
<Wizzup>
rafael2k: I didn't do it yet, sry, had other things on my mind
dev has left #maemo-leste [Disconnected: closed]
dev has joined #maemo-leste
<Wizzup>
freemangordon: the kernel also has its own force shutdown on low battery afaik
<Wizzup>
which might be more sensitive to spikes
<uvos__>
freemangordon: battd its a closed source motorola thing
<uvos__>
freemangordon: the eeprom is extremly unlikely to be usefull
<uvos__>
freemangordon: it dose not contain any callibration
<uvos__>
freemangordon: as it is read only it can not
<rafael2k>
Wizzup: ?
<uvos__>
freemangordon: indeed the kernel has its own force shutdown too and its not filered at all. the battery voltage is a bit sensetive to spikes in mce too but filtering that is really upowers resposability.
<uvos__>
please also note that pulling the battery below 3.0 under load causes damage, its not the open circut volage thats relevant.
<uvos__>
a problem here is that the d4 has a massive resistance between the battery and cpcaps voltage probe, for some reason
<uvos__>
(an aditional)
ikmaak has quit [Quit: No Ping reply in 180 seconds.]
ikmaak has joined #maemo-leste
Twig has quit [Remote host closed the connection]
Twig has joined #maemo-leste
* sicelo
also just had that shutdown fmg is referring to
<freemangordon>
uvos__: well, battery voltage is measured by cpcap, so a temp spike on *that* voltage should not lead to immediate shutdown
<freemangordon>
also, this shutdown seems to happen @ < 3.2V
<freemangordon>
that would guarantee that the battery itself is well above 3.0, no?
<uvos__>
yes we dont shutdown early beacuse it would damage the battery
<freemangordon>
umm, sorry, can't parse
<uvos__>
we shoutdown early beacuse the user cant easly recover from the state wehre the device is fully discarged
<freemangordon>
ah
<uvos__>
becasue of bootloader trouble
<freemangordon>
that's fine
<uvos__>
not really
<uvos__>
but its the best we can do atm
<freemangordon>
the point is that IMO we shall not shutdown as soon as we see < 3.2
<uvos__>
yeah thats a kernel thing
<uvos__>
upower dose filter the spikes
<uvos__>
if its enough idk
<freemangordon>
mhm, we shall filter too
<freemangordon>
IIUC
<freemangordon>
in the kernel driver that is
<uvos__>
sure
<freemangordon>
shall I implement some filtering there?
<sicelo>
yessss please :-)
<uvos__>
yes sure
<uvos__>
but atm this would change nothing in leste
<sicelo>
battery issues are the main reason i don't enjoy using my the d4
<uvos__>
but still yes
<freemangordon>
it will prevent random shutdowns
<uvos__>
i dont think the kernel ever hits its shutdown
<uvos__>
atm
<uvos__>
its .3v away
<uvos__>
it certenly dosen for me
Livio has quit [Ping timeout: 264 seconds]
<freemangordon>
it does, when you stop mce :D
<uvos__>
(kernel shutdown = no white light)
<uvos__>
ok
<uvos__>
sure yeah then
<uvos__>
;)
<freemangordon>
also, to me 3.5V is too high
<uvos__>
mce is 3,35
<freemangordon>
why don;t we shutdown @ 3.25?
<uvos__>
mce is 3.35
<uvos__>
freemangordon: we shoutdown early beacuse the user cant easly recover from the state wehre the device is fully discarged
<freemangordon>
well,, I guess spikes again
<uvos__>
when are you mesureing 3,5v
<uvos__>
if thats afterwards its useless you need to measure under load
<freemangordon>
even with charge mode?
<uvos__>
yes
<uvos__>
charge mode helps only a little
<freemangordon>
ok, 3.35 then
<uvos__>
the problem is the device dieing before the kenrel finishes booting
<uvos__>
(and the android kernel and kexecboot it all just takes to long)
<freemangordon>
but, we stall shall filter better
<uvos__>
and no pm during that time either
<uvos__>
sure
<uvos__>
upower dose filter as i saied
<freemangordon>
even in mce, if needed
<uvos__>
but maybe to fast
<freemangordon>
does not seem enough
<freemangordon>
yeah
<sicelo>
no idea how possible this is - but i really don't mind 3.5v or any other voltage *IF* the shutdown is not initiated immediately, but we test over a couple of seconds to be sure the voltage has really dropped (it's not just a spike)
<uvos__>
mce cant really filter
<uvos__>
iirc
<uvos__>
becasue it gets voltage changed events
<uvos__>
not some polling rate
<freemangordon>
but, if we filter in kernel, then upower will filter the already filtered value :)
<uvos__>
no
<uvos__>
dont filter the voltage_now value
<uvos__>
that breaks spec
<uvos__>
its defined as a snapshot
<uvos__>
the kernel can filter for its shutdown thresh
<uvos__>
not uapi
<uvos__>
check if voltage_avg is a thing (current_avg) exists
<uvos__>
in uapi
<uvos__>
then filter that, as its defined to be the filtered value
<uvos__>
anyhow ttyl
* freemangordon
looks at how mce takes shutdown decisions
<Wizzup>
rafael2k: the kernel build
<freemangordon>
uvos__: yes, it can filter, just not the voltage, but the state
<freemangordon>
like, it receives 'empty' message with voltage < threshold from upower and starts timer. if after the timer expires we didn;t receive anything from upower with voltage > threshold we initiate shutdown
<freemangordon>
if voltage comes that is > threshold, then we abort "shutdown sequence"
<rafael2k>
Wizzup: lemme know if there is something wrong
<sicelo>
Wizzup: wiki down again
<freemangordon>
uvos__: re battery eeprom - at least we'll be able to understand if this is high voltage battery or not and charge properly
<freemangordon>
iven if not @ 4.35, but 4.25 or 4.3 sounds sane to me
<freemangordon>
*even
<rafael2k>
uvos__: the "speaker" button in sphone does not change the audio output to the speakers in the PP
<Wizzup>
sicelo: hm looks like the vm freezes
[TheBug] has quit [Ping timeout: 244 seconds]
<Wizzup>
sicelo: that's not great :)
<freemangordon>
DoS attack?
<Wizzup>
maybe
<Wizzup>
not likely I think
<Wizzup>
but we'll see
<Wizzup>
hm I think it froze again already
Twig has quit [Ping timeout: 265 seconds]
<Wizzup>
even the vnc session of qemu disappears
<Wizzup>
well, it hangs
<Wizzup>
well, I don't understand atm :)
<Wizzup>
I will have to debug this later today
<Wizzup>
I will keep it down for now
<uvos__>
freemangordon: this is allready implemented @hv voltage or not
<uvos__>
freemangordon: its just that we cant modprobe the one wire bus driver
<uvos__>
freemangordon: becasue it blocks idle
<uvos__>
freemangordon: also theres a small bug in the code that makes it work on only some phones, but thats small fry and i could fix it immidatly if the other issue is solved
<uvos__>
rafael2k: probubly ucm issue
<rafael2k>
uvos__: indeed. Will try to debug this a bit
Twig has joined #maemo-leste
<uvos__>
freemangordon: sure you could do that @ timeout, but thats sortof a hack vs just filtering the voltage itself so its not so noisy
[TheBug] has joined #maemo-leste
<uvos__>
i also have to note thtat i dont have the "noisy battery voltage" problem at all
<uvos__>
mine shuts down very reliably at 3.3 ish volts
<uvos__>
i gues that may be becasue my battery is new and the really old degraded batteries have greateer internal resistance
<uvos__>
thus having great magnitude spikes when the load changes
<uvos__>
in your filtering please also note that spikes upwards might also exitst
<uvos__>
when for instance the phone enters ret for a tiny period of time while otherwise loaded
<uvos__>
this may cause you to shutdown to late (again the closed circut voltage is important, not the open circut one)
<uvos__>
your timer proposal would be subject to this problem
akossh has quit [Read error: Connection reset by peer]
<freemangordon>
uvos__: sure the issue appears because of my old battery
<freemangordon>
then again - if you say filtering VOLTAGE_NOW will break the specs, I am not sure which voltage to filter
<uvos__>
freemangordon: so cpcap gives the kernel a voltage low irq
<freemangordon>
ah
<uvos__>
freemangordon: (btw we should throttle it, it comes way to often below a thresh)
<freemangordon>
@ what voltage?
<uvos__>
hw defined
<uvos__>
3.3 or so i think
<freemangordon>
I see
<uvos__>
but it comes repeatably below that thresh
<uvos__>
and then the driver checks the voltage when the irq fires
<freemangordon>
so you think we shall filter in irq
<uvos__>
i think it dose that 3 times and makes a avg
<freemangordon>
handler
<uvos__>
allready
<uvos__>
iirc
<uvos__>
but it needs to be longer i gues
<freemangordon>
I see
<freemangordon>
well, counting to 3 is wrong I would say :)
<freemangordon>
if irq rises every ms
<uvos__>
sure but i think the irq handler dose 3 mesurements by itself
<freemangordon>
ahaaa
<uvos__>
iirc, but dont have the code infront of me rn
* freemangordon
ckecks the code
<freemangordon>
I see no filtering whatsoever, maybe I can;t find it
<uvos__>
ok
<uvos__>
maybe the 3 mesruements was for someting else (callibration maybe)
<uvos__>
anyhow that needs filtering somehow (irq handler)
<uvos__>
also throtteling, while at it
elastic_dog has quit [Ping timeout: 260 seconds]
akossh has joined #maemo-leste
<freemangordon>
do we have some standard API to do that? or we shall invent it
<freemangordon>
or, you mean we shall not call power_supply_changed() more than once every few seconds?
<freemangordon>
from the irq handler that is
<uvos__>
throtteling is achived by disabeling the irq for some seconds
<uvos__>
by changing cpcaps irqmask
elastic_dog has joined #maemo-leste
<freemangordon>
ok
<freemangordon>
do you know how often does it come now?
<uvos__>
not exactly if you want a ms number
<uvos__>
very often sometimes
<uvos__>
btw the thing is qutie suspect to me anyhow
<uvos__>
im not srue cpcap even guarentees the irq will fire ever again after thresh
<uvos__>
it might just because noise
<uvos__>
anyhow tmlind obviously thought it did
<uvos__>
maybe he can enlighten us
<freemangordon>
yep, I'll pester him on that one
<uvos__>
i get the fealing maybe we should just disable the irq after geting it once and poll after that, untill we shtudown or the charger is plugged
<freemangordon>
lemme see in the logs, yesterday I had mce stopped
<freemangordon>
so I should have several "low" messages in dmesg
<uvos__>
dmsg absolutly spamms you will low becasue of the irq below a thresh
<uvos__>
s/will/with
<freemangordon>
umm, then I don't understand "im not srue cpcap even guarentees the irq will fire ever again after thresh"
<uvos__>
the code as is
<uvos__>
assumes that cpcap will fire the low irq repeadbly after crossing the threshold
<uvos__>
in reality i suspect its just a comperator
<uvos__>
that will fire only when the voltage passes thresh
<uvos__>
that means the kernel may never shutdown
<freemangordon>
it did yesterday
<uvos__>
if the irq fires, the kernel thinks voltage is high enoguh and cpcap thinks its low and has done its duty
rafael2k has quit [Ping timeout: 265 seconds]
<uvos__>
freemangordon: right so tmlinds assumption was wrong
<uvos__>
and wee nedd to " i get the fealing maybe we should just disable the irq after geting it once and poll after that, untill we shtudown or the charger is plugged"
<freemangordon>
yep, I see irq storm in th elogs
<freemangordon>
about low battery
<freemangordon>
what is weird though is the voltage
<freemangordon>
I see battery low @ 3661 mV
<uvos__>
oh ok
<uvos__>
i never see it before 3.3 or so
<uvos__>
i gues its old battery spikes again
<uvos__>
seeing it very early is not that unusual if your battery is really bad i gues
<freemangordon>
ok, but @ 3.6V :)
<uvos__>
the irq is unfiltered ofc and very fast
<freemangordon>
yeah
<uvos__>
that means your droping below 3.3
<freemangordon>
I guess this drains it even faster :)
<uvos__>
even while mostly charged
<freemangordon>
right
<uvos__>
thats bad
<uvos__>
that means your droping > .3 volts
<uvos__>
d4 hw has ram erros below 2.9 or so
<uvos__>
so you might be even flipping bits with that
<freemangordon>
the storm continues for 5 seconds
<freemangordon>
and then it stops
<freemangordon>
seems irq is triggered every 20-30 ms though
<freemangordon>
hmm, no
<freemangordon>
it is not on interval
<uvos__>
its probubly triggering on noise after that, is my suspicion
<uvos__>
not a time
<freemangordon>
mhm
<freemangordon>
why do we need to start poling once we have 'low' irq?
<uvos__>
becasue how would you know when to shutdown?
<uvos__>
you can rely on noise triggering the irq again
<freemangordon>
we have 2 irqs
<freemangordon>
one for low and one for empty
<uvos__>
i dont think we use the empty one directly
<uvos__>
iirc
<freemangordon>
sure we do
<uvos__>
without mesrueing the voltage?
<freemangordon>
wit measuring
<uvos__>
right
<freemangordon>
*with
<uvos__>
the problem is
<uvos__>
empty irq fires
<freemangordon>
well, it uses the last measurement
<uvos__>
we messure voltage
<uvos__>
we think its ok to not shutdown
<uvos__>
now what?
<uvos__>
the irq may never come agian
<freemangordon>
obviously it comes
<uvos__>
because of noise
<freemangordon>
does not matter
<uvos__>
idk if you cna rely on that
<freemangordon>
hmm, I see
<uvos__>
even if it mostly works
<uvos__>
the voltage may be very clean for some reason
<freemangordon>
what we can do:
<uvos__>
phone is is continuous off mode or whatever
<freemangordon>
once we have "empty" irq, start polling every 10 seconds or so
<uvos__>
right
<uvos__>
thats what i said :)
<freemangordon>
if we see voltage < 3.2, shutdown
<uvos__>
"i get the fealing maybe we should just disable the irq after geting it once and poll after that, untill we shtudown or the charger is plugged"
<freemangordon>
you were talking abot "low" not "empty" :)
<uvos__>
well both
<freemangordon>
no
<uvos__>
both have the sam eproblem
<freemangordon>
we should disregard empty
<freemangordon>
once it comes
ceene has quit [Ping timeout: 244 seconds]
Daaanct12 is now known as Danct12
<freemangordon>
we shall not start poll on "low" only on "empty"
<uvos__>
if you want the low indicated to uapi to be realiable
<uvos__>
you have to do the same thing to it too
<uvos__>
its not as important i gues
<uvos__>
but otherwise it holds
<freemangordon>
obviously it went below the threshold, no?
<uvos__>
sure
<freemangordon>
so it is low
<uvos__>
but yours is obviously totaly bonkers
<freemangordon>
sure
<freemangordon>
the point is that it does not really matter how much "low" it is, from the shutdown perspective
<uvos__>
sure
<freemangordon>
so, once we detect low, we disable the irq and enable it back only on charger connected
<uvos__>
or reboot yes
<freemangordon>
well, power-up will enable it for us, obviously :)
<freemangordon>
hmm, wait
<uvos__>
well avoid writeing the state to nvmem xD
<freemangordon>
you are right we shall start some polling for couple of seconds
<freemangordon>
or not?
* freemangordon
checks how mce decodes to shutdown
<freemangordon>
*decides
<uvos__>
mce just gets the voltage from upower
<uvos__>
and descides to shutdown on thresh
<uvos__>
not by default at all btw
<uvos__>
its a device specific config activated on mapphones
<freemangordon>
it receives UP_DEVICE_STATE_EMPTY
<uvos__>
it dosent use that
<uvos__>
it uses the voltage
<uvos__>
and decides itself
<freemangordon>
both
<uvos__>
right both but the voltage is allways sooner
<freemangordon>
ok, so upower does not filter enough
* freemangordon
is afk for few minutes
<freemangordon>
uvos__: ok, what I think I will implement for now, is to disable 'low' interrupt for 30 seconds and then re-anable
<freemangordon>
*re-enable
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
dev has left #maemo-leste [#maemo-leste]
dev has joined #maemo-leste
dev has left #maemo-leste [#maemo-leste]
dev has joined #maemo-leste
rafael2k has joined #maemo-leste
ceene has joined #maemo-leste
xes has quit [Remote host closed the connection]
xmn has joined #maemo-leste
xes has joined #maemo-leste
<uvos__>
freemangordon: ok well thats not really a final solution, but may at least defer the problem so that its not too annoying for people with batteries that are close to death
<buZz>
hehe yeah, that 'low battery' poweroff is kinda annoying, i even had it happen on ~80% charge
<freemangordon>
thats upower misbehaving, but that's another story
<freemangordon>
uvos__: oh, BTW, I checked GFX domain and it enters OFF when screen is on
xes has joined #maemo-leste
<uvos__>
freemangordon: i mean yeah it should, but it dident in the past at some point post ddk 1.9
<uvos__>
so good
<freemangordon>
for sure it does now
<uvos__>
also iirc on android dss enters off too
<uvos__>
and dosent on leste
<uvos__>
(screen on)
<freemangordon>
did you check?
<uvos__>
sure yeah when i was debugging power things
<uvos__>
1 year ago
<uvos__>
so its more of a check this again, not a its broken
<freemangordon>
yeah, it stays ON
<uvos__>
ok i gues the android kernel has special handlig for the command mode dsiplay
<uvos__>
on a regular display dss cant be off ofc
<freemangordon>
hmm, wait
<freemangordon>
I am playing video :)
<uvos__>
lol
<freemangordon>
lemme stop it
<uvos__>
ok
<uvos__>
another problem is
<uvos__>
that we have just one gfx clock
<uvos__>
while android scalles it
<uvos__>
we just have off and full blast
<freemangordon>
yeah
<uvos__>
android ussually never even needs full sgx clock in the ui
<freemangordon>
uvos__: hmm actually OFF counter increases when the display is on
<freemangordon>
so I guess this is some artificial VSYNC that's going on
<freemangordon>
not that it is good, I will have a look at it
<uvos__>
ok
<uvos__>
well that means the code path at least is sorta there
<uvos__>
to suspend dss with cm mode pannel
<freemangordon>
ok, I see no ioctls with display enabled
<freemangordon>
DRM ioctls that is
<freemangordon>
well, there are few, every 10 seconds or so
<freemangordon>
but nothing to keep it ON
<freemangordon>
maybe gsm signal strenght gets updated
xes has quit [Read error: Connection reset by peer]
<uvos__>
maybe check if its sill a poblem in a vt
<uvos__>
(disable the cursor ofc ;))
<freemangordon>
will do
<freemangordon>
but not now
<uvos__>
ok
<freemangordon>
lets first see the battery low patch
<buZz>
:) oh that display thing is weird too
<buZz>
sometimes it seems X thinks the screen is turned off, and you need to press a button for it to 'turn on' before the button arrives at (say) xterm , but the screen would already be on
<buZz>
feels kinda like DPMS is enabled but not supported, or something
<buZz>
wow did something in charging change? i see d4 charging a lot faster now
<buZz>
hmmz, wiki seems offline, or at least superslow
<rafael2k>
btw, I have a very strange behavior with the screen backlight when I connect a USB mouse, the screen starts to dim, until it turns off.
<rafael2k>
also, most likely a WiFi regression, maemo does not connect to an available network, but always try to connect to the latest network, even if it is not available
<rafael2k>
I dunno if it was always like this, but it does not seems right
<buZz>
rafael2k: hm? thats kinda normal? i mean 'dimming and then off' is the normal maemo 'idle screen off'
<buZz>
ohhh, you mean, its still turning off even though you are giving external inputs?
<buZz>
that connection stuff is about auto-connecting to wifi?
<rafael2k>
buZz: no no, as soon as I connect a USB mouse, it starts to dim off
<buZz>
huh
<buZz>
thats bizar, lemme try :D
<rafael2k>
indeed, very bizar
<buZz>
*digs around for a usb mouse*
<rafael2k>
buZz: auto-connecting to wifi - yes - it has a problem
<rafael2k>
it does not try to connect to an available network, but to the last one
<buZz>
initially? or all the time? does it never get on the available one?
<rafael2k>
I need to manually choose the available one
<buZz>
eh, i just connected a usb mouse, and screen doesnt dim
<buZz>
rafael2k: you're using a d4 aswell?
<rafael2k>
strange, here the issue starts imediatelly
<rafael2k>
nope, just the PP
<buZz>
oh ok, i dont have a usb-c mouse or adapter
<rafael2k>
USB is indeed working fine, apart of this issue... I dunno if when we have usbnet back things will keep working
<buZz>
aha! screen did dim -eventually- like from normal timeout on maemo
<buZz>
BUT , moving usb mouse does not undim!
<rafael2k>
indeed!
<buZz>
tapping screen -does- undim directly
<buZz>
weird issue :P but feels related to my eh 'screen is on but needs a keypress before working'
<rafael2k>
but the strange thing for me is that just plugin the USB mouse triggers the dimming
<buZz>
hmhm, i'm not using PP a lot
<buZz>
was great to see the GPU finally getting somewhat fast though :)
<rafael2k>
also, the mouse wheel makes lots of system clicks sounds... unless I set the system to be silent
<rafael2k>
: )
<rafael2k>
not a big issue thou
<buZz>
hmhm? well 'mousewheel' usually is >1 button, isnt it?
<buZz>
its 'down X lines' or something
<buZz>
i'll try to make a issue from this topic
<rafael2k>
I dunno, but mouse wheel movements makes the same system sound as a left or right click
<buZz>
yeah that regressed, it was working briefly before
<buZz>
oh, it does work on d4 running -devel
xes has quit [Remote host closed the connection]
<buZz>
rafael2k: are you on -devel?
<freemangordon>
rafael2k: what does it mean "does not connect to the available network?" it connects only to networks that are in the connections list
<freemangordon>
like, you should have connected at least once
<freemangordon>
*manually*
<rafael2k>
buZz: yes, on -devel
<rafael2k>
freemangordon: it was connected to a known network, then this network goes out of range, the phone does not connect to a known available network automatically
<freemangordon>
hmm, weird
<freemangordon>
is it set to do it?
<freemangordon>
in settings
<buZz>
'autoconnect' isnt tested a lot yet, btw
<buZz>
i guess i should enable it now that gprs is working so well <3 <3
<freemangordon>
it is not tested, but at least on my d4 it works fine
<buZz>
rafael2k uses a PP
<buZz>
rafael2k: you autoconnect to 'any' or just wifi?
<buZz>
rafael2k: do they, by chance, share the same SSID?
<buZz>
right, but why even use voltage_now , that drops a ton even if you just turn on the screen
<buZz>
voltage_avg is the filtered one
<freemangordon>
not everyone supports it it seems
<freemangordon>
d4 for example :)
<buZz>
it does?
<freemangordon>
where?
<buZz>
wait, i think it does
<freemangordon>
nope
<freemangordon>
see /sys/class/power_supply/battery
<buZz>
oh, indeed
<freemangordon>
buZz: BTW I know rafael2k uses PP, it is just that icd2 does not care if it is PP or d4
xes has joined #maemo-leste
<buZz>
maybe we could add a voltage_avg output to cpcap-charger.c ?
<buZz>
or cpcap-battery.c
<buZz>
just eh. average of last X samples
<freemangordon>
that wouldn;t help upower
<buZz>
yeah , not as-is, unless we flip _now and _avg on the lines you linked
<freemangordon>
oh, this is again spinal
<buZz>
(afaics)
<freemangordon>
"Subject: [PATCH] Add voltage estimated percentage fallback"
<freemangordon>
"This is common code for status-area-applet-battery and mce"
macros_ has joined #maemo-leste
<freemangordon>
so, I think we shall fix that by trying _avg first and if there is no, average _now
<freemangordon>
or, provide both voltage_avg and voltage_now and leave users decide what they prefer
<buZz>
does upower even support providing both?
<freemangordon>
upower supports neither
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
xes has quit [Read error: Connection reset by peer]
<freemangordon>
this is code added by spinal.by at gmail.com
<freemangordon>
the same guy that made a rage quit
ceene has quit [Remote host closed the connection]
<freemangordon>
because I 'stole' *his* clutter code
<freemangordon>
anyway
<buZz>
rofl
<uvos__>
so the scrollwheel making sounds is as designed
<uvos__>
thats the mousebutton click in mis
<uvos__>
the mouse not undiming the screen is probubly mce misscharacterizing the mouse as a keyboard
<uvos__>
could you post the evtes output of that mouse
<uvos__>
idk whats going on with the display dimming when you insert a mouse but just on pp
<uvos__>
mabybe this is a hw interaction between vbus and the light sensor or sometheing
<uvos__>
no idea
<freemangordon>
could be the same issue I see on d4
<uvos__>
maybe run mce with --verbose --verbose and give me the output
<uvos__>
freemangordon: at least buZz repoted it dident happen to him
<freemangordon>
I am seeing it when I connect a charger
<freemangordon>
hmm, lemme try to repro and see the logs
<buZz>
freemangordon: your screen dims when you connect a charger?
<buZz>
not here, indeed
<freemangordon>
when I disconnect it
<buZz>
not here either
<buZz>
do you have 'screen on when charging' set?
<freemangordon>
yes
<buZz>
i dont
<uvos__>
pretty wierd behavior
<uvos__>
all around
<freemangordon>
does not happen all the time though
<buZz>
uvos__: you want me to post something about a usb mouse?
<uvos__>
yeah
<uvos__>
evtest
<uvos__>
the list of events it supports
<buZz>
alright
<buZz>
hmmm , i dont have evtest, what package is that in?
<uvos__>
i think evtest
xes has joined #maemo-leste
<buZz>
indeed :)
* buZz
waits for dpkg lock to release after connecting wifi -_-
<buZz>
how do i disable that behaviour? :D
<buZz>
funny, a mouseclick does undim screen , movement just doesnt
<freemangordon>
uvos__: hmm, you said 'screen on when charging' does nto work, but it seems it works now
xes has quit [Ping timeout: 250 seconds]
<freemangordon>
it does not work correctly (like, it does not turn the display on when charger is connected), but at least display stays lit when connected
<uvos__>
unless i forgot that i partally implmented this again (very unlikely), its not mce
<freemangordon>
we see MCE_DISPLAY_ON in /build/mce-1.9.17+2m7/src/modules/display.c display_on_req_dbus_cb 446, which in turn calls display_state_filter
<freemangordon>
however, noone sets inactivity to FALSE
<freemangordon>
also, why is dbus call allowed to turn display on unconditionally?
rafael2k has quit [Ping timeout: 244 seconds]
<freemangordon>
hmm, it is the same on fremantle
<freemangordon>
besides that it does not reset inactivity to false on OFF
Pali has joined #maemo-leste
<freemangordon>
ok, I was able to repro: if you send display on request while it dims
<uvos>
seams wierd that something would force mce to turn the display on on usb unplugging
<freemangordon>
trying to find who sends that
<uvos>
that behavior should probubly be added to mce while reimplmenting the keep display on while charging thing
<uvos>
and removed where its now
<freemangordon>
there is no such code in stock mce
<freemangordon>
I guess it is you that added it at some stage
<uvos>
no what code?
<freemangordon>
but, that's not the point
<freemangordon>
display_state_filter
<freemangordon>
in inactivity
<uvos>
right yes i split the display module into several
<freemangordon>
still, that's not important
<uvos>
no and i wasent asking that
<freemangordon>
I think there are no other issues, besides that there is some problem while it dims
<freemangordon>
also, "stay lit while charging' works when started from ssh session
<freemangordon>
but not when started as a service
<freemangordon>
at least this is waht I saw
<freemangordon>
but I'll investigate later
<freemangordon>
after I find who TF sends req_display_blanking_pause on unlock
<uvos>
tklock prob
<uvos>
i dont see it
<uvos>
(and i dont run tklock)
<freemangordon>
why tklock shall send that to mce?
<uvos>
no idea
<freemangordon>
no way, afaik
* freemangordon
checks
<uvos>
im just checking whats different
<freemangordon>
do you know how to find pid from service id?
<uvos>
no
<sicelo>
buZz: re _avg, i think the kernel api says sysfs shall only contain what is reported by device/hardware ... not extrapolated data. so if cpcap has no concept of _avg, then it shouldn't exist in sysfs. at least that's how i understand it
<uvos>
that is correct
<uvos>
altho the cpcap modules allready violate that
<uvos>
but this is also what breaks <30sec timeouts
<freemangordon>
< 60 I would say
<uvos>
becasue req_display_blanking_pause is for at least 60 sec
<uvos>
right
<uvos>
60
<freemangordon>
ok, but why it works on fremantle
<uvos>
it dosent
<uvos>
its broken on freemantle too
<uvos>
try 10s timeout
<freemangordon>
anyway, we find 2 issues
<freemangordon>
yes
<uvos>
and unlock via vtklock
<freemangordon>
it could be my REing
<freemangordon>
have to check what stock code is doing
<uvos>
rught ill fix mce issue later
<uvos>
and buZz's mouse issue to
<freemangordon>
great, thanks
<uvos>
that one looks easy
<buZz>
<3 not my issue uvos , just confirmed and described it ;)
<freemangordon>
uvos: maybe there is issue in mce
<freemangordon>
I will check in fremantle mce how it decides to stop blank prevention
dev has quit [Quit: Gateway shutdown]
norayr has quit [Quit: Gateway shutdown]
Twig has quit [Read error: Connection reset by peer]
norayr has joined #maemo-leste
norayr has left #maemo-leste [Disconnected: closed]
norayr has joined #maemo-leste
<dreamer>
generating locales took a while so I went to do other things. now after the dist-upgrade I rebooted. now the wifi connection doesn't seem to work any more. cannot bring up the internet connection widget
<dreamer>
s/widget/selector-thingy
<dreamer>
any changes in this in the last months?
<dreamer>
actually, the keyboard also doesn't respond
<dreamer>
terminal closes after starting ..
<dreamer>
so. I guess I'll just have to reflash the damn thing ..
<Wizzup>
dreamer: sounds like a bad upgrade experience for sure
Twig has joined #maemo-leste
<dreamer>
Wizzup: my role as "dumb user that upgrades once every couple months" pays off again ;)
<dreamer>
(in generally a pretty good metric for how stable an OS is for the general public, imo)
* sicelo
has burned image only once. everything else is just apt-get (dist-)upgrade
<sicelo>
the commonly stated reason for migrating away from ofono to MM within mobile linux communities has been 'ofono development is slow and they do not accept contributions'
<dreamer>
Wizzup: hmhm. will reflash when I have time :)
xes has joined #maemo-leste
<uvos>
freemangordon: the display module is nolonger involved in the blaning inhibit
<uvos>
i move that to its own module
<uvos>
freemangordon: so your adding a new interface that allows you to remove the blaning pause?
<uvos>
ok, by why dose tklock need to do this at all
<freemangordon>
yes
<uvos>
it gets its own submode in mce anyhow
<freemangordon>
it sets DND on tklock window
<uvos>
so mce could just do whatever beavior wise
<uvos>
no dnd needed
<uvos>
and infact it dose
<uvos>
i think the tklock module disables blanking anyhow while in vtklock
<freemangordon>
well, it is not about tklock, but about hildon_gtk_window_set_do_not_disturb()
<uvos>
sure, im just questioning why tklock needs to call this
<freemangordon>
every application that calls this will break blanking period for 60 seconds
<freemangordon>
not sure
<uvos>
yes i know
<uvos>
the patch is fine
<freemangordon>
So, my fix is in that regard
<freemangordon>
we may remove hildon_gtk_window_set_do_not_disturb() from vtklock, but that's another story
<freemangordon>
ok, so I'll push that to mce and will fix h-d to use the new interface
<freemangordon>
uvos; what will happen if some application requests MCE_DISPLAY_OFF while vtklock is active? maybe this is why they set DND
<freemangordon>
realy hard to say what did they have in mind
<uvos>
mce should/could ignore it in tklock mode anyhow
<uvos>
dnd or no
<freemangordon>
yes, but does it ignore it now? maybe that pisece was/is missing so that's why they set DND
<uvos>
anyhow it was broken in fremantle so im not sure they had something sane in mind.
<freemangordon>
*piece
<freemangordon>
could be
Livio has joined #maemo-leste
Livio has quit [Changing host]
Livio has joined #maemo-leste
pere has quit [Ping timeout: 244 seconds]
akossh has quit [Quit: Leaving.]
uvos has quit [Ping timeout: 265 seconds]
Livio has quit [Ping timeout: 252 seconds]
pere has joined #maemo-leste
<Wizzup>
btw, we passed the first round for nlnet funding, but there is another round, if we pass that, the organisation will get more funding