Attend XDA's Second Annual Developer Conference, XDA:DevCon 2014!
5,732,778 Members 52,030 Now Online
XDA Developers Android and Mobile Development Forum
View Poll Results: Do you have an issue with Galaxy Nexus volume changing automatically?
Yes, my phone suffers from volume problems 209 54.43%
No, I haven't experienced the volume problem 141 36.72%
I did not have it at first, but it does happen now 17 4.43%
I had the problem before, but not anymore 17 4.43%
Voters: 384. You may not vote on this poll

Do you have an issue with Galaxy Nexus volume changing automatically? (Updated 01.12)

Tip us?
 
appelflap
Old
#1001  
appelflap's Avatar
Recognized Developer
Thanks Meter 797
Posts: 4,084
Join Date: Feb 2008
Location: Utrecht
Quote:
Originally Posted by kristovaher View Post
They did not say it is not hardware related! You are putting words in their mouth. It is hardware related. What they are saying is that they will release a software fix that will likely mask the problem from the worst thing it does, cause volume drops.
I think the whole hardware / software related discussion is obsolete. The boundary isn't that clear cut. With new technologies software can't be set up to listen to a exactly defined subset of hardware. The relation is probably more "coherentistic" and not "foundationalistic". Its a many to many relation that needs to be coherent. Classical deductive logic can't be used anymore for these complex systems. So if the fix is hardware related or software related isn't important. Important is that the whole system functions coherently.
 
coolbho3000
Old
(Last edited by coolbho3000; 23rd November 2011 at 09:35 AM.)
#1002  
Senior Recognized Developer
Thanks Meter 758
Posts: 886
Join Date: Dec 2008
Okay, let me step in again and say that the people who are saying "bull**** on software fix" either don't know what they're talking about or aren't thinking hard enough. From what I understand, this problem is entirely fixable at either the kernel level or the firmware level. I posted that I would attempt a fix today when I get my Galaxy Nexus, but it looks like Google already has it handled.

To me, this seems like hardware issue that can be compensated for completely in software.

I don't have my Galaxy Nexus yet, but from what I gather from logs posted earlier as well as this video: http://www.youtube.com/watch?v=Rp-N352hwZY, the issue is that 900MHz interference makes the volume down button oscillate between on and off so quickly that it overflows the buffer for the keypad device. This is the key here. Such a thing would NEVER happen in normal usage - there's no way a human could possibly press the button quickly enough.

From the video, we can see that when the bug happens, the volume pretty much immediately jumps from maximum to minimum. We all know that if you hold the volume down button in Android, it doesn't decrease nearly that quickly (it lowers one level immediately and then gradually lowers the volume for as long as the button is held). So a 900MHz signal does not hold down the button. It just presses it (and releases it) really, really quickly.

The 900MHz signal never seems to hold the button for longer than tiny fractions of a second. A human wanting to change the volume would always hold the button down for at least many times that rate. So now we know the difference between the 900MHz signal and a human pressing the button - the 900MHz signal never holds the button for any significant period of time.

So how do we fix it? See source file: https://www.codeaurora.org/gitweb/qu...p-tuna-3.0-mr0

Pressing the button or releasing the button causes a hardware interrupt which calls omap4_keypad_interrupt(). An example fix (there's probably a better/more low level way to do this - this would just be a quick fix): All we'd have to do is add the following logic to omap4_keypad_interrupt():

- If we get an interrupt for volume down pressed, do not register it yet.
- In 100 milliseconds, volume down is still pressed, register the key press. If not, ignore it.
- If we got another interrupt for volume down in the meantime (volume down pressed or volume down released), ignore it even if it's pressed.

This would, more likely than not, fix the issue, or mitigate it so much that the interference becomes negligible.

Yes, it's a workaround, but workarounds like this happen all the time. Hardware is limited by the laws of physics, but that doesn't mean software can't compensate for it. The procedure is very similar to "debouncing." See: http://en.wikipedia.org/wiki/Debounce#Contact_bounce. This wouldn't fix the issue in the bootloader - you would need to have the above logic implemented in the keypad driver there, or just fix it in firmware.

DO NOT return your phones yet. There is no reason not to believe Google. I'll still look into writing a proof of concept fix, but as it stands, I live in the US where I can't easily get a 900MHz GSM signal (and I don't have easy access to baby monitors/portable radios or 900MHz cordless telephones).
Galaxy Nexus (GSM)
Control your Android phone's CPU! SetCPU for Root Users
Follow me on Twitter!

Like my work? Buy SetCPU on the market or buy me some [insert drink here].
The Following 3 Users Say Thank You to coolbho3000 For This Useful Post: [ Click to Expand ]
 
davej777
Old
#1003  
Junior Member
Thanks Meter 4
Posts: 13
Join Date: Nov 2009
Quote:
Originally Posted by kristovaher View Post
What they are saying is that they will release a software fix that will likely mask the problem from the worst thing it does, cause volume drops.
Unfortunately, there aren't really any good software fixes for this.

You can try and filter the button presses - you could then end up with situations where you hit the button quickly and it thinks it is just interference, or where the interference just happens to closely imitate a real button press and the volume goes down. Either way, the constant interrupts may prevent the phone from correctly sleeping and could cause poor battery life.

The alternative is to completely disable the input pins, resulting in dead volume buttons. No battery life issues, but you would need to use a widget or app to change the volume.

A hardware fix could be as simple as changing (or installing) a resistor or capacitor. Unfortunately, any hardware changes could take quite some time (and be a massive inconvenience).

So who would prefer possibly-temperamental volume buttons over non-functional volume buttons?
 
pienut
Old
#1004  
Junior Member
Thanks Meter 2
Posts: 24
Join Date: Jan 2009
I ordered from Handtec...
I am afraid though to allow them to ship my phone since my provider in Belgium (Proximus) uses 900Mhz for 2G and also has 900Mhz (+1800Mhz) on 3G ...

I'm afraid I would be properly f*cked because of the 900mhz usage on 3G networks as well here :)

And I'm also a little skeptical about a software fix for this issue...
Unless it could be fixed firmware/radio wise...
I'm no Samsung Engineer, can't conclude how they (or Google) messed up and are going to solve it :)

Seeing Samsung & Google are 2 big companies (A company's primary goal is to make profit), they will just "patch" up things and hope everybody will remain silent about this "feature" afterwards.
 
StuMcBill
Old
#1005  
StuMcBill's Avatar
Senior Member
Thanks Meter 91
Posts: 1,636
Join Date: Feb 2010
Correct me if I am wrong, but once this fix has been applied, we will still be able to look at the logs to see if the "ghost" button presses are being registered by the device, but just being ignored unless the rocker is held down for +/- 100ms as a coolbho3000 said?
HTC One M8 : ARHD 8.1
Asus Nexus 7 (2013) - 32Gb : ParanoidAndroid & Stock 4.4.2 using MultiRom
 
davej777
Old
#1006  
Junior Member
Thanks Meter 4
Posts: 13
Join Date: Nov 2009
Quote:
Originally Posted by coolbho3000 View Post
- If we get an interrupt for volume down pressed, do not register it yet.
- In 100 milliseconds, volume down is still pressed, register the key press. If not, ignore it. If we got another interrupt for volume up pressed in the meantime, ignore it even if it's pressed.
This sounds a lot like software debouncing.

The problem is that the button is not bouncing - a "bouncing" button eventually enters a steady state (usually within 20ms). The interference in this case is continuous - it can happen continuously for several seconds. 100ms is not long enough - it is entirely possible that the button will randomly happen to be "down" at this instant.
 
coolbho3000
Old
(Last edited by coolbho3000; 23rd November 2011 at 09:47 AM.)
#1007  
Senior Recognized Developer
Thanks Meter 758
Posts: 886
Join Date: Dec 2008
Quote:
Originally Posted by StuMcBill View Post
Correct me if I am wrong, but once this fix has been applied, we will still be able to look at the logs to see if the "ghost" button presses are being registered by the device, but just being ignored unless the rocker is held down for +/- 100ms as a coolbho3000 said?
If you fix it on the lowest level possible in the kernel and do it efficiently, nothing should log to logcat, and there should be just the tiniest minimal performance impact. If you fix it on the firmware level, it would be completely transparent to the user.


Quote:
Originally Posted by davej777 View Post
This sounds a lot like software debouncing.

The problem is that the button is not bouncing - a "bouncing" button eventually enters a steady state (usually within 20ms). The interference in this case is continuous - it can happen continuously for several seconds. 100ms is not long enough - it is entirely possible that the button will randomly happen to be "down" at this instant.
I mention that. It's very similar to software debouncing.

But... We listen for the volume down released interrupt, too. The on/off oscillations seem to be happening at a much greater frequency than 10Hz.

If we get a volume down pressed interrupt and 100 milliseconds later the volume down button is still held, then register it BUT if we get a volume down released interrupt in the meantime, then we know it's from interference. Yes, it could be held at both instants and happen to randomly be down 100ms later - but if there was no volume down released interrupt between our two measurements, then we are sure the button was held down between them.
Galaxy Nexus (GSM)
Control your Android phone's CPU! SetCPU for Root Users
Follow me on Twitter!

Like my work? Buy SetCPU on the market or buy me some [insert drink here].
The Following User Says Thank You to coolbho3000 For This Useful Post: [ Click to Expand ]
 
Alexander T.
Old
#1008  
Member
Thanks Meter 98
Posts: 76
Join Date: Dec 2010
Quote:
Originally Posted by Luxferro View Post
Maybe a pin is floating and can be set with a register to an internal pullup, ect.
Yes, that's exactly what I was thinking over. Samsung engineers might have just accidentally misconfigured the port parameters, e.g. forgotten the pullups.
 
sethyx
Old
#1009  
Member
Thanks Meter 186
Posts: 86
Join Date: Nov 2011
Location: Budapest

 
DONATE TO ME
Quote:
Originally Posted by coolbho3000 View Post
- If we get an interrupt for volume down pressed, do not register it yet.
- In 100 milliseconds, volume down is still pressed, register the key press. If not, ignore it.
- If we got another interrupt for volume down in the meantime (volume down pressed or volume down released), ignore it even if it's pressed.
What if the user presses the button "in the meantime"?
How can the driver detect a user-press, when it is bouncing because of the RF interference?
 
coolbho3000
Old
(Last edited by coolbho3000; 23rd November 2011 at 09:53 AM.)
#1010  
Senior Recognized Developer
Thanks Meter 758
Posts: 886
Join Date: Dec 2008
Quote:
Originally Posted by sethyx View Post
What if the user presses the button "in the meantime"?
How can the driver detect a user-press, when it is bouncing because of the RF interference?
Every time we get a volume down pressed interrupt, we repeat this process. So if the user presses the volume down switch in the meantime, we ignore the original volume down pressed signal, and start calculating from the last volume down pressed signal (actuated by the user).

But, you say, wouldn't we continue to get interrupts from interference as the 900MHz signal continues while the user is holding the button? I don't think so.

When the volume down button is held by the user, the switch is constantly at an "on" position and interference cannot change that (rapidly inducting an "on" signal in a switch when it's already on results in the switch continuing to be on), so we get no further interrupts in the kernel other than the original pressed and released interrupts. If this interval is >= 100ms, then we register the keypress because we assume it's from the user (the signal doesn't seem to be capable of holding down the switch for that long). Otherwise, we do not.
Galaxy Nexus (GSM)
Control your Android phone's CPU! SetCPU for Root Users
Follow me on Twitter!

Like my work? Buy SetCPU on the market or buy me some [insert drink here].

The Following User Says Thank You to coolbho3000 For This Useful Post: [ Click to Expand ]
Tags
bug, galaxy, nexus, volume
THREAD CLOSED
Subscribe
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes