1. 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
  2. 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
  3. 22 May, 2018 1 commit
  4. 12 Apr, 2018 1 commit
  5. 07 Mar, 2018 4 commits
  6. 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
  7. 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
  8. 09 Nov, 2017 1 commit
  9. 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
  10. 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
  11. 06 Sep, 2017 3 commits
  12. 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
  13. 27 Jun, 2017 1 commit
  14. 05 May, 2017 6 commits
    • Jason Gerecke's avatar
      HID: wacom: generic: Refactor generic battery handling · 5ac3d4ae
      Jason Gerecke authored
      Generic battery handling code is spread between the pen and pad codepaths
      since battery usages may appear in reports for either. This makes it
      difficult to concisely see the logic involved. Since battery data is
      not treated like other data (i.e., we report it through the power_supply
      subsystem rather than through the input subsystem), it makes reasonable
      sense to split the functionality out into its own functions.
      
      This commit has the generic battery handling duplicate the same pattern
      that is used by the pen, pad, and touch interfaces. A "mapping" function
      is provided to set up the battery, an "event" function is provided to
      update the battery data, and a "report" function is provided to notify
      the power_supply subsystem after all the data has been read. We look at
      the usage itself rather than its collection to determine if one of the
      battery functions should handle it. Additionally, we unconditionally
      call the "report" function since there is no particularly good way to
      know if a report contained a battery usage; 'wacom_notify_battery()'
      will filter out any duplicate updates, however.
      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>
      5ac3d4ae
    • Jason Gerecke's avatar
      HID: wacom: Add ability to provide explicit battery status info · 16e45989
      Jason Gerecke authored
      At the moment, our driver relies on 'wacom_battery_get_property()' to
      determine the most likely battery state (e.g charging, discharging, or
      full) based on the information available. It is not always possible
      for the function to properly determine this, however. For instance,
      whenever an AES pen leaves proximity the battery state becomes
      indeterminite. This commit adds the ability to provide it with explict
      state information if desired. Whenever explicit state is not required
      (the majority of circumstances), WACOM_POWER_SUPPLY_STATUS_AUTO can
      be used in its place.
      
      Three uses of explicit battery status are added: two wireless disconnect
      paths and the AES case mentioned above.
      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>
      16e45989
    • Jason Gerecke's avatar
      HID: wacom: generic: Report AES battery information · a7758702
      Jason Gerecke authored
      When support for the HID_DG_BATTERYSTRENGTH usage was added for AES devices,
      it appears that the value was read, but never actually forwarded to the
      power_supply subystem for userspace's benefit. Let's correct that.
      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>
      a7758702
    • Jason Gerecke's avatar
      HID: wacom: generic: Ignore HID_DG_BATTERYSTRENTH == 0 · f496c09c
      Jason Gerecke authored
      AES sensors use the value 0 to indicate "not available" rather than
      "completely dead". Such values are often sent for dozens of reports
      while the pen is being brought into proximity and can cause userspace
      to get the wrong impression about the actual battery state.
      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>
      f496c09c
    • Jason Gerecke's avatar
      HID: wacom: generic: Scale battery capacity measurements to percentages · 37d16019
      Jason Gerecke authored
      The power_supply subsystem expects us to provide it with capacity values
      measured in percent. In particular, AES devices (HID_DG_BATTERYSTRENGTH)
      use the range 0-255, which needs to be rescaled. The MobileStudio Pro
      (WACOM_HID_WD_BATTERY_LEVEL) uses the range 0-100, but there's no guarantee
      that future devices will share the same range.
      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>
      37d16019
    • Jason Gerecke's avatar
      HID: wacom: Have wacom_tpc_irq guard against possible NULL dereference · 2ac97f0f
      Jason Gerecke authored
      The following Smatch complaint was generated in response to commit
      2a6cdbdd ("HID: wacom: Introduce new 'touch_input' device"):
      
          drivers/hid/wacom_wac.c:1586 wacom_tpc_irq()
                   error: we previously assumed 'wacom->touch_input' could be null (see line 1577)
      
      The 'touch_input' and 'pen_input' variables point to the 'struct input_dev'
      used for relaying touch and pen events to userspace, respectively. If a
      device does not have a touch interface or pen interface, the associated
      input variable is NULL. The 'wacom_tpc_irq()' function is responsible for
      forwarding input reports to a more-specific IRQ handler function. An
      unknown report could theoretically be mistaken as e.g. a touch report
      on a device which does not have a touch interface. This can be prevented
      by only calling the pen/touch functions are called when the pen/touch
      pointers are valid.
      
      Fixes: 2a6cdbdd ("HID: wacom: Introduce new 'touch_input' device")
      Signed-off-by: default avatarJason Gerecke <jason.gerecke@wacom.com>
      Reviewed-by: default avatarPing Cheng <ping.cheng@wacom.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      2ac97f0f
  15. 20 Apr, 2017 1 commit
    • Jason Gerecke's avatar
      HID: wacom: Override incorrect logical maximum contact identifier · 6f107fab
      Jason Gerecke authored
      It apears that devices designed around Wacom's G11 chipset (e.g. Lenovo
      ThinkPad Yoga 260, Lenovo ThinkPad X1 Yoga, Dell XPS 12 9250, Dell Venue
      8 Pro 5855, etc.) suffer from a common issue in their HID descriptors.
      The logical maximum is not updated for the "Contact Identifier" usage,
      leaving it as just "1" despite these devices being capable of tracking
      far more touches.
      
      Commit 60a22186 began ignoring usages with out-of-range values,
      causing problems for devices based on this chipset. Touches after
      the first will have an out-of-range Contact Identifier, and ignoring
      that usage will cause the kernel to incorrectly slot each finger's
      events (along with all the knock-on userspace effects that entails).
      
      This commit checks for these buggy descriptors and updates the maximum
      where required. Prior chipsets have used "255" as the maximum (and the
      G11, at least, doesn't seem to actually use IDs outside the range of
      1..CONTACTMAX) so continue using this value.
      
      Cc: stable@vger.kernel.org
      Fixes: 60a22186 ("HID: wacom: generic: add support for touchring")
      Signed-off-by: default avatarJason Gerecke <jason.gerecke@wacom.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      6f107fab
  16. 19 Apr, 2017 1 commit
    • Jason Gerecke's avatar
      HID: wacom: Treat HID_DG_TOOLSERIALNUMBER as unsigned · 286f3f47
      Jason Gerecke authored
      Because HID_DG_TOOLSERIALNUMBER doesn't first cast the value recieved from HID
      to an unsigned type, sign-extension rules can cause the value of
      wacom_wac->serial[0] to inadvertently wind up with all 32 of its highest bits
      set if the highest bit of "value" was set.
      
      This can cause problems for Tablet PC devices which use AES sensors and the
      xf86-input-wacom userspace driver. It is not uncommon for AES sensors to send a
      serial number of '0' while the pen is entering or leaving proximity. The
      xf86-input-wacom driver ignores events with a serial number of '0' since it
      cannot match them up to an in-use tool.  To ensure the xf86-input-wacom driver
      does not ignore the final out-of-proximity event, the kernel does not send
      MSC_SERIAL events when the value of wacom_wac->serial[0] is '0'. If the highest
      bit of HID_DG_TOOLSERIALNUMBER is set by an in-prox pen which later leaves
      proximity and sends a '0' for HID_DG_TOOLSERIALNUMBER, then only the lowest 32
      bits of wacom_wac->serial[0] are actually cleared, causing the kernel to send
      an MSC_SERIAL event. Since the 'input_event' function takes an 'int' as
      argument, only those lowest (now-cleared) 32 bits of wacom_wac->serial[0] are
      sent to userspace, causing xf86-input-wacom to ignore the event. If the event
      was the final out-of-prox event, then xf86-input-wacom may remain in a state
      where it believes the pen is in proximity and refuses to allow other devices
      under its control (e.g. the touchscreen) to move the cursor.
      
      It should be noted that EMR devices and devices which use both the
      HID_DG_TOOLSERIALNUMBER and WACOM_HID_WD_SERIALHI usages (in that order) would
      be immune to this issue. It appears only AES devices are affected.
      
      Fixes: f85c9dc6 ("HID: wacom: generic: Support tool ID and additional tool types")
      Cc: stable@vger.kernel.org
      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>
      286f3f47
  17. 06 Apr, 2017 2 commits
  18. 30 Mar, 2017 1 commit
  19. 21 Mar, 2017 2 commits
  20. 06 Mar, 2017 1 commit