All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Ragwitz <rafl@debian.org>
To: linux-input@vger.kernel.org
Subject: Getting recent elantech touchpads to work with synaptics
Date: Sat, 24 Apr 2010 22:40:58 +0200	[thread overview]
Message-ID: <1272141662-23431-1-git-send-email-rafl@debian.org> (raw)

The following 4 patches aim to improve various bits of the the elantech support
in the psmouse driver in order to get it to work with recent elantech firmwares
used in many touchpads of modern laptops. The list of those laptops includes
almost all recent ASUS machines, including the UL{2,3,5,8}0- and and P-series,
but also various others, like many Dell Inspiron machines.

[PATCH 1/4] Input: elantech - Assume all firmware versions >= 2.48 use 6 byte packets

  This patch just fixes a minor thinko in the handling of v1 vs. v2 firmware
  versions.

[PATCH 2/4] Input: Add an option to force the use of the elantech extension

  This adds a force_elantech options to the psmouse module, which allows to
  force the use of the elantech extension if a device responds to the elantech
  magic knock and firmware version request, but the driver doesn't know about
  the particular firmware version yet.

[PATCH 3/4] Input: elantech - Ignore high bits in the position coordinates

  This change is what actually makes things work on new firmwares. The driver
  used to use too many of the bits sent by the device to compute the position
  coordinates. On old versions all those bits were always zero, so it didn't
  actually matter, but new versions apparently reuse the bits for something
  else, screwing up results.

[PATCH 4/4] Input: elantech - Whitelist new models with firmware version 4.1

  This broadens the range of devices which are automatically recognized as
  elantech to include all devices reporting the bytes 0x04 0x01 0x01 upon a
  firmware version request. The check is intentionally rather strict, and I
  assume there's other devices out there, which report slightly different
  versions, but would still work, but given how easy it is to test those
  devices with the force_elantech option, I figured the check could be
  relaxed later, if necessary, and it'd be better to avoid recognizing
  non-elantech devices wrongly.


Those patches are only tested on machines with firmware version 4.1. They
should also be tested on older firmware versions using the 6-byte packet
format, like any ASUS Eee PC, before being applied.

--
BOFH excuse #196:
Me no internet, only janitor, me just wax floors.

             reply	other threads:[~2010-04-24 21:26 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-24 20:40 Florian Ragwitz [this message]
2010-04-24 20:40 ` [PATCH 1/4] Input: elantech - Assume all firmware versions >= 2.48 use 6 byte packets Florian Ragwitz
2010-04-26 14:19   ` Getting recent elantech touchpads to work with synaptics Florian Ragwitz
2010-04-27  7:36     ` Dmitry Torokhov
2010-04-27 14:58       ` Florian Ragwitz
2010-04-27 14:58       ` [PATCH] Update elantech documentation Florian Ragwitz
2010-04-24 20:41 ` [PATCH 2/4] Input: Add an option to force the use of the elantech extension Florian Ragwitz
2010-04-24 20:41 ` [PATCH 3/4] Input: elantech - Ignore high bits in the position coordinates Florian Ragwitz
2010-04-24 20:41 ` [PATCH 4/4] Input: elantech - Whitelist new models with firmware version 4.1 Florian Ragwitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1272141662-23431-1-git-send-email-rafl@debian.org \
    --to=rafl@debian.org \
    --cc=linux-input@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.