Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Correct handling of multimedia keypresses #2039

Merged
merged 1 commit into from

4 participants

@jhsrennie
Collaborator

http://trac.xbmc.org/ticket/13585 reports that on some laptops multimedia keypresses are having unintended affects. This is because on some keyboards (it isn't clear exactly which) the multimedia keys send scan codes used by different keys e.g. the mute key sends the same scancode as the "d" key. This means that (on Windows) XBMC sees the WM_APPCOMMAND message from the mute key, but then a rogue "d" keypress as well. This has started mattering since new key mappings were added to support the PVR functions.

This commit is a quick fix that stops XBMC processing the scan code for multimedia keys. This should do for Frodo, though in the longer term we need to look at exactly what scancode processing is required as it isn't clear why the current code is needed.

@jmarshallnz
Owner

So all these keys are handled in WM_APPCOMMAND already? i.e. this can't break anything?

@Voyager1
Collaborator

I confirm that on one of my PCs I had the "back" button handled twice! once for the scan code, once for the WM_APPCOMMAND. I had to turn off multimedia key handling by setting false so it only hits once.

@jhsrennie
Collaborator

In Windows (God bless you Bill Gates) pressing a multimedia key generates two messages. First it generates a WM_APPCOMMAND message, then it generates a WM_KEYDOWN message. By default XBMC handles the WM_APPCOMMAMD but ignores any WM_KEYDOWN messages from multimedia keys (obviously, only from multimedia keys), and this prevents the keypress being handled twice. You can change this behaviour from http://wiki.xbmc.org/?title=Advancedsettings.xml#.3Cenablemultimediakeys.3E, which is presumably why Voyager1 experienced the duplicated key presses.

However the current problem is unrelated. It's happening because XBMC misinterprets the multimedia keypresses so they look like other keypresses e.g. the mute key looks like a "d" keypress. This fix prevents this mishandling of the keypresses.

FWIW http://forum.xbmc.org/showthread.php?tid=148760&pid=1290606#pid1290606 reports that the fix works.

I guess it's a bit scary putting a change like this in at the RC3 stage, but I'm 99% confident it won't affect anything else. It's difficult to be 100% sure as the problem only occurred on some keybpoards and doesn't happen on mine, or with any of the remotes I use.

@jmarshallnz
Owner

Sounds fine to me then.

@jmarshallnz jmarshallnz merged commit 0c66b4a into xbmc:master
@jhsrennie
Collaborator

Are you going to pull the changes into the Frodo branch as well?

@jmarshallnz
Owner

davilla handles that - see the frodo final thread on the forums.

@davilla

yes, list it and it will get merged into frodo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Jan 7, 2013
  1. Correct handling of multimedia key presses

    John Rennie authored
This page is out of date. Refresh to see the latest.
Showing with 19 additions and 0 deletions.
  1. +19 −0 xbmc/windowing/windows/WinEventsWin32.cpp
View
19 xbmc/windowing/windows/WinEventsWin32.cpp
@@ -261,6 +261,25 @@ static int XBMC_MapVirtualKey(int scancode, int vkey)
case VK_RMENU:
case VK_SNAPSHOT:
case VK_PAUSE:
+ /* Multimedia keys are already handled */
+ case VK_BROWSER_BACK:
+ case VK_BROWSER_FORWARD:
+ case VK_BROWSER_REFRESH:
+ case VK_BROWSER_STOP:
+ case VK_BROWSER_SEARCH:
+ case VK_BROWSER_FAVORITES:
+ case VK_BROWSER_HOME:
+ case VK_VOLUME_MUTE:
+ case VK_VOLUME_DOWN:
+ case VK_VOLUME_UP:
+ case VK_MEDIA_NEXT_TRACK:
+ case VK_MEDIA_PREV_TRACK:
+ case VK_MEDIA_STOP:
+ case VK_MEDIA_PLAY_PAUSE:
+ case VK_LAUNCH_MAIL:
+ case VK_LAUNCH_MEDIA_SELECT:
+ case VK_LAUNCH_APP1:
+ case VK_LAUNCH_APP2:
return vkey;
}
switch(mvke)
Something went wrong with that request. Please try again.