summaryrefslogtreecommitdiffstats
path: root/ipc
diff options
context:
space:
mode:
authorHans de Goede <hdegoede@redhat.com>2020-06-20 14:32:29 +0200
committerJiri Kosina <jkosina@suse.cz>2020-06-24 09:49:04 +0200
commita5d81646fa294eed57786a9310b06ca48902adf8 (patch)
tree1e41810b75896563462527fe82ed6351c2fb7484 /ipc
parenta06bb885cf3d812ebfd45c6300e503690a762955 (diff)
downloadlinux-stable-a5d81646fa294eed57786a9310b06ca48902adf8.tar.gz
linux-stable-a5d81646fa294eed57786a9310b06ca48902adf8.tar.bz2
linux-stable-a5d81646fa294eed57786a9310b06ca48902adf8.zip
HID: apple: Disable Fn-key key-re-mapping on clone keyboards
The Maxxter KB-BT-001 Bluetooth keyboard, which looks somewhat like the Apple Wireless Keyboard, is using the vendor and product IDs (05AC:0239) of the Apple Wireless Keyboard (2009 ANSI version) <sigh>. But its F1 - F10 keys are marked as sending F1 - F10, not the special functions hid-apple.c maps them too; and since its descriptors do not contain the HID_UP_CUSTOM | 0x0003 usage apple-hid looks for for the Fn-key, apple_setup_input() never gets called, so F1 - F6 are mapped to key-codes which have not been set in the keybit array causing them to not send any events at all. The lack of a usage code matching the Fn key in the clone is actually useful as this allows solving this problem in a generic way. This commits adds a fn_found flag and it adds a input_configured callback which checks if this flag is set once all usages have been mapped. If it is not set, then assume this is a clone and clear the quirks bitmap so that the hid-apple code does not add any special handling to this keyboard. This fixes F1 - F6 not sending anything at all and F7 - F12 sending the wrong codes on the Maxxter KB-BT-001 Bluetooth keyboard and on similar clones. Cc: Joao Moreno <mail@joaomoreno.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Diffstat (limited to 'ipc')
0 files changed, 0 insertions, 0 deletions