1. 17 3月, 2015 1 次提交
    • B
      HID: wacom: ask for a in-prox report when it was missed · 5fcad167
      Benjamin Tissoires 提交于
      If noone listens to the input device when a tool comes in proximity,
      the tablet does not send the in-prox event when a client becomes available.
      That means that no events will be sent until the tool is taken out of
      proximity.
      
      In this situation, ask for the report WACOM_REPORT_INTUOSREAD which will
      read the corresponding feature and generate an in-prox event.
      To make some generation of hardware working, we need to unset the
      quirk NO_GET set by hid-core because the interfaces are seen as "boot
      mouse".
      
      We don't schedule this read in a worker while we are in an IO interrupt.
      We know that usbhid will do it asynchronously. If this is triggered by
      uhid, then this is obviously a client side bug :)
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Acked-by: NJason Gerecke <killertofu@gmail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      5fcad167
  2. 12 3月, 2015 1 次提交
    • J
      HID: wacom: Add battery presence indicator to wireless tablets · 71fa641e
      Jason Gerecke 提交于
      Declare the POWER_SUPPLY_PROP_PRESENT property to provide userspace
      with a way to determine if the battery on a wireless tablet is plugged
      in. Although current wireless tablets do not explicitly report this
      information, it can be inferred from other state information. In
      particular, a battery is assumed to be present if any of the following
      are true: a non-zero battery level reported, the battery is reported as
      charging, or the tablet is operating wirelessly.
      
      Note: The last condition above may not strictly hold for the Graphire
      Wireless (it charges from a DC barrel jack instead of a USB port), but I
      do not know what is reported in the no-battery condition.
      Signed-off-by: NJason Gerecke <killertofu@gmail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      71fa641e
  3. 11 3月, 2015 2 次提交
  4. 27 2月, 2015 2 次提交
  5. 29 1月, 2015 1 次提交
  6. 06 1月, 2015 1 次提交
  7. 10 12月, 2014 1 次提交
  8. 02 12月, 2014 2 次提交
    • B
      HID: wacom: fix freeze on open when autosuspend is on · dff67416
      Benjamin Tissoires 提交于
      Since the conversion from USB to HID (in v3.17), some people reported a
      freeze on boot with the wacom driver. Hans managed to get a stacktrace:
      
      [  240.272331] Call Trace:
      [  240.272338]  [<ffffffff813de7b9>] ? usb_hcd_submit_urb+0xa9/0xb10
      [  240.272347]  [<ffffffff81555579>] schedule+0x29/0x70
      [  240.272355]  [<ffffffff815559e6>] schedule_preempt_disabled+0x16/0x20
      [  240.272363]  [<ffffffff81557365>] __mutex_lock_slowpath+0xe5/0x230
      [  240.272372]  [<ffffffff815574c7>] mutex_lock+0x17/0x30
      [  240.272380]  [<ffffffffa063c1d2>] wacom_resume+0x22/0x50 [wacom]
      [  240.272396]  [<ffffffffa01aea8a>] hid_resume_common+0xba/0x110 [usbhid]
      [  240.272404]  [<ffffffff813e5890>] ? usb_runtime_suspend+0x80/0x80
      [  240.272417]  [<ffffffffa01aeb1d>] hid_resume+0x3d/0x70 [usbhid]
      [  240.272425]  [<ffffffff813e44a6>] usb_resume_interface.isra.6+0xb6/0x120
      [  240.272432]  [<ffffffff813e4774>] usb_resume_both+0x74/0x140
      [  240.272439]  [<ffffffff813e58aa>] usb_runtime_resume+0x1a/0x20
      [  240.272446]  [<ffffffff813b1912>] __rpm_callback+0x32/0x70
      [  240.272453]  [<ffffffff813b1976>] rpm_callback+0x26/0xa0
      [  240.272460]  [<ffffffff813b2d71>] rpm_resume+0x4b1/0x690
      [  240.272468]  [<ffffffff812ab992>] ? radix_tree_lookup_slot+0x22/0x50
      [  240.272475]  [<ffffffff813b2c1a>] rpm_resume+0x35a/0x690
      [  240.272482]  [<ffffffff8116e9c9>] ? zone_statistics+0x89/0xa0
      [  240.272489]  [<ffffffff813b2f90>] __pm_runtime_resume+0x40/0x60
      [  240.272497]  [<ffffffff813e4272>] usb_autopm_get_interface+0x22/0x60
      [  240.272509]  [<ffffffffa01ae8d9>] usbhid_open+0x59/0xe0 [usbhid]
      [  240.272517]  [<ffffffffa063ac85>] wacom_open+0x35/0x50 [wacom]
      [  240.272525]  [<ffffffff813f37b9>] input_open_device+0x79/0xa0
      [  240.272534]  [<ffffffffa048d1c1>] evdev_open+0x1b1/0x200 [evdev]
      [  240.272543]  [<ffffffff811c899e>] chrdev_open+0xae/0x1f0
      [  240.272549]  [<ffffffff811c88f0>] ? cdev_put+0x30/0x30
      [  240.272556]  [<ffffffff811c17e2>] do_dentry_open+0x1d2/0x320
      [  240.272562]  [<ffffffff811c1cd1>] finish_open+0x31/0x50
      [  240.272571]  [<ffffffff811d2202>] do_last.isra.36+0x652/0xe50
      [  240.272579]  [<ffffffff811d2ac7>] path_openat+0xc7/0x6f0
      [  240.272586]  [<ffffffff811cf012>] ? final_putname+0x22/0x50
      [  240.272594]  [<ffffffff811d42d2>] ? user_path_at_empty+0x72/0xd0
      [  240.272602]  [<ffffffff811d43fd>] do_filp_open+0x4d/0xc0
      [...]
      
      So here, wacom_open is called, and then wacom_resume is called by the
      PM system. However, wacom_open already took the lock when wacom_resume
      tries to get it. Freeze.
      
      A little bit of history shows that this already happened in the past
      - commit f6cd3783 ("Input: wacom - fix runtime PM related deadlock"),
      and the solution was to call first the PM function before taking the lock.
      
      The lock was introduced in commit commit e7224094 ("Input: wacom -
      implement suspend and autosuspend") when the autosuspend feature has
      been added. Given that usbhid already takes care of this very same
      locking between suspend/resume, I think we can simply kill the lock
      in open/close.
      
      The lock is now used also with LEDs, so we can not remove it completely.
      Reported-by: NHans Spath <inbox-546@hans-spath.de>
      Tested-by: NHans Spath <inbox-546@hans-spath.de>
      CC: stable@vger.kernel.org # v3.17+
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      dff67416
    • M
      HID: make hid_report_len as a static inline function in hid.h · dabb05c6
      Mathieu Magnaudet 提交于
      In several hid drivers it is necessary to calculate the length of an
      hid_report. This patch exports the existing static function hid_report_len of
      hid-core.c as an inline function in hid.h
      Signed-off-by: NMathieu Magnaudet <mathieu.magnaudet@enac.fr>
      Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
      Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      dabb05c6
  9. 26 11月, 2014 1 次提交
  10. 21 11月, 2014 1 次提交
  11. 01 10月, 2014 5 次提交
  12. 22 9月, 2014 1 次提交
  13. 12 9月, 2014 1 次提交
    • B
      HID: wacom: make the WL connection friendly for the desktop · 12969e3b
      Benjamin Tissoires 提交于
      Currently, tablets connected to the WL receiver all share the same
      VID/PID. There is no way for the user space to know which one is which
      besides parsing the name. We can force the PID to be set to the
      actual hardware. This way, the input device will have the correct PID
      which can be match in libwacom.
      
      With only this trick, the pad input does not inherit the ID_INPUT_TABLET
      udev property from its parent. We can force udev to accept it by declaring
      a BTN_STYLUS which is never used.
      
      This way, tablets connected through WL can be used from the user point of
      view in the same way they are used while connected through wire.
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Reviewed-by: NPing Cheng <pingc@wacom.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      12969e3b
  14. 11 9月, 2014 4 次提交
  15. 13 8月, 2014 1 次提交
  16. 07 8月, 2014 6 次提交
  17. 26 7月, 2014 9 次提交