<freemangordon>
I guess this shall be changed to install_kernel_headers debian/linux-headers ${version};;
fmg_d4 has joined #maemo-leste
fmg_d4 has quit [Client Quit]
akossh has joined #maemo-leste
pere has quit [Ping timeout: 256 seconds]
amunizp has joined #maemo-leste
System_Error has quit [Ping timeout: 260 seconds]
pere has joined #maemo-leste
<Wizzup>
freemangordon: good catch
<Wizzup>
freemangordon: wpa supp in experimental is backported version
ceene has quit [Ping timeout: 246 seconds]
Oksana has joined #maemo-leste
Daanct12 has joined #maemo-leste
arno11 has joined #maemo-leste
<freemangordon>
Wizzup: uvos: another nasty bug, either in sphone or in vcm: if another side hangs-up before call is answered, ringing continues forever
<freemangordon>
even if you close sphone, it does not stop
<arno11>
i remember seeing that bug with vibrator in the past but never with ringtone (at least when ringtone works)
<freemangordon>
well, now (on 6.6) ringtone works every time
<freemangordon>
and that bug is 100% reproducible
<freemangordon>
at least on d4
<freemangordon>
Wizzup: did you check your d4 idle power usage?
<arno11>
ok, btw i got ringtone working on 6.6 as well but stopped working after a while
<freemangordon>
Wizzup: even with iphb it is twice the one on 6.1 here
<arno11>
wow
<arno11>
something blocks ret ?
<freemangordon>
perhaps, but I don;t know how to test properly
<arno11>
you can use pm script
parazyd has quit [Ping timeout: 272 seconds]
parazyd has joined #maemo-leste
<arno11>
can't remember the exact name for d4, something like droid4-pm in /etc/init.d
<arno11>
'status' should show the number of ret and blockers if any
<arno11>
good question, that's really difficult (see N900 mess with blockers lol)
<Wizzup>
freemangordon: this bug is fixed, the one you mention
<Wizzup>
re infinity ring
<Wizzup>
freemangordon: this is not likely, but I have a droid 4 that I had on a lab psu and something inside it broke nad it has like much higher power usage than all my other droid4s
<Wizzup>
I get 2-3 days on full chrage on 6.6
<Wizzup>
freemangordon: shall I build current 6.6 for experimental, although I guess I need to fix header thing
<Wizzup>
freemangordon: if the bug re-appeared I will see what's up
<Wizzup>
2b3faf00e071ceeb7add6827c53686e6446a25ee ("voicecallmanager: ensure we receive hangup")
<Wizzup>
^ fixes it
<freemangordon>
Wizzup: is that released?
<Wizzup>
I am checking
<Wizzup>
I think probably not actually since the rtco logging is still broken wrt fremantle
<freemangordon>
well...
<Wizzup>
so yeah not released apparently
<freemangordon>
could you release it?
<Wizzup>
I can, but the rtcom logging is still broken ;)
<Wizzup>
I'll take a look, IIRC there was/is the matrix breakage still
<freemangordon>
well, my d4 was ringing for 2 hours until I got bach home :)
<freemangordon>
*back
<freemangordon>
Wizzup: I'll revert the kernel to see how it is with 6.1
<Wizzup>
freemangordon: oof...
<freemangordon>
so I doubt it is HW failure
ceene has joined #maemo-leste
<freemangordon>
hmm, droid4-powermanagement checks for non-existent module names
<Wizzup>
they might be blacklisted at this point
branon has quit [Server closed connection]
<Wizzup>
or not built
<freemangordon>
no, they are loaded, but names are with undersore and not dash ;)
<freemangordon>
like phy_cpcap_usb
branon has joined #maemo-leste
<Wizzup>
maybe this changed in kernels
<freemangordon>
rmmod phy_cpcap_usb does not seem to help much
<freemangordon>
or it does?
<freemangordon>
Wizzup: coud you do:
<freemangordon>
/sys/class/power_supply/battery$ while [ 1 ]; do cat power_avg; sleep 30; done
<Wizzup>
on wifi, not on wifi?
<freemangordon>
on wifi
<Wizzup>
I can, but I get 2-3 days, which is the same as on 6.1 more or less :)
<freemangordon>
through ssh session
<Wizzup>
maybe it is related to audio somehow?
<Wizzup>
k
<freemangordon>
could be, dunno
<freemangordon>
do you have phy_cpcap_usb loaded?
<Wizzup>
if you build sphone locally, in case you do, also pull 0302bd946c5766d7fd808b9b2dae7a32dfa2f1a9 since it makes rtcom logging ok for vcm
<Wizzup>
will check, just a moment
fmg_leste_vm has quit [Quit: fmg_leste_vm]
<freemangordon>
why shall I build it locally?
<freemangordon>
I am waiting for you to make a release :)
<Wizzup>
to get the rtcom logging fixes
<Wizzup>
uvos doesn't like the way I did them so I have to re-do it
<Wizzup>
but I'll push the ringing fix at least
<Wizzup>
s/push/release/
<freemangordon>
ah, that's another branch I guess
<Wizzup>
you can git fetch the object
<Wizzup>
git fetch origin ...
<freemangordon>
right
<Wizzup>
in any case
<Wizzup>
good news is that if you were still on that version, you should be much happier with the upcoming one
<freemangordon>
that's why I asked you to see what is your power usage and if you have that module loaded
<Wizzup>
$ while [ 1 ]; do cat power_avg; sleep 30; done
<Wizzup>
1023305
<Wizzup>
250329
<Wizzup>
242813
<Wizzup>
227080
<Wizzup>
225047
<Wizzup>
and then it dropped from wifi since it seems to do that with 6.6
<Wizzup>
here is the rest
<Wizzup>
225047
<Wizzup>
156816
<Wizzup>
136867
<Wizzup>
I do have phy_cpcap_usb loaded
<freemangordon>
ok, lemme see what is usage here without wifi
<Wizzup>
I don't think we block this module in modprobe.d though
<Wizzup>
yeah the last two numbers are with wifi off I think
xmn has quit [Ping timeout: 256 seconds]
<freemangordon>
fir me wifi is better with 6.6
<freemangordon>
*for
<Wizzup>
funny :)
<freemangordon>
like, most of the times it connects from the first time after boot
<freemangordon>
and never drops
<Wizzup>
let's see if our CI can still build stuff :D
<Wizzup>
freemangordon: interesting, that would be nice
<Wizzup>
so we should fix the droid4 pm script, but for the record we don't block the phy_cpcap_usb per our config currently
<Wizzup>
I'd have to check the logs to remember why
<freemangordon>
hmm, usage from osso-xterm, with wifi off produces 182 mW at minimum
<freemangordon>
going to revert the kernel to see if it makes any difffernence
<Wizzup>
so I am not yet on -your- 6.6 for lack of better terms
<Wizzup>
could it be that some audio path is always on
<freemangordon>
Wizzup: please fix config and headers path
<freemangordon>
yes, could be
<Wizzup>
maybe you can check alsa dapm entries in /sys
<Wizzup>
freemangordon: I will look, I think you already found the problem, right?
<freemangordon>
yes, but didn;t make a fix
<Wizzup>
ok
<freemangordon>
where to check those dapm entries
<freemangordon>
?
<Wizzup>
/build/sphone-0.9.3+m7/src/modules/contacts-evolution.c:124:53: error: 'E_CONTACT_IM_MATRIX' undeclared (first use in this function); did you mean 'E_CONTACT_IM_AIM'?
<Wizzup>
I don't know if we monut it by default, it's not considered good practice from a security pov
Wikiwide has quit [Read error: Connection reset by peer]
<freemangordon>
scratch that
<freemangordon>
I was not root
<Wizzup>
ok
<arno11>
Wizzup: commenting matrix stuff (temporary) in contacts-evolution.c fixes the issue btw, at least on a local build
<arno11>
iirc
<Wizzup>
yes, but will uvos like it if I comment it out in the master branch temporarily? :D
<Wizzup>
from my pov it looks like the libebook version he uses locally is not the same as the leste one
<Wizzup>
and ours just doesn't have this other field
<arno11>
for master branch: ah yes indeed...:D
<Wizzup>
but the bug has been there since april
<Wizzup>
iiuc
<freemangordon>
Wizzup: most of dapm entries are On
<freemangordon>
how to torn them off?
<Wizzup>
freemangordon: I don't think they are supposed to be
<freemangordon>
*turn
<Wizzup>
I suspect this is the c2c change, if you're still seeing more power management
<Wizzup>
what toggles/turns on the c2c?
<Wizzup>
s/more power management/more power usage/
<freemangordon>
no idea :D
<Wizzup>
ok
<Wizzup>
so I think we should build this with the fixed headers because it's still quite useful for experimental
<freemangordon>
but I guess it is route in DT
<freemangordon>
lemme check something
<Wizzup>
the way I would imagine it would work from userspace is we switch UCM, which sets/triggers some alsa toggles in one of our codecs/cards and that should enable the route
<Wizzup>
but again this is from my very naive understnading
<Wizzup>
if there's nothing that triggers it either way, it's probably always on
<Wizzup>
let me look at the headers issue
<Wizzup>
I pushed headers fix to maemo-6.6.y
<arno11>
cool
<Wizzup>
freemangordon: btw, as far as I can concerned, you can take current maemo-6.6.y and rebase it to get rid of 'xxx' commit a bit later today
<Wizzup>
this is a branch that we -rebase- on linux-stable nayway
mdz has joined #maemo-leste
<freemangordon>
I will not have tiome to do anything later today
<freemangordon>
I am traveling for few days
<freemangordon>
Wizzup: what am I supposed to use to try to turn that control off?
<Wizzup>
well
<Wizzup>
I don't know what limitations kernel puts on you, but I suspect some alsa widget
<Wizzup>
if that is the right perminology
<freemangordon>
but I can;t find any that's related
<Wizzup>
just a second
<Wizzup>
I will try to explain what I mean
<Wizzup>
so if you run alsamixer -c 0
<Wizzup>
you sohuld get Mapphone Audio card
<Wizzup>
and then there is an item called 'Call Output'
<Wizzup>
this can be set to Handset, Headset, Speakerphone
<Wizzup>
I imagine that we could have something like this that just says 'yeah we are in a call', and we could set that through UCM
<freemangordon>
I think I checked and it is off
<Wizzup>
well this is just an example
<freemangordon>
but lemme double-check
<Wizzup>
either that or something we can turn on/off, like for example the 'Earpiece' item
<Wizzup>
earpiece can be off/HiFi/Voice
<freemangordon>
on alsamixer everything is off
<Wizzup>
but I think we need something that triggers the actual c2c to become active (well, you have it active currently of course, but ewr need to be able to toggle it)
<freemangordon>
switching the ucm profile does it
<Wizzup>
as far as I am concerned you can call it 'c2c toggle' and we can turn it on/off, as long as it controls dapm for this new path
Livio has quit [Ping timeout: 268 seconds]
<Wizzup>
I understand, but my very naive understanding is that you added a new codec or card that has a special codec to codec routing (c2c) and this makes it active without userspace interaction, right?
<freemangordon>
It is called 'Voice Call Playback'
<Wizzup>
ok, and what can this be set to?
<freemangordon>
how do I know/
<freemangordon>
?
<freemangordon>
this is in dapm
<Wizzup>
ah, not in alsamixer then
<freemangordon>
no widget
<freemangordon>
yes
<Wizzup>
right, so I think we maybe need a widget to control it
<Wizzup>
the example you followed from this other codec from 6.6, did that have a widget to control whether it was on/off?
<freemangordon>
no widget
<freemangordon>
it should be auto-disabled when not connected
<freemangordon>
well, I think it would be better if you build/install latest 6.6 and check what has to be done
<freemangordon>
as yoy have better understanding than me on asoc
<Wizzup>
I will try, but I can assure you that your understanding is better than mine, but I am happy to try
<Wizzup>
I don't know how kernel or userspace would know when it is connected
<Wizzup>
Like, something must trigger the route to be enabled/disabled, right?
<freemangordon>
yes, ucm
<Wizzup>
but ucm can only control widgets
<Wizzup>
and volume etc
<freemangordon>
right
<Wizzup>
so if there is no widget hooked up, I don't see how this can work,
<Wizzup>
like, can we not have a widget called 'Call' that can just be On or Off ?
<Wizzup>
which would trigger this new route to be on or off
<freemangordon>
hmm, nothing to be fixed there IIUC
<freemangordon>
Wizzup: sorry, can;t grok it ATM and out of spare time
<Wizzup>
ok
Livio has joined #maemo-leste
uvos__ has joined #maemo-leste
<uvos__>
Wizzup: oh jeah my debian d4 has newer ebook
<uvos__>
ill fix this when i get home
Daanct12 has quit [Quit: WeeChat 4.3.4]
Wikiwide has joined #maemo-leste
<Wizzup>
thx
branon has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
branon has joined #maemo-leste
Livio has quit [Ping timeout: 256 seconds]
nela has quit [Server closed connection]
nela has joined #maemo-leste
Wikiwide has quit [Remote host closed the connection]
Wikiwide has joined #maemo-leste
arno11 has joined #maemo-leste
Wikiwide has quit [Remote host closed the connection]
Wikiwide has joined #maemo-leste
Wikiwide has quit [Read error: Connection reset by peer]
<arno11>
Wizzup: i tried 6.6 with dts fix: it works but still got slowness after 30min. Seems something is wrong with memory because when i start a qt app after 1 min of idle, it becomes buggy
<arno11>
or maybe dynamic debug causes troubles ?
<arno11>
i really don't know what's going on
<arno11>
i mean it is so smooth now on my device with 6.1 that it is particulary noticeable when i run 6.6
<arno11>
*the slowness
mdz has quit [Remote host closed the connection]
mdz has joined #maemo-leste
<arno11>
btw guys, what is the best/easiest way to monitor read/write to disk ?
<freemangordon>
iostat?
mdz1 has joined #maemo-leste
mdz has quit [Ping timeout: 264 seconds]
mdz1 is now known as mdz
<arno11>
ok i failed to find it but maybe it is part of another pkg
pere has quit [Ping timeout: 268 seconds]
<arno11>
sysstat works (sar)
<arno11>
i'll compare 6.1 and 6.6
<freemangordon>
yes, iostat is part of sysstat
Wikiwide has joined #maemo-leste
sunshavi has quit [Ping timeout: 252 seconds]
sunshavi has joined #maemo-leste
ceene has quit [Remote host closed the connection]
arno11 has left #maemo-leste [#maemo-leste]
System_Error has joined #maemo-leste
pere has joined #maemo-leste
Livio has joined #maemo-leste
<Wizzup>
freemangordon: what did you need enabled in config
<Wizzup>
ah audio-graph-card2
uvos__ has quit [Remote host closed the connection]
<Wizzup>
done, building kernel
xmn has joined #maemo-leste
<Wizzup>
freemangordon: tested the kernel and yes, great, call audio is good with voicecall manager and 6.6
<Wizzup>
there's just the dapm being on stuff now :)
Livio has quit [Ping timeout: 240 seconds]
Livio has joined #maemo-leste
arno11 has joined #maemo-leste
<arno11>
ah good news @call audio
<sicelo>
yeah, nice sleuth work freemangordon
<sicelo>
and thanks Wizzup for the vcm stuff that triggered it ;-)
arno11 has left #maemo-leste [#maemo-leste]
uvos has joined #maemo-leste
<uvos>
Wizzup: you missed a tonne of changes in sphones changelog
<Wizzup>
well, the tag won't work anyway since it doesn't compile
<uvos>
it compile fine
<Wizzup>
not in the CI it doesn't
<uvos>
on newer debian
<uvos>
sure
<Wizzup>
ok, great, but you're in #maeom-leste
<Wizzup>
I think you can just rewrite the changelog and replace the tag or make a new tag
<uvos>
to late
<uvos>
i dont think thats relevant since i see leste as just one platform to support
<uvos>
anyhow
<uvos>
should build this time
<uvos>
Wizzup: chroot: failed to run command '/debootstrap/debootstrap': Exec format error
<uvos>
uhh
<Wizzup>
I will look in a bit
System_Error has quit [Remote host closed the connection]
<uvos>
dapm turns on the nodes on the route when it thinks the source is active and the route is unbroken
<uvos>
the source being a dai
<uvos>
i gues the kernel thinks the dai of the modem is active, we need to figure out how to make it know its not
<Wizzup>
switch seems like a great way imo, since we can toggle it from userspace with ucm without having to parse AT in kernel
<Wizzup>
well, -some- AT at least
<uvos>
doing that is def wrong form a framework perspective
<uvos>
nomater how nice it looks from userspace
<uvos>
but anyhow
<Wizzup>
I suppose this is relevant:
<Wizzup>
Make sure to name your corresponding cpu and codec playback and capture dai names ending with “Playback” and “Capture” respectively as dapm core will link and power those dais based on the name.
<uvos>
also i dont think you can shutdown cpcaps dai this way, at least thats before you could insert a switch in the chain is after the cpcap dai
<uvos>
looking at alsa/snd-soc stuff allways makes me think: this is really compilcated and this lacks features i need :P
<uvos>
also: i dont get how this bit works
<uvos>
skill issue i gues
<Wizzup>
it's not just you :)
uvos has quit [Quit: Konversation terminated!]
cockroach has joined #maemo-leste
fmg_d4 has joined #maemo-leste
fmg_d4 has quit [Client Quit]
amunizp has quit [Quit: Not sure what quit means.]