From 4f958333daf8cefd144bc21c9c82ed04753816a9 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 16 Mar 2015 13:52:58 +0100 Subject: [PATCH] 3.14-stable patches added patches: hid-fixup-the-conflicting-keyboard-mappings-quirk.patch hid-input-fix-confusion-on-conflicting-mappings.patch hid-wacom-report-abs_misc-event-for-cintiq-companion-hybrid.patch --- ...-conflicting-keyboard-mappings-quirk.patch | 34 +++++ ...ix-confusion-on-conflicting-mappings.patch | 143 ++++++++++++++++++ ...sc-event-for-cintiq-companion-hybrid.patch | 46 ++++++ queue-3.14/series | 3 + 4 files changed, 226 insertions(+) create mode 100644 queue-3.14/hid-fixup-the-conflicting-keyboard-mappings-quirk.patch create mode 100644 queue-3.14/hid-input-fix-confusion-on-conflicting-mappings.patch create mode 100644 queue-3.14/hid-wacom-report-abs_misc-event-for-cintiq-companion-hybrid.patch diff --git a/queue-3.14/hid-fixup-the-conflicting-keyboard-mappings-quirk.patch b/queue-3.14/hid-fixup-the-conflicting-keyboard-mappings-quirk.patch new file mode 100644 index 00000000000..de69a5b09d6 --- /dev/null +++ b/queue-3.14/hid-fixup-the-conflicting-keyboard-mappings-quirk.patch @@ -0,0 +1,34 @@ +From 8e7b341037db1835ee6eea64663013cbfcf33575 Mon Sep 17 00:00:00 2001 +From: Jiri Kosina +Date: Tue, 6 Jan 2015 22:34:19 +0100 +Subject: HID: fixup the conflicting keyboard mappings quirk + +From: Jiri Kosina + +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 +Reported-by: David Herrmann +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-3.14/hid-input-fix-confusion-on-conflicting-mappings.patch b/queue-3.14/hid-input-fix-confusion-on-conflicting-mappings.patch new file mode 100644 index 00000000000..6c1bd32e744 --- /dev/null +++ b/queue-3.14/hid-input-fix-confusion-on-conflicting-mappings.patch @@ -0,0 +1,143 @@ +From 6ce901eb61aa30ba8565c62049ee80c90728ef14 Mon Sep 17 00:00:00 2001 +From: David Herrmann +Date: Mon, 29 Dec 2014 15:21:26 +0100 +Subject: HID: input: fix confusion on conflicting mappings + +From: David Herrmann + +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 +Reported-by: Fredrik Hallenberg +Tested-by: Fredrik Hallenberg +Signed-off-by: David Herrmann +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-3.14/hid-wacom-report-abs_misc-event-for-cintiq-companion-hybrid.patch b/queue-3.14/hid-wacom-report-abs_misc-event-for-cintiq-companion-hybrid.patch new file mode 100644 index 00000000000..f5a6a071b73 --- /dev/null +++ b/queue-3.14/hid-wacom-report-abs_misc-event-for-cintiq-companion-hybrid.patch @@ -0,0 +1,46 @@ +From 33e5df0e0e32027866e9fb00451952998fc957f2 Mon Sep 17 00:00:00 2001 +From: Jason Gerecke +Date: Thu, 22 Jan 2015 15:53:28 -0800 +Subject: HID: wacom: Report ABS_MISC event for Cintiq Companion Hybrid + +From: Jason Gerecke + +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 +Reviewed-by: Benjamin Tissoires +Signed-off-by: Jiri Kosina +[killertofu@gmail.com: ported to drivers/input/tablet/wacom_wac.c] +Signed-off-by: Jason Gerecke +Signed-off-by: Greg Kroah-Hartman +--- + +--- + 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; + diff --git a/queue-3.14/series b/queue-3.14/series index e82eb347da0..56b217a7301 100644 --- a/queue-3.14/series +++ b/queue-3.14/series @@ -82,3 +82,6 @@ dm-io-reject-unsupported-discard-requests-with-eopnotsupp.patch dm-fix-a-race-condition-in-dm_get_md.patch dm-snapshot-fix-a-possible-invalid-memory-access-on-unload.patch staging-comedi-cb_pcidas64-fix-incorrect-ai-range-code-handling.patch +hid-input-fix-confusion-on-conflicting-mappings.patch +hid-fixup-the-conflicting-keyboard-mappings-quirk.patch +hid-wacom-report-abs_misc-event-for-cintiq-companion-hybrid.patch -- 2.47.3