We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 3247

Summary: Media/special keys incorrectly processed on Windows
Product: SDL Reporter: Matthew Turner <msturner>
Component: eventsAssignee: Sam Lantinga <slouken>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: major    
Priority: P2 CC: michael
Version: 2.0.4   
Hardware: x86_64   
OS: Windows 7   
Attachments: patch to prefer virtual keycodes over scancodes for extended keys

Description Matthew Turner 2016-01-26 06:34:14 UTC 
This behavior was observed in the latest stable release: 2.0.4 on Windows.

I am running on a Dell XPS L702X laptop. The keyboard for this laptop has a special "Fn" key, which when used in combination with the normal function keys, performs special system functions:

Fn+F4  - Decrease display brightness
Fn+F5  - Increase display brightness
Fn+F11 - Decrease audio volume
Fn+F12 - Increase audio volume

It appears that SDL is incorrectly mapping Fn key presses. For example, when I press Fn+F11 to decrease the volume, I get a key down message for the 'C' key.

I have tracked down the source of the bug to WindowsScanCodeToSDLScanCode() in SDL_windowevents.c

This function is responsible for mapping Windows keyboard messages to SDL key codes. However, the current logic places priority on scan codes before virtual key codes, which is the source of the malfunction.

In my own testing, I have observed the following:

Key:               'C'
Virtual key code:  67 (VK_C)
Scan code:         46
Extended key flag: 0

Key:               Fn + F11
Virtual key code:  174 (VK_VOLUME_DOWN)
Scan code:         46
Extended key flag: 1

As you can see, both 'C' and Fn+F11 have the same scan code (46), but the extended key flag is different, and they have different virtual key codes.

I suggest that WindowsScanCodeToSDLScanCode() be modified to prioritize virtual key codes before scan codes to ensure that extended keys are processed correctly. I see that there is already a special case handler for scan code 0x45, but I suggest this is not a suitable general solution.
Comment 1 ouned 2017-06-03 07:32:24 UTC 
Created attachment 2748 [details]
patch to prefer virtual keycodes over scancodes for extended keys

We got a bug report at our project with exactly the same issue:
https://github.com/mvdevs/jk2mv/issues/92

I came to the exact same solution just to find this bugreport afterwards :)

This patch pretty much does what Matthew Turner suggested.

I hope that the patchfile works, it's the first time I used mercurial.
Comment 2 Sam Lantinga 2017-08-12 19:57:16 UTC 
Fixed, thanks!
https://hg.libsdl.org/SDL/rev/33802c660fa0