Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 11 11月, 2014 1 次提交
  3. 01 10月, 2014 1 次提交
    • B
      HID: wacom: implement generic HID handling for pen generic devices · 7704ac93
      由 Benjamin Tissoires 提交于 
      ISDv4 and v5 are plain HID devices. We can directly implement a generic
HID parsing/handling and remove the need to manually add those PID in
the list of supported devices.

This patch implements the pen support only. The finger part will come in
a later patch.

To be properly notified of an .event() and a .report(), we need to force
hid-core to go through the HID parsing. By default, wacom.ko binds only
hidraw, so the hid parsing is not done by hid-core. When a true HID device
is there, we add the flag HID_CLAIMED_DRIVER to hid->claimed which will
force hid-core to parse the incoming reports.
(Note that this can be easily backported by directly setting the .claimed
flag to HID_CLAIMED_DRIVER even if hid-core does not support
HID_CONNECT_DRIVER)
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NJason Gerecke <killertofu@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      7704ac93
  5. 08 9月, 2014 2 次提交
  7. 04 9月, 2014 1 次提交
  9. 07 8月, 2014 2 次提交
  11. 29 7月, 2014 5 次提交
  13. 26 7月, 2014 1 次提交
    • B
      Input: wacom - switch from an USB driver to a HID driver · 29b47391
      由 Benjamin Tissoires 提交于 
      All USB Wacom tablets are actually HID devices.
For historical reasons, they are handled as plain USB devices.
The current code makes more and more reference to the HID subsystem
like implementing its own HID report descriptor parser to handle new
devices.

From the user point of view, we can transparently switch from this state
to a driver handled in the HID subsystem and clean up a lot of USB specific
code in the wacom.ko driver.

The other benefit once the USB dependecies have been removed is that we can
use a tool like uhid to make regression tests and allow further cleanup or
new implementations without risking breaking current behaviors.

To match the current handling of devices in wacom_wac.c, we rely on the
hid_type set by usbhid. usbhid sets the hid_type to HID_TYPE_USBMOUSE when
it sees a USB boot mouse protocol declared and HID_TYPE_USBNONE when the
device is plain HID. There is thus a one to one matching between the list
of supported devices before and after the switch from USB to HID.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: NJason Gerecke <killertofu@gmail.com>
Tested-by: NJason Gerecke <killertofu@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      29b47391
  15. 01 7月, 2014 1 次提交
  17. 22 5月, 2014 1 次提交
  19. 21 5月, 2014 1 次提交
  21. 20 5月, 2014 1 次提交
  23. 05 5月, 2014 1 次提交
  25. 09 4月, 2014 1 次提交
  27. 07 4月, 2014 2 次提交
    • B
      HID: core: do not scan constant input report · e24d0d39
      由 Benjamin Tissoires 提交于 
      The Microsoft Surface Type/Touch Cover 2 is a fancy device which advertised
itself as a multitouch device but with constant input reports.
This way, hid_scan_report() gives the group MULTITOUCH to it, but
hid-multitouch can not handle it due to the constant collection ignored
by hid-input.

To prevent such crap in the future, and while we do not fix this particular
device, make the scan_report coherent with hid-input.c, and ignore constant
input reports.

CC: stable@vger.kernel.org # 3.12+
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      e24d0d39
    • D
      Revert "HID: microsoft: Add ID's for Surface Type/Touch Cover 2" · f3b0cbce
      由 Derya 提交于 
      This reverts commit 117309c5.

The MS Surface Pro 2 has an USB composite device with 3 interfaces
- interface 0 - sensor hub
- interface 1 - wacom digitizer
- interface 2 - the keyboard cover, if one is attached
This USB composite device changes it product id dependent on if and which
keyboard cover is attached. Adding the covers to hid_have_special_driver
prevents loading the right hid drivers for the other two interfaces, all 3
get loaded with hid-microsoft. We don't even need hid-microsoft for the
keyboards. We have to revert this to load the right hid modules for each
interface.

CC: stable@vger.kernel.org # kernel 3.14 only
Signed-off-by: NDerya <derya.kiran@yahoo.de>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      f3b0cbce
  29. 25 2月, 2014 1 次提交
  31. 18 2月, 2014 1 次提交
    • D
      HID: add hid-cp2112 driver · e932d817
      由 David Barksdale 提交于 
      This patch adds support for the Silicon Labs CP2112 "Single-Chip HID USB to
SMBus Master Bridge."

This is a HID device driver which registers as an i2c adapter and gpiochip to
expose these functions of the CP2112. The customizable USB descriptor fields
are exposed as sysfs attributes.  The SMBus byte-read, byte-data-read/write,
and word-data-read transfer modes have been tested by talking to an i2c
sensor.  The GPIO functions and USB descriptor field programming have also
been tested.
Signed-off-by: NDavid Barksdale <dbarksdale@uplogix.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      e932d817
  33. 17 2月, 2014 1 次提交
  35. 16 2月, 2014 1 次提交
  37. 06 2月, 2014 1 次提交
  39. 03 2月, 2014 1 次提交
  41. 28 1月, 2014 1 次提交
  43. 17 1月, 2014 2 次提交
  45. 18 12月, 2013 1 次提交
  47. 16 12月, 2013 1 次提交
  49. 13 12月, 2013 1 次提交
  51. 02 12月, 2013 1 次提交
  53. 21 11月, 2013 1 次提交
  55. 19 11月, 2013 1 次提交
  57. 13 11月, 2013 1 次提交
  59. 11 11月, 2013 1 次提交
    • F
      HID: don't ignore eGalax/D-Wav/EETI HIDs · 95d50b6c
      由 Forest Bond 提交于 
      Certain devices with class HID, protocol None did not work with the HID
driver at one point, and as a result were bound to usbtouchscreen
instead as of commit 139ebe8d ("Input: usbtouchscreen - fix eGalax HID
ignoring").  This change was prompted by the following report:

https://lkml.org/lkml/2009/1/25/127

Unfortunately, the device mentioned in this report is no longer
available for testing.

We've recently discovered that some devices with class HID, protocol
None do not work with usbtouchscreen, but do work with usbhid.  Here is
the report that made this evident:

http://comments.gmane.org/gmane.linux.kernel.input/31710

Driver binding for these devices has flip-flopped a few times, so both
of the above reports were regressions.

This situation would appear to leave us with no easy way to bind every
device to the right driver.  However, in my own testing with several
devices I have not found a device with class HID that does not work with
the current HID driver.  It is my belief that changes to the HID driver
since the original report have likely fixed the issue(s) that made it
unsuitable at the time, and that we should prefer it over usbtouchscreen
for these devices.  In particular, HID quirks affecting these devices
were added/removed in the following commits since then:

fe6065dc HID: add multi-input quirk for eGalax Touchcontroller
77933c35 Merge branch 'egalax' into for-linus
ebd11fec HID: Add quirk for eGalax touch controler.
d34c4aa4 HID: add no-get quirk for eGalax touch controller

This patch makes the HID driver no longer ignore eGalax/D-Wav/EETI
devices with class HID.  If there are in fact devices with class HID
that still do not work with the HID driver, we will see another round of
regressions.  In that case I propose we investigate why the device is
not working with the HID driver rather than re-introduce regressions for
functioning HID devices by again binding them to usbtouchscreen.

The corresponding change to usbtouchscreen will be made separately.
Signed-off-by: NForest Bond <forest.bond@rapidrollout.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      95d50b6c
  61. 08 11月, 2013 1 次提交
  63. 30 10月, 2013 1 次提交