user/sven/linux.git/drivers/hid, branch v3.12.39

HID: fixup the conflicting keyboard mappings quirk

2015-03-16T13:58:18Z

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: Jiri Slaby

HID: input: fix confusion on conflicting mappings

2015-03-16T13:58:18Z

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: Jiri Slaby

HID: yet another buggy ELAN touchscreen

2015-03-16T10:09:26Z

commit a32c99e7ab8410bae7c276a7e94ca84d108de034 upstream. The touchscreen needs the same quirk as the other models. Signed-off-by: Oliver Neukum Reported-by: Bryan Poling CC: stable@vger.kernel.org Acked-by: Greg Kroah-Hartman Signed-off-by: Jiri Kosina Signed-off-by: Jiri Slaby

HID: usbhid: enable always-poll quirk for Elan Touchscreen 0103

2015-03-16T10:09:26Z

commit fa51ee1085d6f2fa344d4ba64faadc9c6db0a3f1 upstream. Yet another device that needs this quirk. Reported-by: Tanguy de Baritault Signed-off-by: Adel Gadllah Signed-off-by: Jiri Kosina Signed-off-by: Jiri Slaby

HID: usbhid: add another mouse that needs QUIRK_ALWAYS_POLL

2015-03-16T10:09:25Z

commit 5235166fbc332c8b5dcf49e3a498a8b510a77449 upstream. There is a second mouse sharing the same vendor strings but different IDs. Signed-off-by: Oliver Neukum Signed-off-by: Jiri Kosina Signed-off-by: Jiri Slaby

HID: usbhid: fix PIXART optical mouse

2015-03-16T10:09:25Z

commit 4980f95755e2966b30ac70d1841f4db66d1a8a22 upstream. This mouse keeps disconnecting in runlevel 3. It needs the ALWAYS_POLL quirk. Signed-off-by: Oliver Neukum Signed-off-by: Jiri Kosina Signed-off-by: Jiri Slaby

HID: microsoft: Add ID for NE7K wireless keyboard

2015-03-16T10:09:24Z

commit ef567cf9ddb682dbfa840bf4a2600931299f9555 upstream. Microsoft Natural Wireless Ergonomic Keyboard 7000 has special My Favorites 1..5 keys which are handled through a vendor-defined usage page (0xff05). Apply MS_ERGONOMY quirks handling to USB PID 0x071d (Microsoft Microsoft 2.4GHz Transceiver V1.0) so that the My Favorites 1..5 keys are reported as KEY_F14..18 events. Link: https://bugzilla.kernel.org/show_bug.cgi?id=52841 Signed-off-by: Jakub Sitnicki Signed-off-by: Jiri Kosina Signed-off-by: Jiri Slaby

HID: microsoft: add support for Japanese Surface Type Cover 3

2015-03-12T16:31:23Z

commit 5e7e9e90b5867a3754159a8ce524299d930fbac8 upstream. Based on code for the US Surface Type Cover 3 from commit be3b16341d5cd8cf2a64fcc7a604a8efe6599ff0 ("HID: add support for MS Surface Pro 3 Type Cover"): Signed-off-by: Alan Wu Tested-by: Karlis Dreizis Signed-off-by: Jiri Kosina Signed-off-by: Jiri Slaby

HID: add support for MS Surface Pro 3 Type Cover

2015-03-12T16:31:22Z

commit be3b16341d5cd8cf2a64fcc7a604a8efe6599ff0 upstream. Surface Pro 3 Type Cover that works with Ubuntu (and possibly Arch) from this thread. Both trackpad and keyboard work after compiling my own kernel. http://ubuntuforums.org/showthread.php?t=2231207&page=2&s=44910e0c56047e4f93dfd9fea58121ef Also includes Jarrad Whitaker's message which sources http://winaero.com/blog/how-to-install-linux-on-surface-pro-3/ which he says is sourced from a Russian site Signed-off-by: Alan Wu Signed-off-by: Jiri Kosina Signed-off-by: Jiri Slaby

HID: hid-microsoft: Add support for scrollwheel and special keypad keys

2015-03-12T16:31:22Z

commit 3faed1aff786a007b3ea0549ac469e09f48c98f9 upstream. The Microsoft Office keyboard has a scrollwheel as well as some special keys above the keypad which are handled through the custom MS usage page, this commit adds support for these. Signed-off-by: Hans de Goede Signed-off-by: Jiri Kosina Signed-off-by: Jiri Slaby