1. 10 8月, 2011 2 次提交
    • J
      HID: propagate return value correctly in hid_input_report() · 45dc1ac7
      Jiri Kosina 提交于
      Fix a return value propagation that was omitted in David Herrmann's
      locking fix around hid_input_report().
      Reported-by: NDavid Herrmann <dh.herrmann@googlemail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      45dc1ac7
    • D
      HID: Fix race condition between driver core and ll-driver · 4ea54542
      David Herrmann 提交于
      HID low level drivers register new devices with the HID core which then
      adds the devices to the HID bus. The HID bus normally immediately probes
      an appropriate driver which then handles HID input for this device.
      The ll driver now uses the hid_input_report() function to report input
      events for a specific device. However, if the HID bus unloads the driver
      at the same time (for instance via a call to
       /sys/bus/hid/devices/<dev>/unbind) then the hdev->driver pointer may be
      used by hid_input_report() and hid_device_remove() at the same time
      which may cause hdev->driver to point to invalid memory.
      
      This fix adds a semaphore to every hid device which protects
      hdev->driver from asynchronous access. This semaphore is locked during
      driver *_probe and *_remove and also inside hid_input_report(). The
      *_probe and *_remove functions may sleep so the semaphore is good here,
      however, hid_input_report() is in atomic context and hence only uses
      down_trylock(). If it cannot acquire the lock it simply drops the input
      package.
      
      The low-level drivers report input events synchronously so
      hid_input_report() should never be entered twice at the same time on the
      same device. Hence, the lock should always be available. But if the
      driver is currently probed/removed then the lock is not available and
      dropping the package should be safe because this is what would have
      happened if the package arrived some milliseconds earlier/later.
      
      This also fixes another race condition while probing drivers:
      First the *_probe function of the driver is called and only if that
      succeeds, the related input device of hidinput is registered. If the low
      level driver reports input events after the *_probe function returned
      but before the input device is registered, then a NULL pointer
      dereference will occur. (Equivalently on driver remove function).
      This is not possible anymore, since the semaphore lock drops all
      incoming packages until the driver/device is fully initialized.
      Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      4ea54542
  2. 05 8月, 2011 2 次提交
  3. 22 7月, 2011 1 次提交
  4. 21 7月, 2011 3 次提交
  5. 20 7月, 2011 1 次提交
  6. 14 7月, 2011 1 次提交
  7. 12 7月, 2011 1 次提交
  8. 11 7月, 2011 13 次提交
  9. 27 6月, 2011 1 次提交
  10. 24 6月, 2011 3 次提交
  11. 16 6月, 2011 1 次提交
  12. 14 6月, 2011 1 次提交
  13. 13 6月, 2011 7 次提交
  14. 08 6月, 2011 1 次提交
    • S
      HID: Add driver to fix Speedlink VAD Cezanne support · 74bc6953
      Stefan Kriwanek 提交于
      Speedlink VAD Cezanne have a hardware bug that makes the cursor "jump" from one
      place to another every now and then. The issue are relative motion events
      erroneously reported by the device, each having a distance value of +256. This
      256 can in fact never occur due to real motion, therefore those events can
      safely be ignored.  The driver also drops useless EV_REL events with a value of
      0, that the device sends every time it sends an "real" EV_REL or EV_KEY event.
      Signed-off-by: NStefan Kriwanek <mail@stefankriwanek.de>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      74bc6953
  15. 07 6月, 2011 2 次提交
    • M
      HID: Fix Logitech Driving Force Pro wheel · dc0a4f0c
      Michael Bauer 提交于
      - Add the quirk "NOGET" to make the wheel work at all in native mode.
      - Replace the somehow broken report descriptor with a custom one to have
        separate throttle and brake axes.
      
      As there are significant differences in the descriptor (original descriptor
      "hides" the separate axes in a  24 bit FF00 usagepage, new descripter replaces
      that with two individual 8 bit desktop.y and desktop.rz usages) I provided a
      complete replacement descriptor instead trying to patch the original one.
      Patching the descriptor seems not feasible as the new one is much larger.
      
      Note: To actually test this you have to use the tool "ltwheelconf" to put the
      DFP into it's native mode - See below for more info.
      
      Background:
      Most Logitech wheels are initially reporting themselves with a "fallback"
      deviceID (USB_DEVICE_ID_LOGITECH_WHEEL - 0xc294), in order to make sure they
      are working even without having the proper driver installed.
      
      If the Logitech driver is installed it sends a special command to the wheel
      which sets the wheel to "native mode", enabling enhance features like:
      - Clutch pedal
      - extended wheel rotation range (up to 900 degrees)
      - H-gate shifter
      - separate axis for throttle / brake
      - all buttons
      
      When the wheel is set to native mode it basically disconnects and reconnects
      with a different deviceID (USB_DEVICE_ID_LOGITECH_DFP_WHEEL - 0xc298 in this
      case).
      
      I am working on a userspace tool [1] which does the switching from fallback to
      native mode. During development I found out that the Driving Force Pro wheel
      is not supported in native mode - quierk NOGET is missing and the throttle and
      brake axes are reported in a combined way only.
      Signed-off-by: NMichael Bauer <michael@m-bauer.org>
      Signed-off-by: NSimon Wood <simon@mungewell.org>
      
      [1] https://github.com/TripleSpeeder/LTWheelConfSigned-off-by: NJiri Kosina <jkosina@suse.cz>
      dc0a4f0c
    • A
      HID: hid-multitouch: add support for Chunghwa multi-touch panel · 942fd422
      Austin Zhang 提交于
      Added Chunghwa hid multitouch panel support into hid-multitouch.
      Signed-off-by: NAustin Zhang <zhang.austin@gmail.com>
      Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@enac.fr>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      942fd422