14 Apr, 2015

1 commit


10 Apr, 2015

1 commit

  • In the unlikely case of hdev vanishing while hid_debug_events_read() was
    sleeping, we can't really break out of the case switch as with other cases,
    as on the way out we'll try to remove ourselves from the hdev waitqueue.

    Fix this by taking a shortcut exit path and avoiding cleanup that doesn't
    make sense in case hdev doesn't exist any more anyway.

    Reported-by: Jiri Slaby
    Signed-off-by: Jiri Kosina

    Jiri Kosina
     

07 Apr, 2015

1 commit

  • 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=88903

    Signed-off-by: Benjamin Tissoires
    Acked-by: Dmitry Torokhov
    Signed-off-by: Jiri Kosina

    Benjamin Tissoires
     

06 Apr, 2015

1 commit

  • Return a negative error code on failure.

    A simplified version of the semantic match that finds this problem is as
    follows: (http://coccinelle.lip6.fr/)

    //
    @@
    identifier ret; expression e1,e2;
    @@
    (
    if (\(ret < 0\|ret != 0\))
    { ... return ret; }
    |
    ret = 0
    )
    ... when != ret = e1
    when != &ret
    *if(...)
    {
    ... when != ret = e2
    when forall
    return ret;
    }
    //

    Signed-off-by: Julia Lawall
    Reviewed-by: Benjamin Tissoires
    Signed-off-by: Jiri Kosina

    Julia Lawall
     

02 Apr, 2015

8 commits


27 Mar, 2015

1 commit


25 Mar, 2015

2 commits


18 Mar, 2015

1 commit

  • 486b908 (HID: wacom: do not send pen events before touch is up/forced out)
    introduces a kernel oops when plugging a tablet without touch.

    wacom->shared is null for these devices so this leads to a null pointer
    exception.

    Change the condition to make it clear that what we need is wacom->shared
    not NULL.

    Signed-off-by: Benjamin Tissoires
    Signed-off-by: Jiri Kosina

    Benjamin Tissoires
     

17 Mar, 2015

1 commit

  • 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: Benjamin Tissoires
    Acked-by: Jason Gerecke
    Signed-off-by: Jiri Kosina

    Benjamin Tissoires
     

16 Mar, 2015

4 commits

  • This driver didn't exist until before v3.19.
    Why would suddenly everybody want to build it?

    Signed-off-by: Stefan Richter
    Signed-off-by: Jiri Kosina

    Stefan Richter
     
  • 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: Jim Keir
    Signed-off-by: Jiri Kosina

    Jim Keir
     
  • 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: Jean Delvare
    Signed-off-by: Jiri Kosina

    Jean Delvare
     
  • 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: Benjamin Tissoires
    Signed-off-by: Jiri Kosina

    Benjamin Tissoires
     

15 Mar, 2015

2 commits


12 Mar, 2015

3 commits

  • According to [1], Windows Precision Touchpad devices must supply
    a button type usage in the device capabilities feature report. A
    value of 0 indicates that the device contains a depressible
    button (i.e. it's a click-pad) whereas a value of 1 indicates
    a non-depressible button. Add support for this usage and set
    INPUT_PROP_BUTTONPAD on the touchpad input device whenever a
    depressible button is present.

    [1] https://msdn.microsoft.com/en-us/library/windows/hardware/dn467314(v=vs.85).aspx

    Signed-off-by: Seth Forshee
    Reviewed-by: Benjamin Tissoires
    Signed-off-by: Jiri Kosina

    Seth Forshee
     
  • 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: Jason Gerecke
    Signed-off-by: Jiri Kosina

    Jason Gerecke
     
  • This device disconnects every 60s without X

    Signed-off-by: Oliver Neukum
    Signed-off-by: Jiri Kosina

    oliver@neukum.org
     

11 Mar, 2015

7 commits


07 Mar, 2015

1 commit


05 Mar, 2015

2 commits

  • 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: Dmitry Torokhov
    Signed-off-by: Jiri Kosina

    Dmitry Torokhov
     
  • In commit 08177f4 (HID: uclogic: merge hid-huion driver in hid-uclogic)
    HID_HUION depends explicitely on USB_HID because it contained quite some
    USB-isms.

    Now that hid-uclogic is the new home of Huion tablets, we need to also
    add the dependency on USB_HID to this driver.

    Reported-by: Jiri Kosina
    Reported-by: kbuild test robot
    Signed-off-by: Benjamin Tissoires
    Signed-off-by: Jiri Kosina

    Benjamin Tissoires
     

04 Mar, 2015

4 commits