diff options
author | Hans de Goede <hdegoede@redhat.com> | 2020-06-20 14:32:29 +0200 |
---|---|---|
committer | Jiri Kosina <jkosina@suse.cz> | 2020-06-24 09:49:04 +0200 |
commit | a5d81646fa294eed57786a9310b06ca48902adf8 (patch) | |
tree | 1e41810b75896563462527fe82ed6351c2fb7484 /drivers/hid/hid-ids.h | |
parent | a06bb885cf3d812ebfd45c6300e503690a762955 (diff) | |
download | lwn-a5d81646fa294eed57786a9310b06ca48902adf8.tar.gz lwn-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 'drivers/hid/hid-ids.h')
0 files changed, 0 insertions, 0 deletions