--- /dev/null
+From 8e7b341037db1835ee6eea64663013cbfcf33575 Mon Sep 17 00:00:00 2001
+From: Jiri Kosina <jkosina@suse.cz>
+Date: Tue, 6 Jan 2015 22:34:19 +0100
+Subject: HID: fixup the conflicting keyboard mappings quirk
+
+From: Jiri Kosina <jkosina@suse.cz>
+
+commit 8e7b341037db1835ee6eea64663013cbfcf33575 upstream.
+
+The ignore check that got added in 6ce901eb61 ("HID: input: fix confusion
+on conflicting mappings") needs to properly check for VARIABLE reports
+as well (ARRAY reports should be ignored), otherwise legitimate keyboards
+might break.
+
+Fixes: 6ce901eb61 ("HID: input: fix confusion on conflicting mappings")
+Reported-by: Fredrik Hallenberg <megahallon@gmail.com>
+Reported-by: David Herrmann <dh.herrmann@gmail.com>
+Signed-off-by: Jiri Kosina <jkosina@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hid/hid-input.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/hid/hid-input.c
++++ b/drivers/hid/hid-input.c
+@@ -1078,6 +1078,7 @@ void hidinput_hid_event(struct hid_devic
+ */
+ if (!(field->flags & (HID_MAIN_ITEM_RELATIVE |
+ HID_MAIN_ITEM_BUFFERED_BYTE)) &&
++ (field->flags & HID_MAIN_ITEM_VARIABLE) &&
+ usage->usage_index < field->maxusage &&
+ value == field->value[usage->usage_index])
+ return;
--- /dev/null
+From 6ce901eb61aa30ba8565c62049ee80c90728ef14 Mon Sep 17 00:00:00 2001
+From: David Herrmann <dh.herrmann@gmail.com>
+Date: Mon, 29 Dec 2014 15:21:26 +0100
+Subject: HID: input: fix confusion on conflicting mappings
+
+From: David Herrmann <dh.herrmann@gmail.com>
+
+commit 6ce901eb61aa30ba8565c62049ee80c90728ef14 upstream.
+
+On an PC-101/103/104 keyboard (American layout) the 'Enter' key and its
+neighbours look like this:
+
+ +---+ +---+ +-------+
+ | 1 | | 2 | | 5 |
+ +---+ +---+ +-------+
+ +---+ +-----------+
+ | 3 | | 4 |
+ +---+ +-----------+
+
+On a PC-102/105 keyboard (European layout) it looks like this:
+
+ +---+ +---+ +-------+
+ | 1 | | 2 | | |
+ +---+ +---+ +-+ 4 |
+ +---+ +---+ | |
+ | 3 | | 5 | | |
+ +---+ +---+ +-----+
+
+(Note that the number of keys is the same, but key '5' is moved down and
+ the shape of key '4' is changed. Keys '1' to '3' are exactly the same.)
+
+The keys 1-4 report the same scan-code in HID in both layouts, even though
+the keysym they produce is usually different depending on the XKB-keymap
+used by user-space.
+However, key '5' (US 'backslash'/'pipe') reports 0x31 for the upper layout
+and 0x32 for the lower layout, as defined by the HID spec. This is highly
+confusing as the linux-input API uses a single keycode for both.
+
+So far, this was never a problem as there never has been a keyboard with
+both of those keys present at the same time. It would have to look
+something like this:
+
+ +---+ +---+ +-------+
+ | 1 | | 2 | | x31 |
+ +---+ +---+ +-------+
+ +---+ +---+ +-----+
+ | 3 | |x32| | 4 |
+ +---+ +---+ +-----+
+
+HID can represent such a keyboard, but the linux-input API cannot.
+Furthermore, any user-space mapping would be confused by this and,
+luckily, no-one ever produced such hardware.
+
+Now, the HID input layer fixed this mess by mapping both 0x31 and 0x32 to
+the same keycode (KEY_BACKSLASH==0x2b). As only one of both physical keys
+is present on a hardware, this works just fine.
+
+Lets introduce hardware-vendors into this:
+------------------------------------------
+
+Unfortunately, it seems way to expensive to produce a different device for
+American and European layouts. Therefore, hardware-vendors put both keys,
+(0x31 and 0x32) on the same keyboard, but only one of them is hooked up
+to the physical button, the other one is 'dead'.
+This means, they can use the same hardware, with a different button-layout
+and automatically produce the correct HID events for American *and*
+European layouts. This is unproblematic for normal keyboards, as the
+'dead' key will never report any KEY-DOWN events. But RollOver keyboards
+send the whole matrix on each key-event, allowing n-key roll-over mode.
+This means, we get a 0x31 and 0x32 event on each key-press. One of them
+will always be 0, the other reports the real state. As we map both to the
+same keycode, we will get spurious key-events, even though the real
+key-state never changed.
+
+The easiest way would be to blacklist 'dead' keys and never handle those.
+We could simply read the 'country' tag of USB devices and blacklist either
+key according to the layout. But... hardware vendors... want the same
+device for all countries and thus many of them set 'country' to 0 for all
+devices. Meh..
+
+So we have to deal with this properly. As we cannot know which of the keys
+is 'dead', we either need a heuristic and track those keys, or we simply
+make use of our value-tracking for HID fields. We simply ignore HID events
+for absolute data if the data didn't change. As HID tracks events on the
+HID level, we haven't done the keycode translation, yet. Therefore, the
+'dead' key is tracked independently of the real key, therefore, any events
+on it will be ignored.
+
+This patch simply discards any HID events for absolute data if it didn't
+change compared to the last report. We need to ignore relative and
+buffered-byte reports for obvious reasons. But those cannot be affected by
+this bug, so we're fine.
+
+Preferably, we'd do this filtering on the HID-core level. But this might
+break a lot of custom drivers, if they do not follow the HID specs.
+Therefore, we do this late in hid-input just before we inject it into the
+input layer (which does the exact same filtering, but on the keycode
+level).
+
+If this turns out to break some devices, we might have to limit filtering
+to EV_KEY events. But lets try to do the Right Thing first, and properly
+filter any absolute data that didn't change.
+
+This patch is tagged for 'stable' as it fixes a lot of n-key RollOver
+hardware. We might wanna wait with backporting for a while, before we know
+it doesn't break anything else, though.
+
+Reported-by: Adam Goode <adam@spicenitz.org>
+Reported-by: Fredrik Hallenberg <megahallon@gmail.com>
+Tested-by: Fredrik Hallenberg <megahallon@gmail.com>
+Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
+Signed-off-by: Jiri Kosina <jkosina@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hid/hid-input.c | 16 ++++++++++++++++
+ 1 file changed, 16 insertions(+)
+
+--- a/drivers/hid/hid-input.c
++++ b/drivers/hid/hid-input.c
+@@ -1066,6 +1066,22 @@ void hidinput_hid_event(struct hid_devic
+ return;
+ }
+
++ /*
++ * Ignore reports for absolute data if the data didn't change. This is
++ * not only an optimization but also fixes 'dead' key reports. Some
++ * RollOver implementations for localized keys (like BACKSLASH/PIPE; HID
++ * 0x31 and 0x32) report multiple keys, even though a localized keyboard
++ * can only have one of them physically available. The 'dead' keys
++ * report constant 0. As all map to the same keycode, they'd confuse
++ * the input layer. If we filter the 'dead' keys on the HID level, we
++ * skip the keycode translation and only forward real events.
++ */
++ if (!(field->flags & (HID_MAIN_ITEM_RELATIVE |
++ HID_MAIN_ITEM_BUFFERED_BYTE)) &&
++ usage->usage_index < field->maxusage &&
++ value == field->value[usage->usage_index])
++ return;
++
+ /* report the usage code as scancode if the key status has changed */
+ if (usage->type == EV_KEY && !!test_bit(usage->code, input->key) != value)
+ input_event(input, EV_MSC, MSC_SCAN, usage->hid);
--- /dev/null
+From 33e5df0e0e32027866e9fb00451952998fc957f2 Mon Sep 17 00:00:00 2001
+From: Jason Gerecke <killertofu@gmail.com>
+Date: Thu, 22 Jan 2015 15:53:28 -0800
+Subject: HID: wacom: Report ABS_MISC event for Cintiq Companion Hybrid
+
+From: Jason Gerecke <killertofu@gmail.com>
+
+commit 33e5df0e0e32027866e9fb00451952998fc957f2 upstream.
+
+It appears that the Cintiq Companion Hybrid does not send an ABS_MISC event to
+userspace when any of its ExpressKeys are pressed. This is not strictly
+necessary now that the pad exists on its own device, but should be fixed for
+consistency's sake.
+
+Traditionally both the stylus and pad shared the same device node, and
+xf86-input-wacom would use ABS_MISC for disambiguation. Not sending this causes
+the Hybrid to behave incorrectly with xf86-input-wacom beginning with its
+8f44f3 commit.
+
+Signed-off-by: Jason Gerecke <killertofu@gmail.com>
+Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+Signed-off-by: Jiri Kosina <jkosina@suse.cz>
+[killertofu@gmail.com: ported to drivers/input/tablet/wacom_wac.c]
+Signed-off-by: Jason Gerecke <killertofu@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+
+---
+ drivers/input/tablet/wacom_wac.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/input/tablet/wacom_wac.c
++++ b/drivers/input/tablet/wacom_wac.c
+@@ -700,6 +700,12 @@ static int wacom_intuos_irq(struct wacom
+ input_report_key(input, BTN_7, (data[4] & 0x40)); /* Left */
+ input_report_key(input, BTN_8, (data[4] & 0x80)); /* Down */
+ input_report_key(input, BTN_0, (data[3] & 0x01)); /* Center */
++
++ if (data[4] | (data[3] & 0x01)) {
++ input_report_abs(input, ABS_MISC, PAD_DEVICE_ID);
++ } else {
++ input_report_abs(input, ABS_MISC, 0);
++ }
+ } else if (features->type >= INTUOS5S && features->type <= INTUOSPL) {
+ int i;
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
