<Wizzup>
if that uses dsme, the timing won't change
<Wizzup>
at all
<parazyd>
Yeah, so that means it'll keep trying and failing until ofono starts
<parazyd>
You can rather use dsme from an initscript and get dependency handling for free
<parazyd>
And later on switch it out for supervise-daemon
<Wizzup>
why would it keep trying and failing?
<Wizzup>
I don't understand this
<Wizzup>
the way it is written now, does it crash in your xsession, and just never starts?
<parazyd>
Because the xsession runs before ofono
<Wizzup>
maybe we should just revisit the conversation once I fix the bug where it needs ofono running to start the app
<parazyd>
So the implication is that even with dsme, sphone fails to start N times
<Wizzup>
because that's really a bug
<parazyd>
By having this in openrc, you can depend on the ofono initscript and have it fail 0 times
<Wizzup>
please
<Wizzup>
ofono running is *not* a hard dep for the thing to start up
<Wizzup>
if it is, it is a bug and we need to fix it
<Wizzup>
just try /etc/init.d/ofono stop, then app will keep running np
<parazyd>
yes but it's useless
<Wizzup>
???
<parazyd>
e.g. I can't make a call
<Wizzup>
yeah, so?
<Wizzup>
that has nothing to do with it being a bug that it cannot start when ofono is not running
<Wizzup>
by design this should be no problem, and it should just pick up on ofono when it arrives on the bus
<Wizzup>
it's entirely unrelated to what the startup looks like
<Wizzup>
in any case let's wait for uvos and see what he thinks
<parazyd>
actually when I look at the code it's using g_error
<parazyd>
This is wrong
<parazyd>
Because this calls abort()
<parazyd>
Hence the failure
<parazyd>
uvos ^
elastic_dog has quit [Ping timeout: 240 seconds]
elastic_dog has joined #maemo-leste
pere has quit [Ping timeout: 245 seconds]
xmn has quit [Ping timeout: 240 seconds]
cockroach has joined #maemo-leste
amk has quit [Ping timeout: 268 seconds]
amk has joined #maemo-leste
amk has quit [Ping timeout: 268 seconds]
amk has joined #maemo-leste
zhxt has quit [Ping timeout: 248 seconds]
pere has joined #maemo-leste
dos is now known as dos1
uvos has joined #maemo-leste
<uvos>
Wizzup: just started working again
<uvos>
Wizzup: i gues the blocking takes a while to propogate
<uvos>
Wizzup: also ill just get blocked again as soon as the original spammer who i share an ip with gets reported again :\
<uvos>
this isp nat has been the the bane of my existance before :P
<uvos>
yeah so the fact that sphone needs ofono to run is accidental-on-purpose
<uvos>
so sphone registers lots of handlers for interfaces on dbus for ofono
<uvos>
and it only dose this once (now and with the old dbus code)
<uvos>
so it dosent work if started later
<uvos>
the old code dident exit
<uvos>
but it dident work either if ofono was not available
<uvos>
now we could/ should improve this
<uvos>
but thats the current state
<uvos>
parazyd: Wizzup: so openrc should not start user services, it afaik dosent have any real features to support those (unlike systemd)
<uvos>
we should thus not start sphone with openrc
<uvos>
just like dsme should not be starting system services....
<uvos>
long term we need a real session manager of some kind
<uvos>
we could lift one from elsewhere or reduce and ammend (mostly reduce) dsme until its usable as a session manager and dosent do anything else anymore.
<Wizzup>
I think dsme makes sense here, we use it in other places, and in the rare case that sphone might crash, it's kinda nice to have it start again, esp if it crashes in the background
<Wizzup>
no need to really revisit the dsme discussion again imho, but we can check what fremantle does
<uvos>
right dsme makes sense for now
<uvos>
but long term dsme needs to be removed from system service invokation
<Wizzup>
for me I think that if the phone app crashes in the background, the phone should really try to recover, notify, and if all else fails, maybe reboot or something
<uvos>
sure
<uvos>
pls not reboot tho
<Wizzup>
yeah, ok, but there's no point to revisit it every time :p
<Wizzup>
uvos: well if you disable the lg then it won't matter I think
<Wizzup>
(for you at least)
<uvos>
right
<Wizzup>
I managed to get an audio call going with a friend btw
<uvos>
nice
<Wizzup>
it looked like when I picked up, the vibration did not stop though
<Wizzup>
I had to manually mute the vibration
<uvos>
hmm
<uvos>
ok
<Wizzup>
(just giving feedback, you probably know)
<uvos>
no
<uvos>
worked for me :P
<Wizzup>
and audio worked when I set the profile to 'Make a phone call' in pavucontrol
<uvos>
right
<uvos>
speakerphone only tho
<Wizzup>
hm I did earpeace
<uvos>
it goes to the speakerphone
<uvos>
no matter what you select
<Wizzup>
hm, ok
<uvos>
this is the kernel problem
<uvos>
i have a hack that fixes this in my kernel
<Wizzup>
I don't know how nokia does it exactly, but I think a phone call unlocks the phone and locks it again after that
<uvos>
but its not something we should/can include
<uvos>
Wizzup: mce gets put into call mode
<Wizzup>
not quite sure how that is done securely if at all (i have no lock code set on my phone)
<Wizzup>
ok
<Wizzup>
so mce takes care of it then
<uvos>
mce takes care of ti
<uvos>
also it takes care of the proximitry screen blanking
<uvos>
sphone just dosent tell mce about the ongoing call rn
<uvos>
otherwise the mce stuff works allready
<Wizzup>
ok
<uvos>
oh right the thing with vibration not stopping makes sense
<uvos>
this is ofonos fault
<uvos>
for some reason the state of the call never changes after its initalized in ofono
<uvos>
so a outgoing call is stuck at dialing forever
<uvos>
and a incomeing call is stuck at ringing forever in ofono
<uvos>
untill the call is hungup
<uvos>
then it changes to dissconeccted
<uvos>
funny thing
<uvos>
this bug existed in 2010 on the htc device too
<uvos>
sphone src has a workaround for the outgoing part
<uvos>
i gues i never picked up since i implmented vibration
<uvos>
tmlind: regarding pm its still broken for me with the modem online
<tmlind>
uvos: ok
<uvos>
tmlind: but i have made no effort to look into it so ill report when i know more
<tmlind>
ok
<uvos>
tmlind: regarding asoc
<uvos>
tmlind: so i really still dont know what to do about the PGA
<tmlind>
ok
<uvos>
tmlind: i asked at on the alsa-devel mailing what do in this situation
<uvos>
but no replies so far
<uvos>
sre also remains mia
<tmlind>
heh ok :) so for parsing the /dev/gsmtty1 notifications..
<tmlind>
there needs to be a counter for WAKEUP initialized to 0
<tmlind>
if three WAKEUP instances are seen, alert as it means phone call or sms
<tmlind>
but
<uvos>
ok
<bencoh>
Wizzup: wait, you don't want to unlock phone during phone call?
<uvos>
bencoh: we do
<uvos>
bencoh: it dosent currently
<tmlind>
counter needs to be set back to = -1 if any outgoiong status is seen
<bencoh>
oh and iirc, nokia only unlocks phone app
<uvos>
bencoh: just inimplemented
<uvos>
bencoh: just unimplemented
<bencoh>
I don't think you can switch to other apps
<uvos>
mce unlocks the deivce (tklock at least)
<Wizzup>
bencoh: I don't know how it prevents switching, I never use a lock code on fremantle
<Wizzup>
but we'll see I guess :)
<uvos>
the nokia phone app is override redirect
<Wizzup>
ok
<uvos>
its its own lock screen
<Wizzup>
clever
<uvos>
idk if i want to do this
<uvos>
tbh
<uvos>
but later anyhow
<uvos>
i also dont know what they do if some other app holds a screen grab
<bencoh>
yeah
<uvos>
cant just not accept the call then
<uvos>
so not sure what they do.
<uvos>
in this case
<uvos>
tmlind: failing this would break pm?
<uvos>
tmlind: or what is the context here
<tmlind>
uvos: you should see +CIEV notifications on /dev/gsmtty1 for phone status changes
<uvos>
what status exactly? in call vs idle?
<uvos>
obv rn i have not dealt with gsmtty directly at all
<uvos>
since im just using ofono
<tmlind>
uvos: incoming call, incoming sms, call status changing to connected and so on
<uvos>
ok
<tmlind>
so sounds like more +CIEV notifications needs to be parsed in ofono probably
<uvos>
and this suspect the handling of this in ofono, or lack thereof relates to the pm problem or the problem that the ofono calls tate dosent change?
<uvos>
ok so call state not changeing
<tmlind>
yup
<tmlind>
and also what to do with WAKEUP events
<uvos>
ok
<uvos>
who ported ofono to motomdm?
<uvos>
or did generic qmi work?
<tmlind>
as there are also WAKEUP events for outgoing calls that need to be filtered out when a +CIEV is seen by setting counter to -1 instead of 0..
* tmlind
ducks
<uvos>
he
<uvos>
*hehe
<uvos>
ok ill look at the ofono porblems later
<uvos>
(sphone and asoc first)
<tmlind>
ok
<tmlind>
i have not had a chance to get back to ofono for a while..
<uvos>
we also have problems with gprs
<uvos>
but that might be Wizzups fault also
<uvos>
and not ofonos
<tmlind>
but we need to listen to /dev/gsmtty* in ofono for notifications, then trigger qmi notifications for usb
<Wizzup>
uvos: I use mdbus2 for gprs, not icd2, and it still fails
<parazyd>
uvos: In case you missed it, I'm pretty sure you should be using g_critical/g_warning instead of g_error in the code, because g_error does abort()
<Wizzup>
but there might be more to be done somehow, in how I use mdbus2 to talk to ofono, maybe
<uvos>
parazyd: right but the abort is on purpose rn because the failure would cause sphone to be in a state where it cant rescive calls but the user dosent know
<uvos>
id rather it exits
<uvos>
but in reality it should deal with this situation sanely ofc
<Wizzup>
sounds like you're on top of things
<tmlind>
uvos: you do have those ofono commits from the motmdm branch above, right? otherwise only limited qmi usb functionality will work
<tmlind>
uvos: i recall pavel's usb tty changes got merged but that interface is limited and buggy
<uvos>
tmlind: i have whatever leste has in its repos
<uvos>
tmlind: i gues Wizzup or parazyd knows
<Wizzup>
I'm pretty sure we're using the latest from tmlind