26 Jan, 2017

1 commit

  • commit 864db9295b06837d11a260e5dacf99a3fdf6bce2 upstream.

    The current Alps SS5 (SS4 v2) code generates bogus TouchPad events when
    TrackStick packets are processed.

    This causes the xorg synaptics driver to print
    "unable to find touch point 0" and
    "BUG: triggered 'if (priv->num_active_touches > priv->num_slots)'"
    messages. It also causes unexpected TouchPad button release and re-click
    event sequences if the TrackStick is moved while holding a TouchPad
    button.

    This commit corrects the problem by adjusting alps_process_packet_ss4_v2()
    so that it only sends TrackStick reports when processing TrackStick
    packets.

    Reviewed-by: Pali Rohár
    Signed-off-by: Paul Donohue
    Signed-off-by: Dmitry Torokhov
    Signed-off-by: Greg Kroah-Hartman

    Paul Donohue
     

17 Nov, 2016

1 commit

  • BYD automatic protocol detection is extremely unreliable and is often
    triggers false positives on regular mice, Sentelic touchpads, and other
    devices. BYD has several documents that have recommended detection
    sequence, but they conflict with each other and, as far as I can see, still
    would not produce unique enough output to reliably differentiate BYD from
    other PS/2 devices.

    OEMs sourcing BYD devices also do not do us any favors by not supplying any
    reasonable DMI data and instead leaving turds like "To Be Filled By O.E.M."
    in place of vendor data, or "System Serial Number" as serial number.

    On top of that BYD is not truly modern multitouch controller, but rather a
    single-touch transitional device that only reports absolute coordinates at
    the beginning of finger contact and then reverts to reporting
    displacements, and thus not very precise; the only benefit from using BYD
    mode vs the legacy PS/2 mode is possibility of edge scrolling.

    Given the above, and the fact that BYD devices are somewhat uncommon, let's
    disable automatic detection of BYD devices. Users who know they have BYD
    trackpads or want to experiment can attempt to activate BYD protocol via
    sysfs:

    echo -n "byd" > /sys/bus/serio/devices/serio1/drvctl

    Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=151691
    Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=175421
    Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=120781
    Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=121281
    Fixes: 98ee37714493 ("Input: byd - add BYD PS/2 touchpad driver")
    Cc: stable@vger.kernel.org # 4.6+
    Reviewed-by: Pali Rohár
    Signed-off-by: Dmitry Torokhov

    Dmitry Torokhov
     

25 Oct, 2016

1 commit

  • psmouse->name "Focaltech Touchpad" is an overkill. In xinput it is too long
    as "FocaltechPS/2 Focaltech Focaltech Touchpad"

    In focaltech_report_state() pointer to psmouse->dev is already stored as
    *dev

    Signed-off-by: Dmitry Tunin
    Signed-off-by: Dmitry Torokhov

    Dmitry Tunin
     

08 Oct, 2016

1 commit


05 Oct, 2016

4 commits


04 Oct, 2016

3 commits


06 Sep, 2016

1 commit

  • We get 1 warning when building kernel with W=1:
    drivers/input/mouse/focaltech.c:393:6: warning: no previous prototype for 'focaltech_set_resolution' [-Wmissing-prototypes]

    In fact, this function is only used in the file in which it is
    declared and don't need a declaration, but can be made static.
    So this patch marks it 'static'.

    Signed-off-by: Baoyou Xie
    Acked-by: Arnd Bergmann
    Signed-off-by: Dmitry Torokhov

    Baoyou Xie
     

26 Aug, 2016

1 commit

  • alloc_ordered_workqueue() replaces the deprecated
    create_singlethread_workqueue().

    There are multiple work items on the work queue viz
    &priv->dev3_register_work, &priv->recalib_wq, &psmouse->resync_work,
    which require execution ordering. Hence, an ordered workqueue has been
    used.

    The workqueue is not being used on a memory reclaim path. Hence,
    WQ_MEM_RECLAIM has not been set.

    Signed-off-by: Bhaktipriya Shridhar
    Acked-by: Tejun Heo
    Signed-off-by: Dmitry Torokhov

    Bhaktipriya Shridhar
     

03 Aug, 2016

2 commits

  • Some ASUS laptops were shipped with touchpads that require to be woken up
    first, before trying to switch them into absolute reporting mode, otherwise
    touchpad would fail to work while flooding the logs with:

    elan_i2c i2c-ELAN1000:00: invalid report id data (1)

    Among affected devices are Asus E202SA, N552VW, X456UF, UX305CA, and
    others. We detect such devices by checking the IC type and product ID
    numbers and adjusting order of operations accordingly.

    Signed-off-by: KT Liao
    Reported-by: Chris Chiu
    Reported-by: Vlad Glagolev
    Tested-by: Vlad Glagolev
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov

    KT Liao
     
  • The use of mixed psmouse_printk() and printk creates 2 lines in the log,
    while the use of %*ph solves everything.

    Signed-off-by: Benjamin Tissoires
    Signed-off-by: Dmitry Torokhov

    Benjamin Tissoires
     

20 Jul, 2016

1 commit


24 Jun, 2016

2 commits

  • The VMWare EFI BIOS will expose port 0x5658 as an ACPI resource. This
    causes the port to be reserved by the APCI module as the system comes up,
    making it unavailable to be reserved again by other drivers, thus
    preserving this VMWare port for special use in a VMWare guest.

    This port is designed to be shared among multiple VMWare services, such as
    the VMMOUSE. Because of this, VMMOUSE should not try to reserve this port
    on its own.

    The VMWare non-EFI BIOS does not do this to preserve compatibility with
    existing/legacy VMs. It is known that there is small chance a VM may be
    configured such that these ports get reserved by other non-VMWare devices,
    and if this ever happens, the result is undefined.

    Signed-off-by: Sinclair Yeh
    Reviewed-by: Thomas Hellstrom
    Cc: # 4.1-
    Signed-off-by: Dmitry Torokhov

    Sinclair Yeh
     
  • The touchpad in HP Pavilion 14-ab057ca reports it's version as 12 and
    according to Elan both 11 and 12 are valid IC types and should be
    identified as hw_version 4.

    Reported-by: Patrick Lessard
    Tested-by: Patrick Lessard
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov

    Dmitry Torokhov
     

19 Jun, 2016

1 commit


17 May, 2016

1 commit


10 May, 2016

1 commit


30 Apr, 2016

1 commit


18 Mar, 2016

2 commits

  • Looks like the fimware 8.2 still has the extra buttons spurious release
    bug.

    Link: https://bugzilla.kernel.org/show_bug.cgi?id=114321
    Cc: stable@vger.kernel.org
    Signed-off-by: Benjamin Tissoires
    Signed-off-by: Dmitry Torokhov

    Benjamin Tissoires
     
  • The Windows driver's settings dialog contains a visualization of the
    regions for the hardware edge scrolling capability, which uses a
    temporarily-enabled limited-resolution absolute mode.

    This patch enables this during normal operation, and combines the
    absolute packets with the existing relative packets to provide
    accurate absolute position and touch reporting.

    It also adds documentation for all known gesture packets and
    initialization commands.

    Reviewed-by: Chris Diamand
    Signed-off-by: Richard Pospesel
    Signed-off-by: Dmitry Torokhov

    Richard Pospesel
     

16 Mar, 2016

1 commit


05 Mar, 2016

2 commits

  • Bring in updates to roraty encoder driver switching it away from legacy
    platform data and over to generic device properties and adding support
    for encoders using more than 2 GPIOs.

    Dmitry Torokhov
     
  • When changing the scan rate as part of runtime-resume process we may lose
    some of the events, because:

    1) for gen3 trackpads, the driver must msleep() some time to ensure that
    the device is ready to accept next command;

    2) for gen5 and later trackpads, the queue dumping function will simply
    ignore the events when waiting for the set power mode command response.

    The solution is to keep polling and report those valid events when the set
    power mode command is in progress.

    Signed-off-by: Dudley Du
    Tested-by: Jeremiah Mahler
    Signed-off-by: Dmitry Torokhov

    Dudley Du
     

28 Jan, 2016

2 commits

  • Driver for the BYD BTP10463 touchpad, found in PC Specialist `Lafite'
    laptops. This patch sends the magic command sequence which causes the
    touchpad to stream intellimouse-style packets.

    Gestures are detected inside the touchpad, and exposed as special
    values in the Z component of each packet - absolute coordinates are
    not supported, even in the Windows driver. At present, this supports
    two-finger vertical and horizontal scrolling, and provides the
    framework to expose the other gestures it can recognize.

    Signed-off-by: Chris Diamand
    Signed-off-by: Dmitry Torokhov

    Chris Diamand
     
  • We should set device's capabilities first, and then register it,
    otherwise various handlers already present in the kernel will not be
    able to connect to the device.

    Reported-by: Lauri Kasanen
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov

    Dmitry Torokhov
     

12 Jan, 2016

2 commits

  • Prepare first round of input updates for 4.5 merge window.

    Dmitry Torokhov
     
  • When using a protocol v2 or v3 hardware, elantech uses the function
    elantech_report_semi_mt_data() to report data. This devices are rather
    creepy because if num_finger is 3, (x2,y2) is (0,0). Yes, only one valid
    touch is reported.

    Anyway, userspace (libinput) is now confused by these (0,0) touches,
    and detect them as palm, and rejects them.

    Commit 3c0213d17a09 ("Input: elantech - fix semi-mt protocol for v3 HW")
    was sufficient enough for xf86-input-synaptics and libinput before it has
    palm rejection. Now we need to actually tell libinput that this device is
    a semi-mt one and it should not rely on the actual values of the 2 touches.

    Cc: stable@vger.kernel.org
    Signed-off-by: Benjamin Tissoires
    Signed-off-by: Dmitry Torokhov

    Benjamin Tissoires
     

07 Jan, 2016

2 commits

  • This patch moves v3 pinnacle code for trackstick detection from
    alps_hw_init_v3() to alps_set_protocol() so ALPS_DUALPOINT flag can be
    cleared before registering trackstick input device in kernel.

    Signed-off-by: Pali Rohár
    Acked-by: Hans de Goede
    Signed-off-by: Dmitry Torokhov

    Pali Rohár
     
  • This patch adds detection of trackstick for v7 protocol devices. Code in
    this patch is used in official Dell touchpad linux drivers for Dell models:
    Dell Latitude E5250/5250, E5450/5450, E5550/5550

    Detection code and base reg for alps v3 rushmore and v7 devices is exacly
    same.

    Also user in bug https://bugzilla.kernel.org/show_bug.cgi?id=94801 reported
    that Toshiba Sattellite Z30-A-1DG has only alps v7 touchpad device without
    trackstick and kernel reports to userspace also redundant trackstick
    device.

    Signed-off-by: Pali Rohár
    Reviewed-by: Hans de Goede
    Tested-by: Alex Hung
    Signed-off-by: Dmitry Torokhov

    Pali Rohár
     

18 Dec, 2015

7 commits

  • Bring in changes to limit number of protocols we try on pass-though PS/2
    ports so that probe ocmpletes faster.

    Dmitry Torokhov
     
  • This makes Logitech PS2++ protocol implementation consistent with
    the naming in other protocols. Also mark the stub as "static inline"

    Reviewed-by: Hans de Goede
    Tested-by: Marcin Sochacki
    Tested-by: Till
    Signed-off-by: Dmitry Torokhov

    Dmitry Torokhov
     
  • PS/2 protocol is slow, and using it with pass-through port (where we
    encapsulate PS/2 into PS/2) is slower yet so it takes quite a bit of time
    to do full protocol discovery for device attached to a pass-through port.
    However, so far we have not see anything but trackpoints or basic PS/2
    mice on pass-through ports, so let's limit protocols that we probe there
    to Trackpoint, IntelliMouse Explorer, IntelliMouse, and bare PS/2 protocol,
    and avoid other extended protocols, such as Synaptics, ALPS, etc.

    Reviewed-by: Hans de Goede
    Reviewed-by: Pali Rohár
    Tested-by: Marcin Sochacki
    Tested-by: Till
    Signed-off-by: Dmitry Torokhov

    Dmitry Torokhov
     
  • In preparation of limiting protocols that we try on pass-through ports,
    let's rework initialization code and factor common code into
    psmouse_try_protocol() that accepts protocol type (instead of detec()
    function pointer) and can, for most protocols, perform both detection and
    initialization.

    Note that this removes option of forcing Lifebook protocol on devices that
    are not recognized by lifebook_detect() as having the hardware, but I do
    not recall anyone using this option.

    Reviewed-by: Hans de Goede
    Tested-by: Marcin Sochacki
    Tested-by: Till
    Signed-off-by: Dmitry Torokhov

    Dmitry Torokhov
     
  • We move protocol descriptions and psmouse_find_by_type() and
    pmouse_find_by_name() so that we can use them without forward declarations
    in the subsequent patches.

    Reviewed-by: Hans de Goede
    Reviewed-by: Pali Rohár
    Tested-by: Marcin Sochacki
    Tested-by: Till
    Signed-off-by: Dmitry Torokhov

    Dmitry Torokhov
     
  • When Cypress protocol support is disabled cypress_init() is a stub that
    always returns -ENOSYS, so there is not point in testing for
    CONFIG_MOUSE_PS2_CYPRESS after we decided that we are dealing with a
    Cypress device. Also, we should only be calling cypress_detect() when
    set_properties argument is "true", like with other protocols.

    There is a slight change in behavior to make follow-up patches more
    uniform: when we detect Cypress but its initialization fails, instead of
    immediately returning PSMOUSE_PS2 protocol we now continue trying
    IntelliMouse [Explorer]. Given that Cypress devices only have issue with
    Sentelic probes probing Imtellimouse should be safe.

    Reviewed-by: Hans de Goede
    Tested-by: Marcin Sochacki
    Tested-by: Till
    Signed-off-by: Dmitry Torokhov

    Dmitry Torokhov
     
  • The fact that we were calling focaltech_init() even when Focaltech support
    is disabled was confusing. Rearrange the code so that if support is
    disabled we continue to fall through the rest of protocol probing code
    until we get to full reset that Focaltech devices need to work properly.

    Also, replace focaltech_init() with a stub now that it is only called when
    protocol is enabled.

    Reviewed-by: Hans de Goede
    Reviewed-by: Pali Rohár
    Tested-by: Marcin Sochacki
    Tested-by: Till
    Signed-off-by: Dmitry Torokhov

    Dmitry Torokhov