Too many volume button presses causes problems

[Tony Espy]

On the Jax10 device, hitting the volume buttons too quickly causes problems. The volume dialog ( speaker icon + graph ) never gets dismissed, and the sound stutters continuously.

This occurred using our release candidate for our Beta1.5 build.

To recreate, open the mid-browser, goto the site: www.zappa.com, wait till the music starts, then start clicking the volume up / down buttons in rapid succession.

I can get things to freeze up with only a few clicks up / down in volume.

[Tony Espy (awe)]

Marking critical as this bug locks up the system pretty bad...

[Tony Espy (awe)]

At one point I managed to get this so hung up that when I closed the browser, a small square the size of the volume dialog was still displaying an image from the browser overlayed on the desktop.

[May Xie (may-xie)]

Todd, assign to m11. Are you working on this bug?

[ToddBrandt (todd-e-brandt)]

Yea, I'm looking at it now.

[ToddBrandt (todd-e-brandt)]

Question:

How do you map the volume keys to the volume? By default the buttons applet has the XF86AudioRaiseVolume and XF86AudioLowerVolume keys mapped to up and down, however they can be changed to whatever.

I've tried pressing the keys as fast as I can here and I see no issues. Can you try remapping the volume keys to some other buttons (like ctrl-u and ctrl-d) and seeing if you can reproduce the issue in the same manner? I need to know if there's something endemic to the keys you used that cause problems with software.

[ToddBrandt (todd-e-brandt)]

To be clear, this is my understanding of the problem and my attempted fix:

Background: Moblin-settings-daemon is a daemon that runs in the background capturing and initiating keyboard shortcut events, monitoring gconf changes for propogation of theme switches, etc; basically handling all the settings for moblin. For shortcuts, It registers a gdk window filter callback (via gdk_window_add_filter) which gets called whenever there’s a button press on the device. When called, it checks its list of known shortcuts to see if the keycode or combination is mapped to some action; if it isn’t, it returns GDK_FILTER_CONTINUE which lets the caller know that the keypress should propogate onward to xorg for further processing. If it’s a shortcut, it carries out the action and returns GDK_FILTER_REMOVE, which tells the caller that the keypress has been handled and doesn’t need to be propogated any further.

Possible root cause: Now I don’t know for sure since I can’t reproduce this bug on a samsung Q1, but I assume the problem is that when keypress data comes in too fast it can sometimes collide with a previous keypress that isn’t done being processed. This is most probable if the shortcut action takes some time, which in the case of a volume change it would (it has to generate a request and send it through ALSA to the driver, then the driver has to propogate it to hardware, etc).

Attempted fix in moblin-applets 0.62: So what I did is add a simple check when a new keypress is received. If the keypress is a valid shortcut and the daemon isn’t yet finished processing an existing shortcut, the filter immediately returns GDK_FILTER_REMOVE which should effectively nullify the keypress altogether. I’d rather do that than queue them up with a set of semaphores since keypresses coming in that fast are likely all the same anyway.

0.62 moblin-applets should be available on the PPA in about 45 minutes.

[ToddBrandt (todd-e-brandt)]

Attempted fix in moblin-applets 0.62

[Adrian_Hung (adrian-hung)]

Thank you for your great supprot, but may I ask where is PPA site? http://mobilepartners.canonical.com/ubuntu-ports-stable/ or http://mobilepartners.canonical.com/ubuntu-stable/ ? I didn't find moblin-applets 0.62 source files there, where can I download it? Thanks a lot!

[cathyli (cathy-li)]

You can update moblin-applets in this way:
$apt-get update
$apt-get install moblin-applets
$dpkg -l |grep moblin-applets #you will find the applets version change to 0.62.

[cathyli (cathy-li)]

Verified in moblin-applets 0.62, don't met the issue in Q1 and CB, close it.

[cathyli (cathy-li)]

Don't met the issue in Q1 and CB. I cannot reproduce it, not sure if the bug is fixed indeed. It's better for the bug reporter to verify it.
Change status back to Fix Committed.

[cathyli (cathy-li)]

Tony Espy, could you please verify if the issue is fixed in latest moblin-applets?

[Tony Espy (awe)]

I have not been able to reproduce this bug since first reporting it. I discussed with Todd and we both agreed that this issue can now be closed, especially given the fact that Todd added code to handle what he thinks may have been the problem.

[cathyli (cathy-li)]

If that, close the issue.

[Bill Filler (bfiller)]

I found with this fix, you can no longer press and hold the volume key to adjust the volume. You have to keep pressing/releasing to adjust the volume, which is not good for the user. I rolled back Todd's fix to moblin-settings-multimedia-keys.c in our version and everything seems ok. I can't reproduce the problem Tony first reported.

[Bill Filler (bfiller)]

marking this invalid. Cannot reproduce the scenario.

[Tony Espy (awe)]

hmmm... not sure i'd have done that. if it breaks again, it's all yours! ;)-

[Bill Filler (bfiller)]

the fix was incorrect and caused bad side effects, so I don't see the harm in removing it. If the problem re-occurs it needs to be solved in a different way that doesn't prevent press and hold of the volume key.