1. 30 May, 2019 1 commit
  2. 17 May, 2019 5 commits
  3. 20 Feb, 2019 1 commit
  4. 15 Feb, 2019 1 commit
    • Gustavo A. R. Silva's avatar
      HID: wacom: Mark expected switch fall-through · 1da92d43
      Gustavo A. R. Silva authored
      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: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Acked-by: default avatarPing Cheng <ping.cheng@wacom.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      1da92d43
  5. 29 Jan, 2019 1 commit
  6. 11 Oct, 2018 1 commit
    • Jason Gerecke's avatar
      HID: wacom: Work around HID descriptor bug in DTK-2451 and DTH-2452 · 11db8173
      Jason Gerecke authored
      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: default avatarJason Gerecke <jason.gerecke@wacom.com>
      Fixes: 83417206 ("HID: wacom: Queue events with missing type/serial data for later processing")
      Cc: stable@vger.kernel.org # v4.16+
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      11db8173
  7. 03 Jul, 2018 2 commits
    • Jason Gerecke's avatar
      HID: wacom: Correct touch maximum XY of 2nd-gen Intuos · 3b8d5735
      Jason Gerecke authored
      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: b5fd2a3e ("Input: wacom - add support for three new Intuos devices")
      Signed-off-by: default avatarJason Gerecke <jason.gerecke@wacom.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      3b8d5735
    • Jason Gerecke's avatar
      HID: wacom: Replace touch_max fixup code with static touch_max definitions · 29b9e148
      Jason Gerecke authored
      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: default avatarJason Gerecke <jason.gerecke@wacom.com>
      Reviewed-by: default avatarPing Cheng <ping.cheng@wacom.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      29b9e148
  8. 22 May, 2018 1 commit
  9. 12 Apr, 2018 1 commit
  10. 07 Mar, 2018 4 commits
  11. 23 Jan, 2018 2 commits
    • Jason Gerecke's avatar
      HID: wacom: Add support for One by Wacom (CTL-472 / CTL-672) · c9472189
      Jason Gerecke authored
      Adds support for the second-generation "One by Wacom" tablets. These
      devices are similar to the last generation, but a slightly different size
      and reporting a higher number of pressure levels.
      Signed-off-by: default avatarMx Jing <jingmingxuan@outlook.com>
      Signed-off-by: default avatarJason Gerecke <jason.gerecke@wacom.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      c9472189
    • Jason Gerecke's avatar
      HID: wacom: Fix reporting of touch toggle (WACOM_HID_WD_MUTE_DEVICE) events · 403c0f68
      Jason Gerecke authored
      Touch toggle softkeys send a '1' while pressed and a '0' while released,
      requring the kernel to keep track of wether touch should be enabled or
      disabled. The code does not handle the state transitions properly,
      however. If the key is pressed repeatedly, the following four states
      of states are cycled through (assuming touch starts out enabled):
      
      Press:   shared->is_touch_on => 0, SW_MUTE_DEVICE => 1
      Release: shared->is_touch_on => 0, SW_MUTE_DEVICE => 1
      Press:   shared->is_touch_on => 1, SW_MUTE_DEVICE => 0
      Release: shared->is_touch_on => 1, SW_MUTE_DEVICE => 1
      
      The hardware always properly enables/disables touch when the key is
      pressed but applications that listen for SW_MUTE_DEVICE events to provide
      feedback about the state will only ever show touch as being enabled while
      the key is held, and only every-other time. This sequence occurs because
      the fallthrough WACOM_HID_WD_TOUCHONOFF case is always handled, and it
      uses the value of the *local* is_touch_on variable as the value to
      report to userspace. The local value is equal to the shared value when
      the button is pressed, but equal to zero when the button is released.
      
      Reporting the shared value to userspace fixes this problem, but the
      fallthrough case needs to update the shared value in an incompatible
      way (which is why the local variable was introduced in the first place).
      To work around this, we just handle both cases in a single block of code
      and update the shared variable as appropriate.
      
      Fixes: d793ff81 ("HID: wacom: generic: support touch on/off softkey")
      Cc: <stable@vger.kernel.org> # v4.12+
      Signed-off-by: default avatarJason Gerecke <jason.gerecke@wacom.com>
      Reviewed-by: default avatarAaron Skomra <aaron.skomra@wacom.com>
      Tested-by: default avatarAaron Skomra <aaron.skomra@wacom.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      403c0f68
  12. 21 Nov, 2017 2 commits
    • Jason Gerecke's avatar
      HID: wacom: Queue events with missing type/serial data for later processing · 83417206
      Jason Gerecke authored
      Userspace expects to receive tool type and serial number information
      for the active pen in the very first kernel report, if such data is
      supported by the hardware. While this expectation is not an issue for
      EMR devices, AES sensors will often send several packets worth of in-
      range data before relaying type/serial data to the kernel. Sending this
      data "late" can result in proximity-tracking issues by xf86-input-wacom,
      or an inability to distinguish different pens by input-wacom.
      
      Options for dealing with this situation include ignoring reports from
      the tablet until we get the necessary data, or using the information
      from the last-seen pen instead of the (eventual) real data. Neither
      option is particularly attractive: the former results in truncated
      strokes and the latter causes issues with switching between pens.
      
      This commit instead opts to queue up events with missing information
      until we receive a report which contains it. At that point, we can
      update the driver's state variables (id[0] and serial[0]) and replay
      the queued events.
      Signed-off-by: default avatarJason Gerecke <jason.gerecke@wacom.com>
      Reviewed-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      83417206
    • Jason Gerecke's avatar
      HID: wacom: Properly handle AES serial number and tool type · 99acedad
      Jason Gerecke authored
      Current AES sensors relay tool type and serial number information with
      a different set of usages than those prescribed by the modern (i.e.
      MobileStudio Pro and newer) EMR tablet standard. To ensure the driver
      properly understands these usages, we modify them to be compatible.
      The identifying information is split across three consecutive fields:
      a 16-bit WACOM_HID_WT_SERIALNUMBER (which is more accurately described
      as WACOM_HID_WD_TOOLTYPE), a 32-bit HID_DG_TOOLSERIALNUMBER, and an
      8-bit 0xFF000000 (which should be WACOM_HID_WD_SERIALHI). While we're
      at it, we also define proper min/max values since may may be undefined
      on some devices.
      Signed-off-by: default avatarJason Gerecke <jason.gerecke@wacom.com>
      Reviewed-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      99acedad
  13. 09 Nov, 2017 1 commit
  14. 11 Oct, 2017 1 commit
    • Jason Gerecke's avatar
      Revert "HID: wacom: generic: Send BTN_TOOL_PEN in prox once the pen enters range" · 2f84723d
      Jason Gerecke authored
      This reverts commit 3e70969e.
      
      This commit causes a few problems for userspace. The most noteworthy are
      problems related to the distinguishing of different pens and pointer jumps
      when entering proximity. Userspace is written with the expectation that a
      pen will provide its tool ID and serial number (if available) in the very
      first in-prox report. By sending BTN_TOOL_PEN when the tablet starts
      communicating rather than waiting until a tool ID/serial number is
      available, userspace ends up treating all pens as being the same and
      lacking a serial number. Similarly, userspace assumes that the first
      report will contain X/Y data, but by marking the pen as being in-prox
      without an X/Y coordinate, userspace ends up warping the pen to the last-
      known X/Y location. As of commit 5b40104e ("HID: wacom: generic: Reset
      events back to zero when pen leaves") this means warping to (0,0).
      Signed-off-by: default avatarJason Gerecke <jason.gerecke@wacom.com>
      Acked-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      2f84723d
  15. 13 Sep, 2017 6 commits
    • Jason Gerecke's avatar
      HID: wacom: generic: Reset events back to zero when pen leaves · 5b40104e
      Jason Gerecke authored
      As a pen leaves, we need to be sure to reset all events back to zero
      so that userspace is able to get the complete pen state when it enters
      proximity again.
      Signed-off-by: default avatarJason Gerecke <jason.gerecke@wacom.com>
      Reviewed-by: default avatarPing Cheng <ping.cheng@wacom.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      5b40104e
    • Jason Gerecke's avatar
      HID: wacom: generic: Send BTN_TOOL_PEN in prox once the pen enters range · 3e70969e
      Jason Gerecke authored
      When a pen is first able to to be sensed by the tablet, we would like
      to inform userspace that a tool is nearby so that it can attempt to
      perform palm rejection. Unfortunately, we don't know any information
      about the tool that is nearby, so the best we can do is send a prox
      event for a generic BTN_TOOL_PEN. If the pen later comes closer and
      enters proximity, we can determine the actual tool type and send
      BTN_TOOL_PEN out of prox if necessary.
      Signed-off-by: default avatarPing Cheng <ping.cheng@wacom.com>
      Signed-off-by: default avatarJason Gerecke <jason.gerecke@wacom.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      3e70969e
    • Jason Gerecke's avatar
      HID: wacom: generic: Leave tool in prox until it completely leaves sense · 4affc233
      Jason Gerecke authored
      The legacy Intuos codepath and tablet behavior (e.g. the 1st-gen Intuos
      Pro, Cintiq 27, etc.) would result in a BTN_TOOL_* event not being cleared
      to zero until the tool had completely left the sensing range of the
      tablet. Before the final "out of prox" packet would be sent, zero or
      more "in range" packets could be sent to indicate that a pen was still
      detectable but not within a useful distance. These "in range" packets
      were used by the driver to keep touch input disabled at greater pen
      distances. In addition to keeping the `stylus_in_proximity` flag set,
      the driver would leave the current BTN_TOOL_* marked as being in
      proximity as well.
      
      The new HID codepath also sets `stylus_in_proximity` based on the "sense"
      flag, but does not leave the current BTN_TOOL_* marked as being in prox.
      This information is potentially useful to for a future userspace-based
      palm rejection, so this patch modifies the driver to continue sending it.
      Signed-off-by: default avatarJason Gerecke <jason.gerecke@wacom.com>
      Reviewed-by: default avatarPing Cheng <ping.cheng@wacom.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      4affc233
    • Jason Gerecke's avatar
      HID: wacom: generic: Use generic codepath terminology in wacom_wac_pen_report · 7690dd18
      Jason Gerecke authored
      The terminology used to describe the various degrees of pen proximity
      within the wacom_wac_pen_report function does not match that used elsewhere
      in the generic codepath. Specifically, the names of the variables "prox"
      and "range" were inspired by the non-generic codepaths. To make the generic
      codepath internally consistent, replace these terms with "range" and "sense"
      respectively.
      Signed-off-by: default avatarJason Gerecke <jason.gerecke@wacom.com>
      Signed-off-by: default avatarPing Cheng <ping.cheng@wacom.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      7690dd18
    • Jason Gerecke's avatar
      HID: wacom: generic: Clear ABS_MISC when tool leaves proximity · 92380b57
      Jason Gerecke authored
      The tool ID information sent in ABS_MISC is expected to be reset to 0
      when a tool leaves proximity. Not doing this can cause problems if a
      tool is removed and then re-introduced. Kernel event filtering will
      prevent the (identical) ABS_MISC event from being sent when the tool
      re-enters proxmity. This can cause userspace to not properly set the
      tool ID.
      
      Fixes: f85c9dc6 ("HID: wacom: generic: Support tool ID and additional tool types")
      Cc: stable # v4.10 <stable@vger.kernel.org>
      Signed-off-by: default avatarPing Cheng <ping.cheng@wacom.com>
      Signed-off-by: default avatarJason Gerecke <jason.gerecke@wacom.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      92380b57
    • Jason Gerecke's avatar
      HID: wacom: generic: Send MSC_SERIAL and ABS_MISC when leaving prox · 993f0d93
      Jason Gerecke authored
      The latest generation of pro devices (MobileStudio Pro, 2nd-gen Intuos
      Pro, Cintiq Pro) send a serial number of '0' whenever the pen is too far
      away for reliable communication. Userspace defines that a serial number
      of '0' is invalid, so we need to be careful not to actually forward
      this value. Additionally, since EMR ISDv4 devices do not support serial
      numbers or tool IDs, we'd like to not send these events if they aren't
      necessary.
      
      The existing code achieves these goals by adding a check for a non-zero
      serial number within the wacom_wac_pen_report function. The MSC_SERIAL
      and ABS_MISC events are only sent if the serial number is non-zero. This
      code fails, however when the pen for a pro device leaves proximity. When
      the pen leaves prox and the tablet sends a serial of 0, wacom_wac_pen_event
      dutifully clears the serial number. When wacom_wac_pen_report is called,
      it does not send either the MSC_SERIAL of the exiting tool nor an ABS_MISC
      event.
      
      This patch prevents the wacom_wac_pen_event function from clearing an
      already-set serial number. This ensures that we have the serial number
      handy when exiting proximity, but requires us to manually clear it
      afterwards to ensure the driver does not send stale data (e.g. when
      switching between AES pens that report a serial nubmer of 0 for the
      first few fully in-proximity packets).
      
      Fixes: f85c9dc6 ("HID: wacom: generic: Support tool ID and additional tool types")
      Cc: stable # v4.10 <stable@vger.kernel.org>
      Signed-off-by: default avatarPing Cheng <ping.cheng@wacom.com>
      Signed-off-by: default avatarJason Gerecke <jason.gerecke@wacom.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      993f0d93
  16. 06 Sep, 2017 3 commits
  17. 08 Aug, 2017 1 commit
    • Jason Gerecke's avatar
      HID: wacom: Do not completely map WACOM_HID_WD_TOUCHRINGSTATUS usage · 8d411cbf
      Jason Gerecke authored
      The WACOM_HID_WD_TOUCHRINGSTATUS usage is a single bit which tells us
      whether the touchring is currently in use or not. Because we need to
      reset the axis value to 0 when the finger is removed, we call
      'wacom_map_usage' to ensure that the required type/code values are
      associated with the usage. The 'wacom_map_usage' also sets up the axis
      range and resolution, however, which is not desired in this particular
      case.
      
      Although xf86-input-wacom doesn't do really do anything with the ring's
      range or resolution, the libinput driver (for Wayland environments)
      uses these values to provide proper angle indications to userspace.
      
      Fixes: 60a22186 ("HID: wacom: generic: add support for touchring")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJason Gerecke <jason.gerecke@wacom.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      8d411cbf
  18. 27 Jun, 2017 1 commit
  19. 05 May, 2017 5 commits