14 May, 2020

2 commits

  • commit dcce8ef8f70a8e38e6c47c1bae8b312376c04420 upstream.

    The state of the center button was not reported to userspace for the
    2nd-gen Intuos Pro S when used over Bluetooth due to the pad handling
    code not being updated to support its reduced number of buttons. This
    patch uses the actual number of buttons present on the tablet to
    assemble a button state bitmap.

    Link: https://github.com/linuxwacom/xf86-input-wacom/issues/112
    Fixes: cd47de45b855 ("HID: wacom: Add 2nd gen Intuos Pro Small support")
    Signed-off-by: Jason Gerecke
    Cc: stable@vger.kernel.org # v5.3+
    Signed-off-by: Jiri Kosina
    Signed-off-by: Greg Kroah-Hartman

    Jason Gerecke
     
  • commit b43f977dd281945960c26b3ef67bba0fa07d39d9 upstream.

    This reverts commit 15893fa40109f5e7c67eeb8da62267d0fdf0be9d.

    The referenced commit broke pen and touch input for a variety of devices
    such as the Cintiq Pro 32. Affected devices may appear to work normally
    for a short amount of time, but eventually loose track of actual touch
    state and can leave touch arbitration enabled which prevents the pen
    from working. The commit is not itself required for any currently-available
    Bluetooth device, and so we revert it to correct the behavior of broken
    devices.

    This breakage occurs due to a mismatch between the order of collections
    and the order of usages on some devices. This commit tries to read the
    contact count before processing events, but will fail if the contact
    count does not occur prior to the first logical finger collection. This
    is the case for devices like the Cintiq Pro 32 which place the contact
    count at the very end of the report.

    Without the contact count set, touches will only be partially processed.
    The `wacom_wac_finger_slot` function will not open any slots since the
    number of contacts seen is greater than the expectation of 0, but we will
    still end up calling `input_mt_sync_frame` for each finger anyway. This
    can cause problems for userspace separate from the issue currently taking
    place in the kernel. Only once all of the individual finger collections
    have been processed do we finally get to the enclosing collection which
    contains the contact count. The value ends up being used for the *next*
    report, however.

    This delayed use of the contact count can cause the driver to loose track
    of the actual touch state and believe that there are contacts down when
    there aren't. This leaves touch arbitration enabled and prevents the pen
    from working. It can also cause userspace to incorrectly treat single-
    finger input as gestures.

    Link: https://github.com/linuxwacom/input-wacom/issues/146
    Signed-off-by: Jason Gerecke
    Reviewed-by: Aaron Armstrong Skomra
    Fixes: 15893fa40109 ("HID: wacom: generic: read the number of expected touches on a per collection basis")
    Cc: stable@vger.kernel.org # 5.3+
    Signed-off-by: Jiri Kosina
    Signed-off-by: Greg Kroah-Hartman

    Jason Gerecke
     

01 Feb, 2020

1 commit

  • [ Upstream commit fe4e940f0f91b4a506f048b42e00386f5ad322b6 ]

    A new PID is in use for repaired MobileStudio Pro devices. Add it to the
    list of devices that need special-casing in wacom_wac_pad_event.

    Signed-off-by: Jason Gerecke
    Signed-off-by: Benjamin Tissoires
    Signed-off-by: Sasha Levin

    Jason Gerecke
     

07 Nov, 2019

1 commit

  • The HID descriptors for most Wacom devices oddly declare the serial
    number and other related fields as signed integers. When these numbers
    are ingested by the HID subsystem, they are automatically sign-extended
    into 32-bit integers. We treat the fields as unsigned elsewhere in the
    kernel and userspace, however, so this sign-extension causes problems.
    In particular, the sign-extended tool ID sent to userspace as ABS_MISC
    does not properly match unsigned IDs used by xf86-input-wacom and libwacom.

    We introduce a function 'wacom_s32tou' that can undo the automatic sign
    extension performed by 'hid_snto32'. We call this function when processing
    the serial number and related fields to ensure that we are dealing with
    and reporting the unsigned form. We opt to use this method rather than
    adding a descriptor fixup in 'wacom_hid_usage_quirk' since it should be
    more robust in the face of future devices.

    Ref: https://github.com/linuxwacom/input-wacom/issues/134
    Fixes: f85c9dc678 ("HID: wacom: generic: Support tool ID and additional tool types")
    CC: # v4.10+
    Signed-off-by: Jason Gerecke
    Reviewed-by: Aaron Armstrong Skomra
    Signed-off-by: Jiri Kosina

    Jason Gerecke
     

23 Sep, 2019

1 commit


05 Sep, 2019

1 commit


20 Aug, 2019

3 commits

  • Some Wacom devices have keys with predefined meanings. However, when
    support was originally added for these devices, the codes for these
    keys were not available yet. These keys were thus reported with
    the numbered KEY_PROG* range.

    Some missing key codes were added with commit 4eb220cb35a9 ("HID:
    wacom: generic: add 3 tablet touch keys") and we are now able to
    report the proper key codes. We continue to report the original
    KEY_PROG codes so as not to break any unknown applications that
    may depend on them.

    Also, to support the touch key, track its state in the pad report.

    Signed-off-by: Aaron Armstrong Skomra
    Link: https://gitlab.freedesktop.org/libinput/libinput/merge_requests/155
    Link: https://github.com/linuxwacom/xf86-input-wacom/pull/46
    Reviewed-by: Ping Cheng
    Reviewed-by: Jason Gerecke
    Signed-off-by: Jiri Kosina

    Aaron Armstrong Skomra
     
  • Addresses a few issues that were noticed when compiling with non-default
    warnings enabled. The trimmed-down warnings in the order they are fixed
    below are:

    * declaration of 'size' shadows a parameter

    * '%s' directive output may be truncated writing up to 5 bytes into a
    region of size between 1 and 64

    * pointer targets in initialization of 'char *' from 'unsigned char *'
    differ in signedness

    * left shift of negative value

    Signed-off-by: Jason Gerecke
    Reviewed-by: Aaron Armstrong Skomra
    Signed-off-by: Jiri Kosina

    Jason Gerecke
     
  • The EKR ring claims a range of 0 to 71 but actually reports
    values 1 to 72. The ring is used in relative mode so this
    change should not affect users.

    Signed-off-by: Aaron Armstrong Skomra
    Fixes: 72b236d60218f ("HID: wacom: Add support for Express Key Remote.")
    Cc: # v4.3+
    Reviewed-by: Ping Cheng
    Reviewed-by: Jason Gerecke
    Signed-off-by: Jiri Kosina

    Aaron Armstrong Skomra
     

19 Aug, 2019

1 commit

  • Distance values reported by 2nd-gen Intuos tablets are on an inverted
    scale (0 == far, 63 == near). We need to change them over to a normal
    scale before reporting to userspace or else userspace drivers and
    applications can get confused.

    Ref: https://github.com/linuxwacom/input-wacom/issues/98
    Fixes: eda01dab53 ("HID: wacom: Add four new Intuos devices")
    Signed-off-by: Jason Gerecke
    Cc: # v4.4+
    Signed-off-by: Jiri Kosina

    Jason Gerecke
     

13 Aug, 2019

1 commit


05 Aug, 2019

1 commit

  • The bit indicating BTN_6 on this device is overshifted
    by 2 bits, resulting in the incorrect button being
    reported.

    Also fix copy-paste mistake in comments.

    Signed-off-by: Aaron Armstrong Skomra
    Reviewed-by: Ping Cheng
    Link: https://github.com/linuxwacom/xf86-input-wacom/issues/71
    Fixes: c7f0522a1ad1 ("HID: wacom: Slim down wacom_intuos_pad processing")
    Cc: # v4.5+
    Signed-off-by: Jiri Kosina

    Aaron Armstrong Skomra
     

10 Jul, 2019

1 commit


02 Jul, 2019

1 commit


26 Jun, 2019

1 commit


13 Jun, 2019

5 commits

  • Pull HID fixes from Jiri Kosina:

    - regression fixes (reverts) for module loading changes that turned out
    to be incompatible with some userspace, from Benjamin Tissoires

    - regression fix for special Logitech unifiying receiver 0xc52f, from
    Hans de Goede

    - a few device ID additions to logitech driver, from Hans de Goede

    - fix for Bluetooth support on 2nd-gen Wacom Intuos Pro, from Jason
    Gerecke

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid:
    HID: logitech-dj: Fix 064d:c52f receiver support
    Revert "HID: core: Call request_module before doing device_add"
    Revert "HID: core: Do not call request_module() in async context"
    Revert "HID: Increase maximum report size allowed by hid_field_extract()"
    HID: a4tech: fix horizontal scrolling
    HID: hyperv: Add a module description line
    HID: logitech-hidpp: Add support for the S510 remote control
    HID: multitouch: handle faulty Elo touch device
    HID: wacom: Sync INTUOSP2_BT touch state after each frame if necessary
    HID: wacom: Correct button numbering 2nd-gen Intuos Pro over Bluetooth
    HID: wacom: Send BTN_TOUCH in response to INTUOSP2_BT eraser contact
    HID: wacom: Don't report anything prior to the tool entering range
    HID: wacom: Don't set tool type until we're in range
    HID: rmi: Use SET_REPORT request on control endpoint for Acer Switch 3 and 5
    HID: logitech-hidpp: add support for the MX5500 keyboard
    HID: logitech-dj: add support for the Logitech MX5500's Bluetooth Mini-Receiver
    HID: i2c-hid: add iBall Aer3 to descriptor override

    Linus Torvalds
     
  • Bluetooth connections may contain more than one set of touches,
    or a partial set of touches, in one report.

    Set the number of expected touches when reading a collection
    instead of once per report (in the pre-report function).

    Accordingly, reset the number of touches expected after each sync.

    Signed-off-by: Aaron Armstrong Skomra
    Signed-off-by: Jiri Kosina

    Aaron Armstrong Skomra
     
  • Finger data is separated into chunks in our Bluetooth report,
    where each report contains the same number of chunks. Those chunks
    are not aligned in any particular way to a set of finger touches.
    That is, the first half of a group of simultaneous touches may
    be in one chunk at the end of a report and the second half could
    be at the beginning of the next report.

    Also some chunks contain no data and potentially some chunks could
    contain leftover (bad) data.

    Introduce and process the WACOM_HID_WT_REPORT_VALID usage that the
    device uses to let us know if we should process a chunk of data.

    Signed-off-by: Aaron Armstrong Skomra
    Signed-off-by: Jiri Kosina

    Aaron Armstrong Skomra
     
  • In the generic code path, HID_DG_CONTACTMAX was previously
    only read from the second byte of report 0x23.

    Another report (0x82) has the HID_DG_CONTACTMAX in the
    higher nibble of the third byte. We should support reading the
    value of HID_DG_CONTACTMAX no matter what report we are reading
    or which position that value is in.

    To do this we submit the feature report as a event report
    using hid_report_raw_event(). Our modified finger event path
    records the value of HID_DG_CONTACTMAX when it sees that usage.

    Fixes: 8ffffd5212846 ("HID: wacom: fix timeout on probe for some wacoms")
    Signed-off-by: Aaron Armstrong Skomra
    Signed-off-by: Jiri Kosina

    Aaron Armstrong Skomra
     
  • The existing INTUOSP2_BT device class supports LEDs and this device
    does not. A new device class enum entry, "INTUOSP2S_BT", is created
    to avoid the INTUOSP2_BT LED code.

    Signed-off-by: Aaron Armstrong Skomra
    Reviewed-by: Jason Gerecke
    Signed-off-by: Jiri Kosina

    Aaron Armstrong Skomra
     

31 May, 2019

1 commit

  • Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 of the license or at
    your option any later version

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-or-later

    has been chosen to replace the boilerplate/reference in 3029 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

18 May, 2019

3 commits

  • The Bluetooth interface of the 2nd-gen Intuos Pro batches together four
    independent "frames" of finger data into a single report. Each frame
    is essentially equivalent to a single USB report, with the up-to-10
    fingers worth of information being spread across two frames. At the
    moment the driver only calls `input_sync` after processing all four
    frames have been processed, which can result in the driver sending
    multiple updates for a single slot within the same SYN_REPORT. This
    can confuse userspace, so modify the driver to sync more often if
    necessary (i.e., after reporting the state of all fingers).

    Fixes: 4922cd26f03c ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface")
    Cc: # 4.11+
    Signed-off-by: Jason Gerecke
    Signed-off-by: Benjamin Tissoires

    Jason Gerecke
     
  • The button numbering of the 2nd-gen Intuos Pro is not consistent between
    the USB and Bluetooth interfaces. Over USB, the HID_GENERIC codepath
    enumerates the eight ExpressKeys first (BTN_0 - BTN_7) followed by the
    center modeswitch button (BTN_8). The Bluetooth codepath, however, has
    the center modeswitch button as BTN_0 and the the eight ExpressKeys as
    BTN_1 - BTN_8. To ensure userspace button mappings do not change
    depending on how the tablet is connected, modify the Bluetooth codepath
    to report buttons in the same order as USB.

    To ensure the mode switch LED continues to toggle in response to the
    mode switch button, the `wacom_is_led_toggled` function also requires
    a small update.

    Link: https://github.com/linuxwacom/input-wacom/pull/79
    Fixes: 4922cd26f03c ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface")
    Cc: # 4.11+
    Signed-off-by: Jason Gerecke
    Reviewed-by: Aaron Skomra
    Signed-off-by: Benjamin Tissoires

    Jason Gerecke
     
  • The Bluetooth reports from the 2nd-gen Intuos Pro have separate bits for
    indicating if the tip or eraser is in contact with the tablet. At the
    moment, only the tip contact bit controls the state of the BTN_TOUCH
    event. This prevents the eraser from working as expected. This commit
    changes the driver to send BTN_TOUCH whenever either the tip or eraser
    contact bit is set.

    Fixes: 4922cd26f03c ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface")
    Cc: # 4.11+
    Signed-off-by: Jason Gerecke
    Reviewed-by: Aaron Skomra
    Signed-off-by: Benjamin Tissoires

    Jason Gerecke
     

17 May, 2019

5 commits

  • If the tool spends some time in prox before entering range, a series of
    events (e.g. ABS_DISTANCE, MSC_SERIAL) can be sent before we or userspace
    have any clue about the pen whose data is being reported. We need to hold
    off on reporting anything until the pen has entered range. Since we still
    want to report events that occur "in prox" after the pen has *left* range
    we use 'wacom-tool[0]' as the indicator that the pen did at one point
    enter range and provide us/userspace with tool type and serial number
    information.

    Fixes: a48324de6d4d ("HID: wacom: Bluetooth IRQ for Intuos Pro should handle prox/range")
    Cc: # 4.11+
    Signed-off-by: Jason Gerecke
    Reviewed-by: Aaron Armstrong Skomra
    Signed-off-by: Benjamin Tissoires

    Jason Gerecke
     
  • The serial number and tool type information that is reported by the tablet
    while a pen is merely "in prox" instead of fully "in range" can be stale
    and cause us to report incorrect tool information. Serial number, tool
    type, and other information is only valid once the pen comes fully in range
    so we should be careful to not use this information until that point.

    In particular, this issue may cause the driver to incorectly report
    BTN_TOOL_RUBBER after switching from the eraser tool back to the pen.

    Fixes: a48324de6d4d ("HID: wacom: Bluetooth IRQ for Intuos Pro should handle prox/range")
    Cc: # 4.11+
    Signed-off-by: Jason Gerecke
    Reviewed-by: Aaron Armstrong Skomra
    Signed-off-by: Benjamin Tissoires

    Jason Gerecke
     
  • This affects the 2nd-gen Intuos Pro Medium and Large
    when using their Bluetooth connection.

    Fixes: 4922cd26f03c ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface")
    Cc: # v4.11+
    Signed-off-by: Aaron Armstrong Skomra
    Reviewed-by: Jason Gerecke
    Signed-off-by: Jiri Kosina

    Aaron Armstrong Skomra
     
  • Only sync the pad once per report, not once per collection.
    Also avoid syncing the pad on battery reports.

    Fixes: f8b6a74719b5 ("HID: wacom: generic: Support multiple tools per report")
    Cc: # v4.17+
    Signed-off-by: Aaron Armstrong Skomra
    Signed-off-by: Jiri Kosina

    Aaron Armstrong Skomra
     
  • Currently, the driver will attempt to set the mode on all
    devices with a center button, but some devices with a center
    button lack LEDs, and attempting to set the LEDs on devices
    without LEDs results in the kernel error message of the form:

    "leds input8::wacom-0.1: Setting an LED's brightness failed (-32)"

    This is because the generic codepath erroneously assumes that the
    BUTTON_CENTER usage indicates that the device has LEDs, the
    previously ignored TOUCH_RING_SETTING usage is a more accurate
    indication of the existence of LEDs on the device.

    Fixes: 10c55cacb8b2 ("HID: wacom: generic: support LEDs")
    Cc: # v4.11+
    Signed-off-by: Aaron Armstrong Skomra
    Reviewed-by: Jason Gerecke
    Signed-off-by: Jiri Kosina

    Aaron Armstrong Skomra
     

21 Feb, 2019

1 commit

  • Wacom has introduced a new pen compatible with its MobileStudio Pro and
    other tablets. Although adding it to the tool ID tablet is not strictly
    necessary unrecognized pens are reported as BTN_TOOL_PEN already, unless
    the tablet sends the "eraser" bit, when BTN_TOOL_RUBBER is used instead),
    we'll keep it updated anyway.

    Signed-off-by: Jason Gerecke
    Signed-off-by: Benjamin Tissoires

    Jason Gerecke
     

15 Feb, 2019

1 commit

  • In preparation to enabling -Wimplicit-fallthrough, mark switch
    cases where we are expecting to fall through.

    This patch fixes the following warning:

    drivers/hid/wacom_wac.c: In function ‘wacom_setup_pen_input_capabilities’:
    drivers/hid/wacom_wac.c:3506:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
    __clear_bit(ABS_MISC, input_dev->absbit);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    drivers/hid/wacom_wac.c:3508:2: note: here
    case WACOM_MO:
    ^~~~

    Warning level 3 was used: -Wimplicit-fallthrough=3

    This patch is part of the ongoing efforts to enable
    -Wimplicit-fallthrough.

    Signed-off-by: Gustavo A. R. Silva
    Acked-by: Ping Cheng
    Signed-off-by: Jiri Kosina

    Gustavo A. R. Silva
     

29 Jan, 2019

1 commit

  • The 'wacom_hid_usage_quirk' function is the intended home for fixing
    up descriptors that are buggy or that don't quite fit the mold. Commit
    578325120e was supposed to move all of these quirks but it missed the
    code to handle fixup the serial number usages for AES pens. Lets move
    this code out of 'wacom_wac_pen_usage_mapping' where it was previously
    lurking and put it into the same place as the others.

    Signed-off-by: Jason Gerecke
    Signed-off-by: Benjamin Tissoires

    Jason Gerecke
     

11 Oct, 2018

1 commit

  • The DTK-2451 and DTH-2452 have a buggy HID descriptor which incorrectly
    contains a Cintiq-like report, complete with pen tilt, rotation, twist, serial
    number, etc. The hardware doesn't actually support this data but our driver
    duitifully sets up the device as though it does. To ensure userspace has a
    correct view of devices without updated firmware, we clean up this incorrect
    data in wacom_setup_device_quirks.

    We're also careful to clear the WACOM_QUIRK_TOOLSERIAL flag since its presence
    causes the driver to wait for serial number information (via
    wacom_wac_pen_serial_enforce) that never comes, resulting in
    the pen being non-responsive.

    Signed-off-by: Jason Gerecke
    Fixes: 8341720642 ("HID: wacom: Queue events with missing type/serial data for later processing")
    Cc: stable@vger.kernel.org # v4.16+
    Signed-off-by: Jiri Kosina

    Jason Gerecke
     

21 Aug, 2018

1 commit


03 Jul, 2018

2 commits

  • The touch sensors on the 2nd-gen Intuos tablets don't use a 4096x4096
    sensor like other similar tablets (3rd-gen Bamboo, Intuos5, etc.).
    The incorrect maximum XY values don't normally affect userspace since
    touch input from these devices is typically relative rather than
    absolute. It does, however, cause problems when absolute distances
    need to be measured, e.g. for gesture recognition. Since the resolution
    of the touch sensor on these devices is 10 units / mm (versus 100 for
    the pen sensor), the proper maximum values can be calculated by simply
    dividing by 10.

    Fixes: b5fd2a3e92 ("Input: wacom - add support for three new Intuos devices")
    Signed-off-by: Jason Gerecke
    Signed-off-by: Jiri Kosina

    Jason Gerecke
     
  • Detecting the number of supported touches for a particular device used
    to be tricky, both because early forms of the driver didn't have a very
    good HID parser and because early hardware didn't always advertise the
    actual number. At the time, we added a block of code which would ensure
    that touch_max would always be equal to at least 1 on any touch device,
    and relied on setting touch_max to e.g. 2 only for the multitouch-capable
    exceptions.

    The common case has since flipped, and the driver and descriptors can
    reliably detect the number of touches supported by modern sensors.
    Because of this, it makes sense to remove the fixup code and instead
    place static declarations of "touch_max = 1" for these old devices. It
    isn't entirely clear if all 2-finger devices actually report a maximum
    number of touches so we leave these declarations still in place.

    For the eagle-eyed, the "> BAMBOO_PT" condition was originally equivalent
    to ">= TABLETPC", which is what the intent was. This commit doesn't have
    to consider the types introduced in the interim since they shouldn't be
    affected, hence why only the tablet PC definitions have been modified.

    Signed-off-by: Jason Gerecke
    Reviewed-by: Ping Cheng
    Signed-off-by: Jiri Kosina

    Jason Gerecke
     

22 May, 2018

1 commit

  • The 1st-generation Intuos tablets (CTL-X80) include an "in range" flag
    like some professional tablets. To ensure the pen remains usable at as
    large as distance as possible (and to preemptively disable touch when
    it is nearby) we need to ensure that we handle these "in range" events.
    Handling of tool type identification has been moved to occur only when
    the pen is fully in prox rather than any time the "stylus_in_proximity"
    flag changes (which is controlled by the further-out "in range" flag).

    Link: https://sourceforge.net/p/linuxwacom/bugs/358/
    Link: https://github.com/linuxwacom/xf86-input-wacom/issues/14
    Link: https://github.com/linuxwacom/xf86-input-wacom/issues/17
    Signed-off-by: Jason Gerecke
    Tested-by: Ping Cheng
    Signed-off-by: Jiri Kosina

    Jason Gerecke
     

12 Apr, 2018

1 commit


07 Mar, 2018

2 commits