summaryrefslogtreecommitdiffstats
path: root/osdep/w32_keyboard.c
Commit message (Collapse)AuthorAgeFilesLines
* w32_common: handle media keysJames Ross-Gowan2017-08-051-0/+20
| | | | | | | | | | | | | | | | | This was attempted before in fc9695e63b5b, but it was reverted in 1b7ce759b1f4 because it caused conflicts with other software watching the same keys (See #2041.) It seems like some PCs ship with OEM software that watches the volume keys without consuming key events and this causes them to be handled twice, once by mpv and once by the other software. In order to prevent conflicts like this, use the WM_APPCOMMAND message to handle media keys. Returning TRUE from the WM_APPCOMMAND handler should indicate to the operating system that we consumed the key event and it should not be propogated to the shell. Also, we now only listen for keys that are directly related to multimedia playback (eg. the APPCOMMAND_MEDIA_* keys.) Keys like APPCOMMAND_VOLUME_* are ignored, so they can be handled by the shell, or by other mixer software.
* w32_common, w32_keyboard: change license to LGPLwm42017-06-241-7/+7
| | | | All authors agreed.
* Revert "win32: add mappings for some special keys"wm42015-06-241-9/+0
| | | | | | | This reverts commit fc9695e63b5baa1a478acb8e79c038571ee0e9b3. Users were complaining that both mpv and something else (what? I don't know) respond to some multimedia keys, such as volume change.
* win32: add mappings for some special keyswm42015-05-121-0/+9
| | | | Untested.
* w32: use the w32_common keymap in terminal-win tooJames Ross-Gowan2014-01-191-0/+91