Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 17 2月, 2015 1 次提交
  3. 29 1月, 2015 3 次提交
  5. 27 1月, 2015 1 次提交
    • J
      HID: pidff: Fix initialisation forMicrosoft Sidewinder FF Pro 2 · afd700d9
      由 Jim Keir 提交于 
      The FF2 driver (usbhid/hid-pidff.c) sends commands to the stick during ff_init.
However, this is called inside a block where driver_input_lock is locked, so
the results of these initial commands are discarded. This behavior is the
"killer", without this nothing else works.

ff_init issues commands using "hid_hw_request". This eventually goes to
hid_input_report, which returns -EBUSY because driver_input_lock is locked. The
change is to delay the ff_init call in hid-core.c until after this lock has
been released.

Calling hid_device_io_start() releases the lock so the device can be
configured.  We also need to call hid_device_io_stop() on exit for the lock to
remain locked while ending the init of the drivers.

[ benjamin.tissoires@redhat.com: imrpoved the changelog a lot ]
Signed-off-by: NJim Keir <jimkeir@oracledbadirect.com>
Reviewed-by: NBenjamin.tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      afd700d9
  7. 26 1月, 2015 1 次提交
  9. 23 1月, 2015 1 次提交
  11. 22 1月, 2015 1 次提交
  13. 21 1月, 2015 1 次提交
  15. 19 1月, 2015 2 次提交
  17. 12 1月, 2015 5 次提交
  19. 09 1月, 2015 2 次提交
  21. 07 1月, 2015 5 次提交
    • A
      HID: microsoft: add support for Japanese Surface Type Cover 3 · 5e7e9e90
      由 Alan Wu 提交于 
      Based on code for the US Surface Type Cover 3
from commit be3b1634
("HID: add support for MS Surface Pro 3 Type Cover"):
Signed-off-by: NAlan Wu <alan.c.wu@gmail.com>
Tested-by: NKarlis Dreizis <karlisdreizis@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      5e7e9e90
    • J
      HID: fixup the conflicting keyboard mappings quirk · 8e7b3410
      由 Jiri Kosina 提交于 
      The ignore check that got added in 6ce901eb ("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.

Cc: <stable@vger.kernel.org>
Fixes: 6ce901eb ("HID: input: fix confusion on conflicting mappings")
Reported-by: NFredrik Hallenberg <megahallon@gmail.com>
Reported-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      8e7b3410
    • R
      HID: apple: fix battery support for the 2009 ANSI wireless keyboard · cbd366be
      由 Ross Skaliotis 提交于 
      Enabled quirks necessary for correct battery capacity reporting. Cleaned up
surrounding style.
Signed-off-by: NRoss Skaliotis <rskaliotis@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      cbd366be
    • G
      HID: fix Kconfig text · 79bc33bd
      由 Geert Uytterhoeven 提交于 
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      79bc33bd
    • D
      HID: input: fix confusion on conflicting mappings · 6ce901eb
      由 David Herrmann 提交于 
      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.

Cc: <stable@vger.kernel.org>
Reported-by: NAdam Goode <adam@spicenitz.org>
Reported-by: NFredrik Hallenberg <megahallon@gmail.com>
Tested-by: NFredrik Hallenberg <megahallon@gmail.com>
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      6ce901eb
  23. 06 1月, 2015 2 次提交
  25. 29 12月, 2014 1 次提交
  27. 22 12月, 2014 3 次提交
  29. 19 12月, 2014 3 次提交
  31. 18 12月, 2014 1 次提交
  33. 17 12月, 2014 7 次提交