Wifi Calling Breaks when proximity sensor turns screen off during call (1.35)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Have phone unplugged and not charging
2. Turn on wifi and wifi calling
3. Place call and hold phone away from face so screen stays on
4. Audio plays just fine and call can continue
5. Place phone near hand or face to trigger proximity sensor, screen turns off 
and call quickly degrades and drops.  Pull phone away before the call drops, 
screen turns back on and all continues working.

What is the expected output? What do you see instead?
Call to continue - instead it says Signal Dropped. Wifi signal lost. Signal 
bars show complete loss of connectivity if left with the screen off long 
enough.  

What version of the product are you using? On what operating system?
Bricked 1.35 on ViperSs 1.0.0 (Sense 4)

Please provide any additional information below.
This can also be duplicated by just pressing the power button to turn the phone 
off during a call.  I've tried multiple radios, older radios, different RILs, 
different Wifi Calling APK and I cannot make the problem go away.  Makes me 
think it might be a kernel issue but I'm not a kernel expert ;-)

Original issue reported on code.google.com by brh...@gmail.com on 3 Jul 2012 at 5:03

[GoogleCodeExporter]

did you try it with a different kernel?
This could be rom side, since wifi calling inside the kernel hasn't changed 
since version 0.1.
Also try to attach a log as I don't have any wifi calling here.

Original comment by showp1984 on 3 Jul 2012 at 7:01

[GoogleCodeExporter]

I tried the Radio recommended for the ROM, I tried going back to the t-mobile 
radio I was using (11.69A.3504.00U_11.23.3504.07_M2), I tried various RILs, I 
tried checking the build.prop and comparing it to known working roms, I tried 
changing the Wifi calling apk out with a different one known to work as well, 
and also tried the 1.36 kernel.  None of those worked.

I also tried the 1.31 kernel on this ROM but it just boot looped and wouldn't 
restart.

I'll try to see if I can get a log but I'm not sure if I can force it because 
when its connected via USB it doesn't do it because its charging.  When its 
plugged into any sort of power source it doesn't do it.

I'm fairly certain that the issue is specific to the way the Wifi is behaving 
when it goes to "sleep".  If it was the wifi calling specifically I think it 
would just drop immediately but its more like its a severely degraded signal.  
It appears to be trying to maintain the call but it eventually gives up and 
drops.  Once it drops and I look at the phone the wifi is completely dead.

1.35+ has a different wifi driver or something doesn't it?  I was wondering if 
that maybe has something to do with it.  I have a lot of linux experience and 
know the linux kernel and stuff, but not when it comes to phones ;-)

Thanks for your work! :-)

Original comment by brh...@gmail.com on 3 Jul 2012 at 7:10

[GoogleCodeExporter]

also, if you need a tester to help I'm willing to try...

Original comment by brh...@gmail.com on 3 Jul 2012 at 7:10

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

it could need wifi PM = Fast. I can check that later and upload a test here.

Original comment by showp1984 on 3 Jul 2012 at 7:13

• Added labels: Version-1.35, Android-ICS, Device-pyramid, branch-Sense, Usability

[GoogleCodeExporter]

Is this not implemented in 1.35/1.36?  I think there is a good chance this 
might fix it.  Doing some reading about this and I do see other wifi calling 
discussions where this was part of the fix though they aren't on the sensation.

Thanks!

Original comment by brh...@gmail.com on 3 Jul 2012 at 7:47

[GoogleCodeExporter]

well the new driver apparently does not have this hack :)
I will look into it later :)

Original comment by showp1984 on 3 Jul 2012 at 7:57

[GoogleCodeExporter]

This was definitely the problem.  I downloaded your source from git and gave it 
a shot.  I'm sure you're already familiar with this but just in case I can be 
helpful...

I modified drivers/net/wireless/bcmdhd/dhd_linux.c and commented out lines 753 
through 755 effectively disabling the PM_MAX lines in there.  This should be 
able to be inserted into your 1.36 kernel if it helps save you time towards 
your next release.  I inserted the module into the running 1.36 kernel on my 
phone and it fixed the wifi calling issue.

Original comment by brh...@gmail.com on 4 Jul 2012 at 2:44

Attachments:

• dhd_linux.c

[GoogleCodeExporter]

Just updated to the newest version of their ROM that included the 1.36 kernel.  
Wifi calling seems to work.  I noticed after the update that (obviously) the 
module I had compiled and inserted was replaced with the original one again as 
the MD5 matched the original, not mine.  Apparently there was more than one way 
to fix it so I'm curious what the other way was since the module was unchanged 
in the new version - do you know?

Original comment by brh...@gmail.com on 6 Jul 2012 at 5:07

[GoogleCodeExporter]

Well I didn't to anything :P
1.36 and 1.35 have the same drivers. :)

Original comment by showp1984 on 6 Jul 2012 at 5:58

• Changed state: Accepted

[GoogleCodeExporter]

That's funny, because in their first version, I modified the code, recompiled 
the bcmdhd.ko module only and inserted it and it fixed the issues.  I'm 100% 
sure that it made using the modified one vs. the original.  So something they 
changed must have also fixed it.  I know their changelog mentioned skype and 
talk fixes so I wonder if whatever they did also applied to wifi calling.  I 
guess you can just ignore this issue then all together it appears.  If I notice 
it come up again using your kernel I'll let you know but I know the kernel that 
is in place and in use now is the original one and not my modified one and its 
working.

Thanks!

Original comment by brh...@gmail.com on 6 Jul 2012 at 6:07

[GoogleCodeExporter]

Ok, as you suggested: #ignoring this now :p

Original comment by showp1984 on 17 Jul 2012 at 10:57

• Changed state: Done