1. 05 Jun, 2015 2 commits
  2. 02 Jun, 2015 1 commit
  3. 22 May, 2015 2 commits
    • Marek Vasut's avatar
      Input: smtpe-ts - wait 50mS until polling for pen-up · 77b071e7
      Marek Vasut authored
      Wait a little bit longer, 50mS instead of 20mS, until the driver starts
      polling for pen-up. The problematic behavior before this patch is applied
      is as follows. The behavior was observed on the STMPE610QTR controller.
      
      Upon a physical pen-down event, the touchscreen reports one set of x-y-p
      coordinates and a pen-down event. After that, the pen-up polling is
      triggered and since the controller is not ready yet, the polling mistakenly
      detects a pen-up event while the physical state is still such that the pen
      is down on the touch surface.
      
      The pen-up handling flushes the controller FIFO, so after that, all the
      samples in the controller are discarded. The controller becomes ready
      shortly after this bogus pen-up handling and does generate again a pen-down
      interrupt. This time, the controller contains x-y-p samples which all read
      as zero. Since pressure value is zero, this set of samples is effectively
      ignored by userland.
      
      In the end, the driver just bounces between pen-down and bogus pen-up
      handling, generating no useful results. Fix this by giving the controller a
      bit more time before polling it for pen-up.
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Reviewed-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      77b071e7
    • Marek Vasut's avatar
      Input: smtpe-ts - use msecs_to_jiffies() instead of HZ · e686e9e1
      Marek Vasut authored
      Use msecs_to_jiffies(20) instead of plain (HZ / 50), as the former is much
      more explicit about it's behavior. We want to schedule the task 20 mS from
      now, so make it explicit in the code.
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Reviewed-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      e686e9e1
  4. 21 May, 2015 1 commit
  5. 20 May, 2015 2 commits
  6. 13 May, 2015 2 commits
  7. 21 Apr, 2015 1 commit
  8. 20 Apr, 2015 5 commits
  9. 15 Apr, 2015 3 commits
  10. 14 Apr, 2015 4 commits
  11. 12 Apr, 2015 2 commits
    • Hans de Goede's avatar
      Input: alps - non interleaved V2 dualpoint has separate stick button bits · 92bac83d
      Hans de Goede authored
      Non interleaved V2 dualpoint touchpad / stick combos have separate stick
      button bits in the touchpad packets, if we do not check these then the
      trackpoint buttons will not work when using the touchpad, and when pressed
      when the user starts using the touchpad will report a release event even
      though the button is still pressed.
      
      This commit fixes this by checking the separate bits, note that we simply
      combine the buttons, since the hardware does the same when using the touchpad
      buttons with the trackpoint, so we do not have enough information to properly
      separate them.
      Reported-by: default avatarHans de Bruin <jmdebruin@xmsnet.nl>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      92bac83d
    • Hans de Goede's avatar
      Input: alps - fix touchpad buttons getting stuck when used with trackpoint · 6bcca19f
      Hans de Goede authored
      When the left touchpad button gets pressed, and then the trackpoint is
      moved, and then the button is released, the following happens:
      
      1) touchpad packet is received, touchpad evdev node reports BTN_LEFT 1
      
      2) pointing stick packet is received, the hw will report a BTN_LEFT 1 in
         this packet because when the trackstick is active it communicates the
         combined touchpad + pointing stick buttons in the trackstick packet,
         since alps_report_bare_ps2_packet passes NULL (*) for the dev2 parameter
         to alps_report_buttons the combining is not detected and the
         pointing stick evdev node will also report BTN_LEFT 1
      
      3) on release of the button a pointing stick packet with BTN_LEFT 0 is
         received and the pointing stick evdev node will report BTN_LEFT 0
      
      Note how because of the passing as NULL for dev2 the touchpad evdev node
      will never send BTN_LEFT 0 in this scenario leading to a stuck mouse button.
      
      This is a regression in 4.0 introduced by commit 04aae283
      ("Input: ALPS - do not mix trackstick and external PS/2 mouse data")
      
      This commit fixes this by passing in the touchpad evdev as dev2 parameter
      when calling alps_report_buttons for the pointingstick on alps v2 devices,
      so that alps_report_buttons correctly detect that we're already reporting
      the button as pressed via the touchpad evdev node, and will also send the
      release event there.
      
      Cc: stable@vger.kernel.org # 4.0
      Reported-by: default avatarHans de Bruin <jmdebruin@xmsnet.nl>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Acked-by: default avatarPali Rohár <pali.rohar@gmail.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      6bcca19f
  12. 11 Apr, 2015 2 commits
  13. 07 Apr, 2015 4 commits
  14. 06 Apr, 2015 9 commits