Skip to content

L
linux
Switch branch/tag
  1. 13 Apr, 2015 2 commits
  3. 10 Apr, 2015 3 commits
  5. 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
  7. 05 Apr, 2015 1 commit
  9. 02 Apr, 2015 8 commits
  11. 27 Mar, 2015 1 commit
  13. 25 Mar, 2015 2 commits
  15. 17 Mar, 2015 1 commit
  17. 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
  19. 15 Mar, 2015 2 commits
  21. 12 Mar, 2015 1 commit
  23. 11 Mar, 2015 9 commits
  25. 06 Mar, 2015 1 commit
  27. 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
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7