1. 13 Apr, 2015 2 commits
  2. 10 Apr, 2015 3 commits
  3. 07 Apr, 2015 1 commit
    • Benjamin Tissoires's avatar
      Input - mt: Fix input_mt_get_slot_by_key · c6275892
      Benjamin Tissoires authored
      The case occurred recently with a touchscreen using twice a slot during a
      single EV_SYN event:
      
      E: 0.288415 0000 0000 0000      # ------------ SYN_REPORT (0) ----------
      E: 0.296207 0003 002f 0000      # EV_ABS / ABS_MT_SLOT          0
      E: 0.296207 0003 0039 -001      # EV_ABS / ABS_MT_TRACKING_ID   -1
      E: 0.296207 0003 002f 0001      # EV_ABS / ABS_MT_SLOT          1
      E: 0.296207 0003 0035 0908      # EV_ABS / ABS_MT_POSITION_X    908
      E: 0.296207 0003 0036 1062      # EV_ABS / ABS_MT_POSITION_Y    1062
      E: 0.296207 0003 002f 0000      # EV_ABS / ABS_MT_SLOT          0
      E: 0.296207 0003 0039 8787      # EV_ABS / ABS_MT_TRACKING_ID   8787
      E: 0.296207 0003 0035 1566      # EV_ABS / ABS_MT_POSITION_X    1566
      E: 0.296207 0003 0036 0861      # EV_ABS / ABS_MT_POSITION_Y    861
      E: 0.296207 0003 0000 0908      # EV_ABS / ABS_X                908
      E: 0.296207 0003 0001 1062      # EV_ABS / ABS_Y                1062
      E: 0.296207 0000 0000 0000      # ------------ SYN_REPORT (0) ----------
      
      This occurred because while having already slots 0 and 1 assigned, the
      touchscreen sent:
      
      0.293377 Tip Switch: 0 | Contact Id: 0 | X:  539 | Y: 1960 | Contact Count: 3
      0.294783 Tip Switch: 1 | Contact Id: 1 | X:  908 | Y: 1062 | Contact Count: 0
      0.296187 Tip Switch: 1 | Contact Id: 2 | X: 1566 | Y:  861 | Contact Count: 0
      
      Slot 0 is released correclty, but when we look for Contact ID 2, the slot
      0 is then picked up again because it is marked as inactive (trackingID < 0).
      
      This is wrong, and we should not reuse a slot in the same frame.
      The test should also check for input_mt_is_used().
      
      In addition, we need to initialize mt->frame to an other value than 0.
      With mt->frame being 0, all slots are tags as currently used, and so
      input_mt_get_slot_by_key() would return -1 for all requests.
      
      Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=88903Signed-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Acked-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      c6275892
  4. 05 Apr, 2015 1 commit
  5. 02 Apr, 2015 8 commits
  6. 27 Mar, 2015 1 commit
  7. 25 Mar, 2015 2 commits
  8. 17 Mar, 2015 1 commit
  9. 16 Mar, 2015 7 commits
    • Benjamin Tissoires's avatar
      HID: wacom: ask for a in-prox report when it was missed · 5fcad167
      Benjamin Tissoires authored
      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: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Acked-by: default avatarJason Gerecke <killertofu@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      5fcad167
    • Srinivas Pandruvada's avatar
      HID: hid-sensor-hub: Fix sparse warning · 62fad137
      Srinivas Pandruvada authored
      Since I can't change the type of hid_set_field argument 3, using __force __s32 to remove
      this warning.
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      62fad137
    • Srinivas Pandruvada's avatar
      HID: hid-sensor-hub: fix attribute read for logical usage id · eb964833
      Srinivas Pandruvada authored
      For defining enumeration values like report or power status events, the
      enumeration usage ids are enclosed in a logical collection.  In this case we
      need to match logical usage id for pending read on this usage id. For example,
      in the below field, when read is requested for 0319, the report will
      contain one of the status usages like 850, 851 etc. In this case the raw
      event will not match 0319. So when logical collection matches, then wake
      up the pending thread.
      
            Physical(Sensor.OtherCustom)
            Logical(Sensor.0319)
            Application(Sensor.Sensor)
            Usage(6)
              Sensor.0850
              Sensor.0851
              Sensor.0852
              Sensor.0853
              Sensor.0854
              Sensor.0855
            Logical Minimum(1)
            Logical Maximum(5)
            Report Size(8)
            Report Count(1)
            Report Offset(24)
            Flags( Array Absolute )
      Signed-off-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      eb964833
    • Stefan Richter's avatar
      HID: plantronics: fix Kconfig default · f1088b38
      Stefan Richter authored
      This driver didn't exist until before v3.19.
      Why would suddenly everybody want to build it?
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      f1088b38
    • Jim Keir's avatar
      HID: pidff: support more than one concurrent effect · e8f46e4f
      Jim Keir authored
      The PID driver (usbhid/hid-pidff.c) does not set the effect ID when
      uploading an effect. The result is that the initial upload works but
      subsequent uploads to modify effect parameters are all directed at the
      last-created effect.
      
      The targeted effect ID must be passed back to the device when effect
      parameters are changed. This is done at the start of
      "pidff_set_condition_report", "pidff_set_periodic_report" etc. based on
      the value of "pidff->block_load[PID_EFFECT_
      BLOCK_INDEX].value[0]".
      
      This value is only ever set during pidff_request_effect_upload.
      The result is stored in "pidff->pid_id[effect->id]" at the end of
      pid_upload_effect, for later use. However, if an effect is modified and
      re-sent then this identifier is not being copied back from
      pidff->pid_id[effect->id] before sending the command to the device. The
      fix is to do this at the start of pidff_upload_effect.
      Signed-off-by: default avatarJim Keir <jimkeir@oracledbadirect.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      e8f46e4f
    • Jean Delvare's avatar
      HID: Stop hiding options with !EXPERT · 7af05e73
      Jean Delvare authored
      Many HID driver options are hidden unless EXPERT is set. While I
      understand the idea of simplifying the kernel configuration for most
      users, in practice I believe it adds more confusion than it helps.
      
      One thing that worries me is that, in non-EXPERT mode, these drivers
      will be either built-in or modular based on apparent magic. For
      example, switching INPUT and HID from m to y will cause all these
      drivers to be built into the kernel when they were previously built
      as modules. Short of enabling EXPERT mode altogether, the user has no
      control over that.
      
      Generally I do not think tristate options should depend on !EXPERT.
      Of these, 11 of 15 are currently in the hid subsystem.
      
      The HID_LOGITECH option is even worse than the others. Sub-options
      depend on it, and this causes menuconfig and friends to display the
      option even though the user can't change its value. The help page for
      HID_LOGITECH will not explain why the value can't be changed. It only
      says, for example:
      
        Depends on: INPUT [=y] && HID [=y]
      
      and that leaves the user puzzled about why the option is forced to y.
      You might argue that this is a Kconfig bug, but that doesn't make it
      less annoying for the user.
      
      Even worse is that some of the sub-options of HID_LOGITECH select
      INPUT_FF_MEMLESS, which in turn gets out of control for the user. So,
      if you set INPUT=y and HID=y (something most general purpose
      distributions would do these days, as both modules would get loaded on
      a vast majority of systems otherwise), and you want support for
      force-feedback game controllers, you can't have that as a module, it
      has to be built-in, regardless of how rare these devices are.
      
      Of course, all this madness goes away once EXPERT is enabled, but then
      the rest of the kernel configuration becomes more complex, which
      totally voids the original point.
      
      For this reason, I would like all HID device tristate options to be
      displayed regardless of EXPERT being set or not. We can let the
      default settings still depend on EXPERT, that's not intrusive.
      Signed-off-by: default avatarJean Delvare <jdelvare@suse.de>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      7af05e73
    • Benjamin Tissoires's avatar
      HID: uclogic: make input_mapping independent of usb · ee20fe23
      Benjamin Tissoires authored
      No need to retrieve the USB handle in input_mapping() when we already
      do that in probe. It also allows to use the quirk without having to
      add the product ID matching.
      Signed-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      ee20fe23
  10. 15 Mar, 2015 2 commits
  11. 12 Mar, 2015 1 commit
  12. 11 Mar, 2015 9 commits
  13. 06 Mar, 2015 1 commit
  14. 04 Mar, 2015 1 commit
    • Dmitry Torokhov's avatar
      HID: map telephony usage page · f3dddf24
      Dmitry Torokhov authored
      Currently HID code maps usages from telephony page into BTN_0, BTN_1, etc
      keys which get interpreted by mousedev and userspace as left/right/middle
      button clicks, which is not really helpful.
      
      This change adds mappings for usages that have corresponding input event
      definitions, and leaves the rest unmapped. This can be changed when
      there are userspace consumers for more telephony usages.
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      f3dddf24