Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 19 11月, 2013 2 次提交
  3. 15 11月, 2013 1 次提交
  5. 13 11月, 2013 1 次提交
  7. 11 11月, 2013 2 次提交
    • S
      HID: sony: Add force feedback support for Dualshock3 USB · a08c22c0
      由 Sven Eckelmann 提交于 
      Sony Dualshock 3 controllers have two motors which can be used to provide
simple force feedback rumble effects. The right motor is can be used to create
a weak rumble effect but does not allow to set the force. The left motor is
used to create a strong rumble effect with adjustable intensity.

The state of both motors can be changed using HID_OUTPUT_REPORT packets and
have no timing information. FF memless is used to keep track of the timing and
the sony driver just generates the necessary URBs.
Signed-off-by: NSven Eckelmann <sven@narfation.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      a08c22c0
    • 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
  9. 08 11月, 2013 6 次提交
  11. 04 11月, 2013 1 次提交
  13. 30 10月, 2013 10 次提交
  15. 25 10月, 2013 2 次提交
  17. 21 10月, 2013 1 次提交
  19. 18 10月, 2013 1 次提交
    • N
      HID: Fix unit exponent parsing again · ad0e669b
      由 Nikolai Kondrashov 提交于 
      Revert some changes done in 77463838.

Revert all changes done in hidinput_calc_abs_res as it mistakingly used
"Unit" item exponent nibbles to affect resolution value. This wasn't
breaking resolution calculation of relevant axes of any existing
devices, though, as they have only one dimension to their units and thus
1 in the corresponding nible.

Revert to reading "Unit Exponent" item value as a signed integer in
hid_parser_global to fix reading specification-complying values. This
fixes resolution calculation of devices complying to the HID standard,
including Huion, KYE, Waltop and UC-Logic graphics tablets which have
their report descriptors fixed by the drivers.

Explanations follow.

There are two "unit exponents" in HID specification and it is important
not to mix them. One is the global "Unit Exponent" item and another is
nibble values in the global "Unit" item. See 6.2.2.7 Global Items.

The "Unit Exponent" value is just a signed integer and is used to scale
the integer resolution unit values, so fractions can be expressed.

The nibbles of "Unit" value are used to select the unit system (nibble
0), and presence of a particular basic unit type in the unit formula and
its *exponent* (or power, nibbles 1-6). And yes, the latter is in two
complement and zero means absence of the unit type.

Taking the representation example of (integer) joules from the
specification:

[mass(grams)][length(centimeters)^2][time(seconds)^-2] * 10^-7

the "Unit Exponent" would be -7 (or 0xF9, if stored as a byte) and the
"Unit" value would be 0xE121, signifying:

Nibble  Part        Value   Meaning
-----   ----        -----   -------
0       System      1       SI Linear
1       Length      2       Centimeters^2
2       Mass        1       Grams
3       Time        -2      Seconds^-2

To give the resolution in e.g. hundredth of joules the "Unit Exponent"
item value should have been -9.

See also the examples of "Unit" values for some common units in the same
chapter.

However, there is a common misunderstanding about the "Unit Exponent"
value encoding, where it is assumed to be stored the same as nibbles in
"Unit" item. This is most likely due to the specification being a bit
vague and overloading the term "unit exponent". This also was and still
is proliferated by the official "HID Descriptor Tool", which makes this
mistake and stores "Unit Exponent" as such. This format is also
mentioned in books such as "USB Complete" and in Microsoft's hardware
design guides.

As a result many devices currently on the market use this encoding and
so the driver should support them.
Signed-off-by: NNikolai Kondrashov <spbnick@gmail.com>
Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      ad0e669b
  21. 15 10月, 2013 3 次提交
  23. 14 10月, 2013 2 次提交
  25. 09 10月, 2013 3 次提交
  27. 07 10月, 2013 2 次提交
    • L
      HID: multitouch: Fix GeneralTouch products and add more PIDs · 7b226292
      由 Luosong 提交于 
      GeneralTouch products should use the quirk SLOT_IS_CONTACTID
instead of SLOT_IS_CONTACTNUMBER.

Adding PIDs 0101,e100,0102,0106,010a from the new products.

Tested on new and older products by GeneralTouch engineers.
Signed-off-by: NLuosong <android@generaltouch.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      7b226292
    • D
      HID: wiimote: fix FF deadlock · f50f9aab
      由 David Herrmann 提交于 
      The input core has an internal spinlock that is acquired during event
injection via input_event() and friends but also held during FF callbacks.
That means, there is no way to share a lock between event-injection and FF
handling. Unfortunately, this is what is required for wiimote state
tracking and what we do with state.lock and input->lock.

This deadlock can be triggered when using continuous data reporting and FF
on a wiimote device at the same time. I takes me at least 30m of
stress-testing to trigger it but users reported considerably shorter
times (http://bpaste.net/show/132504/) when using some gaming-console
emulators.

The real problem is that we have two copies of internal state, one in the
wiimote objects and the other in the input device. As the input-lock is
not supposed to be accessed from outside of input-core, we have no other
chance than offloading FF handling into a worker. This actually works
pretty nice and also allows to implictly merge fast rumble changes into a
single request.

Due to the 3-layered workers (rumble+queue+l2cap) this might reduce FF
responsiveness. Initial tests were fine so lets fix the race first and if
it turns out to be too slow we can always handle FF out-of-band and skip
the queue-worker.

Cc: <stable@vger.kernel.org> # 3.11+
Reported-by: Thomas Schneider
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      f50f9aab
  29. 02 10月, 2013 2 次提交
  31. 01 10月, 2013 1 次提交