Commit Graph

47 Commits

Author SHA1 Message Date
Hans de Goede fb4f8f568a Input: elantech - don't set bit 1 of reg_10 when the no_hw_res quirk is set
The touchpad on the GIGABYTE U2442 not only stops communicating when we try
to set bit 3 (enable real hardware resolution) of reg_10, but on some BIOS
versions also when we set bit 1 (enable two finger mode auto correct).

I've asked the original reporter of:
https://bugzilla.kernel.org/show_bug.cgi?id=61151

To check that not setting bit 1 does not lead to any adverse effects on his
model / BIOS revision, and it does not, so this commit fixes the touchpad
not working on these versions by simply never setting bit 1 for laptop
models with the no_hw_res quirk.

Reported-and-tested-by: James Lademann <jwlademann@gmail.com>
Tested-by: Philipp Wolfer <ph.wolfer@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2014-06-07 23:20:23 -07:00
Hans de Goede cd9e83e275 Input: elantech - deal with clickpads reporting right button events
At least the Dell Vostro 5470 elantech *clickpad* reports right button
clicks when clicked in the right bottom area:

https://bugzilla.redhat.com/show_bug.cgi?id=1103528

This is different from how (elantech) clickpads normally operate, normally
no matter where the user clicks on the pad the pad always reports a left
button event, since there is only 1 hardware button beneath the path.

It looks like Dell has put 2 buttons under the pad, one under each bottom
corner, causing this.

Since this however still clearly is a real clickpad hardware-wise, we still
want to report it as such to userspace, so that things like finger movement
in the bottom area can be properly ignored as it should be on clickpads.

So deal with this weirdness by simply mapping a right click to a left click
on elantech clickpads. As an added advantage this is something which we can
simply do on all elantech clickpads, so no need to add special quirks for
this weird model.

Reported-and-tested-by: Elder Marco <eldermarco@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2014-06-07 23:20:23 -07:00
Hans de Goede 36189cc3cd Input: elantech - fix touchpad initialization on Gigabyte U2442
The hw_version 3 Elantech touchpad on the Gigabyte U2442 does not accept
0x0b as initialization value for r10, this stand-alone version of the
driver: http://planet76.com/drivers/elantech/psmouse-elantech-v6.tar.bz2

Uses 0x03 which does work, so this means not setting bit 3 of r10 which
sets: "Enable Real H/W Resolution In Absolute mode"

Which will result in half the x and y resolution we get with that bit set,
so simply not setting it everywhere is not a solution. We've been unable to
find a way to identify touchpads where setting the bit will fail, so this
patch uses a dmi based blacklist for this.

https://bugzilla.kernel.org/show_bug.cgi?id=61151

Cc: stable@vger.kernel.org
Reported-by: Philipp Wolfer <ph.wolfer@gmail.com>
Tested-by: Philipp Wolfer <ph.wolfer@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2014-05-05 12:34:22 -07:00
Jordan Rife ae4bedf067 Input: elantech - add support for newer elantech touchpads
Newer elantech touchpads are not recognized by the current driver, since it
fails to detect their firmware version number. This prevents more advanced
touchpad features from being usable such as two-finger scrolling. This
patch allows newer touchpads to be detected and be fully functional. Tested
on Sony Vaio SVF13N17PXB.

Signed-off-by: Jordan Rife <jrife0@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2014-04-22 22:56:41 -07:00
Hans de Goede c15bdfd5b9 Input: elantech - improve clickpad detection
The current assumption in the elantech driver that hw version 3 touchpads
are never clickpads and hw version 4 touchpads are always clickpads is
wrong.

There are several bug reports for this, ie:
https://bugzilla.redhat.com/show_bug.cgi?id=1030802
http://superuser.com/questions/619582/right-elantech-touchpad-button-not-working-in-linux

I've spend a couple of hours wading through various bugzillas, launchpads
and forum posts to create a list of fw-versions and capabilities for
different laptop models to find a good method to differentiate between
clickpads and versions with separate hardware buttons.

Which shows that a device being a clickpad is reliable indicated by bit 12
being set in the fw_version. I've included the gathered list inside the
driver, so that we've this info at hand if we need to revisit this later.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2013-12-18 08:47:29 -08:00
Matt Walker 9cb80b965e Input: elantech - add support for newer (August 2013) devices
Added detection for newer Elantech touchpads, so that kernel doesn't
fall-back to default PS/2 driver. Supports touchpads released after
~August 2013.  Fixes bug:
https://lists.launchpad.net/kernel-packages/msg18481.html

Tested on an Acer Aspire S7-392-6302.

Signed-off by: Matt Walker <matt.g.d.walker@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2013-12-05 12:49:49 -08:00
Matteo Delfino acc0444bf8 Input: elantech - fix packet check for v3 and v4 hardware
The signatures of v3 and v4 packets change depending on the value of a
hardware flag called 'crc_enabled'. The packet type detection must change
accordingly.

This patch also restores a consistency check for v4 packets inadvertently
removed by commit:

9eebed7de6
Input: elantech - fix for newer hardware versions (v7)

A note about the naming convention: v3 hardware is associated with IC body
v5 while v4 hardware is associated with IC body v6 and v7. The above commit
refers to IC body v7, not to v7 hardware.

Tested on Samsung NP730U3E (fw = 0x675f05, ICv7, crc_enabled = 1)

Tested-by: Giovanni Frigione <gio.frigione@gmail.com>
Signed-off-by: Matteo Delfino <kendatsuba@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2013-08-24 17:52:35 -07:00
Matteo Delfino 9eebed7de6 Input: elantech - fix for newer hardware versions (v7)
* Fix version recognition in elantech_set_properties

  The new hardware reports itself as v7 but the packets'
  structure is unaltered.

* Fix packet type recognition in elantech_packet_check_v4

  The bitmask used for v6 is too wide, only the last three bits of
  the third byte in a packet (packet[3] & 0x03) are actually used to
  distinguish between packet types.
  Starting from v7, additional information (to be interpreted) is
  stored in the remaining bits (packets[3] & 0x1c).
  In addition, the value stored in (packet[0] & 0x0c) is no longer
  a constant but contains additional information yet to be deciphered.
  This change should be backwards compatible with v6 hardware.

Additional-author: Giovanni Frigione <gio.frigione@gmail.com>
Signed-off-by: Matteo Delfino <kendatsuba@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2013-07-06 21:57:27 -07:00
Henrik Rydberg b4adbbefc2 Input: MT - Add flags to input_mt_init_slots()
Preparing to move more repeated code into the mt core, add a flags
argument to the input_mt_slots_init() function.

Reviewed-and-tested-by: Benjamin Tissoires <benjamin.tissoires@enac.fr>
Tested-by: Ping Cheng <pingc@wacom.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
2012-09-19 19:50:18 +02:00
JJ Ding e3dde4fba9 Input: elantech - v4 is a clickpad, with only one button
Add pointer and buttonpad properties for v4 hardware.

Also, Jachiet reported that on Asus UX31, right button has no effect.
It turns out v4 has only one button, the right-button effect is
implemented with software when Windows driver is installed, or in
firmware when touchpad is in relative mode. So remove BTN_RIGHT
while at it.

Reported-by: Jachiet Louis <louis@jachiet.com>
Signed-off-by: JJ Ding <jj_ding@emc.com.tw>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2012-04-10 00:40:35 -07:00
JJ Ding a67ada7a72 Input: elantech - reset touchpad before configuring it
Acer VH40 has a Fn key toggling the touchpad on and off, but it's
implemented in system firmware, and the EC chip has to receive
reset command to activate this function. Also when this machine
wakes up after resume, psmouse_reset is necessary to bring the
touchpad back on.

Signed-off-by: JJ Ding <jj_ding@emc.com.tw>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2012-04-10 00:40:31 -07:00
Dmitry Torokhov 0d2cd91bf7 Merge commit 'v3.2-rc3' into next 2011-11-29 01:51:07 -08:00
JJ Ding 3d95fd6ad8 Input: elantech - add resolution query support for v4 hardware
It turns out that v4's firmware provides a command so we can query
the resolution. Let's use it.

Signed-off-by: JJ Ding <jj_ding@emc.com.tw>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-11-20 22:28:34 -08:00
JJ Ding b56b92a9a1 Input: elantech - add support for elantech fast command
Starting with v3 hardware, the firmware supports this shorter
elantech_send_cmd. Teach the driver to use it.

Signed-off-by: JJ Ding <jj_ding@emc.com.tw>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-11-20 22:28:30 -08:00
JJ Ding 76496e7a02 Input: convert obsolete strict_strtox to kstrtox
With commit 67d0a07544 we mark strict_strtox
as obsolete. Convert all remaining such uses in drivers/input/.

Also change long to appropriate types, and return error conditions
from kstrtox separately, as Dmitry sugguests.

Signed-off-by: JJ Ding <dgdunix@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-11-09 21:23:26 -08:00
JJ Ding 3940d6185a Input: elantech - adjust hw_version detection logic
This patch fixes some v3 hardware (fw_version: 0x150500) wrongly detected
as v2 hardware.

Reported-by: Marc Dietrich <marvin24@gmx.de>
Signed-off-by: JJ Ding <jj_ding@emc.com.tw>
Tested-By: Marc Dietrich <marvin24@gmx.de>
Acked-by: Éric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-11-09 21:19:47 -08:00
Dmitry Torokhov b5d2170436 Input: psmouse - switch to using dev_*() for messages
This will ensure our reporting is consistent with the rest of the system
and we do not refer to obsolete source file names.

Reviewed-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: JJ Ding <dgdunix@gmail.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-10-10 18:28:16 -07:00
JJ Ding 4af61e9027 Input: elantech - remove module parameter force_elantech
This essentially reverts commit f81bc788ff.

With recent work on elantech driver, I believe we now have complete support
for all elantech touchpads. So remove this hack.

Signed-off-by: JJ Ding <jj_ding@emc.com.tw>
Reviewed-by: Éric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-09-20 22:46:28 -07:00
JJ Ding 84a90b610a Input: elantech - better support all those v2 variants
V2 hardware has many variants. This patch adddresses two issues:

 - some model also has debounce packets, but with a different signature
   than v3. Now we just check debounce for all v2 hardware.

 - due to different scanning methods the hardware uses, x and y ranges have
   to be calculated differently. And for some specific versions, we can just
   see them as custom-made, so set {x, y} the same values as Windows driver
   does.

Signed-off-by: JJ Ding <jj_ding@emc.com.tw>
Tested-by: Richard Schütz <r.schtz@t-online.de>
Reviewed-by: Éric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-09-20 22:46:27 -07:00
JJ Ding 1dc6edec12 Input: elantech - add v4 hardware support
v4 hardware is a true multitouch capable touchpad (up to 5 fingers).
The packet format is quite complex, please see protocol document for
reference.

Signed-off-by: JJ Ding <jj_ding@emc.com.tw>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-09-09 10:35:02 -07:00
JJ Ding 28f4961611 Input: elantech - add v3 hardware support
v3 hardware's packet format is almost identical to v2 (one/three finger touch),
except when sensing two finger touch, the hardware sends 12 bytes of data.

Signed-off-by: JJ Ding <jj_ding@emc.com.tw>
Acked-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Éric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-09-09 10:34:58 -07:00
JJ Ding 3c8bbb951a Input: elantech - clean up elantech_init
Group property setting code into elantech_set_properties.

Signed-off-by: JJ Ding <jj_ding@emc.com.tw>
Acked-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Éric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-09-09 10:34:55 -07:00
JJ Ding 7894f21b10 Input: elantech - packet checking for v2 hardware
For v2 hardware, there is no real parity check, but we can still check
some constant bits for data integrity.

Also rename elantech_check_parity_v1 to elantech_packet_check_v1 to make
these packet checking function names consistent.

Signed-off-by: JJ Ding <jj_ding@emc.com.tw>
Acked-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Éric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-09-09 10:34:50 -07:00
JJ Ding 230282a77b Input: elantech - use firmware provided x, y ranges
With newer hardware, the touchpad provides range info.
Let's use it.

Signed-off-by: JJ Ding <jj_ding@emc.com.tw>
Acked-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Éric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-09-09 10:34:36 -07:00
JJ Ding 461a791765 Input: elantech - get rid of ETP_2FT_* in elantech.h
For two finger touches the coordinate of each finger gets reported
separately but with reduced resolution.

With this change, we now have the same range for ST and MT data and
scale MT data because it has lower resolution to match ST.

Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: JJ Ding <jj_ding@emc.com.tw>
Acked-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Éric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-09-09 10:34:31 -07:00
JJ Ding 1155961946 Input: elantech - correct x, y value range for v2 hardware
x, y values are actually 12-bit long. Also update protocol document to
reflect the change.

Signed-off-by: JJ Ding <jj_ding@emc.com.tw>
Acked-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Éric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-09-09 10:34:25 -07:00
Éric Piel 9cb6cfae4e Input: elantech - remove support for proprietary X driver
Apparently somewhere someone had a proprietary X driver. To get the
multitouch info, it uses some hack on the normal API instead of using
the multitouch protocol. Now that the multitouch info is transmitted
correctly it makes not much sense to keep it. Especially because it's
impossible to find this proprietary X driver anywhere, so the number of
users must be very low.

Signed-off-by: Éric Piel <eric.piel@tremplin-utc.net>
Reviewed-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-05-16 22:48:43 -07:00
Éric Piel 89eec4d71e Input: elantech - report multitouch with proper ABS_MT messages
Multitouch info was reported only via a old protocol used by the
proprietary X driver from elantech. Let's report the multitouch info
also following the official MT protocol. It's semi-mt because the device
only reports the lowest/highest coordinates.

This was done following the multi-touch-protocol.txt documentation, and
inspired by the bcm5974 and elantech implementations. Testing was light
as there is not many applications using this protocol yet, but the X
synaptics driver didn't complain and the X multitouch driver behaved
correctly.

Signed-off-by: Éric Piel <eric.piel@tremplin-utc.net>
Reviewed-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-05-16 22:48:39 -07:00
Éric Piel f941c705f6 Input: elantech - export pressure and width when supported
Using the info of the Dell/Ubuntu driver, described in the protocol
document, report both width and pressure when pressing 1 and 3
fingers, for the versions of the touchpad which support it.

Signed-off-by: Éric Piel <eric.piel@tremplin-utc.net>
Reviewed-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-05-16 22:48:36 -07:00
Davidlohr Bueso 6792cbbb25 Input: return -ENOMEM in select drivers when memory allocation fails
Instead of using -1 let's start using proper error codes.

Signed-off-by: Davidlohr Bueso <dave@gnu.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2010-10-13 07:49:23 -07:00
Éric Piel 22462d9fcf Input: elantech - report position also with 3 fingers
The 6-byte protocol supports reporting the position when three fingers
are pressed, exactly like when one finger is pressed. Report this.

In addition, it is also distinguishes between 3 and 4 fingers pressed.

Signed-off-by: Éric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2010-08-05 23:53:22 -07:00
Éric Piel 7f29f17b57 Input: elantech - discard the first 2 positions on some firmwares
According to the Dell/Ubuntu driver, what was previously observed as
"jumpy cursor" corresponds to the hardware sending incorrect data for
the first two reports of a one touch finger. So let's use the same
workaround as in the other driver. Also, detect another firmware
version with the same behaviour, as in the other driver.

Signed-off-by: Éric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2010-08-05 23:52:29 -07:00
Dmitry Torokhov a083632eaf Input: elantech - relax signature checks
Apparently there are Elantech touchpads that report non-zero in the 2nd byte
of their signature. Adjust the detection routine so that if 2nd byte is
zero and 3rd byte contains value that is not a valid report rate, we still
assume that signature is valid.

Tested-by: Eric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2010-05-19 10:15:13 -07:00
Dmitry Torokhov d4ae84a84b Input: elantech - enforce common prefix on messages
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2010-05-19 10:15:02 -07:00
Linus Torvalds aa86f26bd8 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: ad7877 - keep dma rx buffers in seperate cache lines
  Input: psmouse - reset all types of mice before reconnecting
  Input: elantech - use all 3 bytes when checking version
  Input: iforce - fix Guillemot Jet Leader 3D entry
  Input: iforce - add Guillemot Jet Leader Force Feedback
2010-05-13 07:28:43 -07:00
Dmitry Torokhov 504e8beed1 Input: elantech - use all 3 bytes when checking version
Apparently all 3 bytes returned by ETP_FW_VERSION_QUERY are significant
and should be taken into account when matching hardware version/features.

Tested-by: Eric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2010-05-13 00:43:19 -07:00
Linus Torvalds 1d7aec3041 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: joydev - allow binding to button-only devices
  Input: elantech - ignore high bits in the position coordinates
  Input: elantech - allow forcing Elantech protocol
  Input: elantech - fix firmware version check
  Input: ati_remote - add some missing devices from lirc_atiusb
  Input: eeti_ts - cancel pending work when going to suspend
  Input: Add support of Synaptics Clickpad device
  Revert "Input: ALPS - add signature for HP Pavilion dm3 laptops"
  Input: psmouse - ignore parity error for basic protocols
2010-05-05 07:53:18 -07:00
Florian Ragwitz e938fbfd4a Input: elantech - ignore high bits in the position coordinates
In older versions of the elantech hardware/firmware those bits always
were unset, so it didn't actually matter, but newer versions seem to
use those high bits for something else, screwing up the coordinates
we report to the input layer for those devices.

Signed-off-by: Florian Ragwitz <rafl@debian.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2010-05-03 23:35:11 -07:00
Florian Ragwitz f81bc788ff Input: elantech - allow forcing Elantech protocol
Apparently hardware vendors now ship elantech touchpads with different version
magic. This options allows for them to be tested easier with the current driver
in order to add their magic to the whitelist later.

Signed-off-by: Florian Ragwitz <rafl@debian.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2010-05-03 23:34:33 -07:00
Florian Ragwitz 225c61aad3 Input: elantech - fix firmware version check
The check determining whether device should use 4- or 6-byte packets
was trying to compare firmware with 2.48, but was failing on majors
greater than 2. The new check ensures that versions like 4.1 are
checked properly.

Signed-off-by: Florian Ragwitz <rafl@debian.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2010-05-03 23:34:13 -07:00
Tejun Heo 5a0e3ad6af include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.

Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-30 22:02:32 +09:00
Dmitry Torokhov c7a1f3ccfc Input: elantech - do not advertise relative events
Elantech touchpads work in absolute mode and do not generate relative
events so they should not be advertising them.

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2009-11-20 00:52:11 -08:00
Dmitry Torokhov b7802c5c1e Input: psmouse - use boolean type
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2009-09-10 22:11:38 -07:00
Arjan Opmeer b2546df69b Input: elantech - make sure touchpad is really in absolute mode
There exist laptops with Elantech touchpads where switching to absolute mode
does not happen, although writing the configuration register succeeds
without error. Reading back the register afterwards reveils that the
absolute mode bit is not set as if masked out by the touchpad firmware.

Always read back register 0x10, make sure that for hardware version 1 the
absolute mode bit is actually set and fail otherwise. This prevents the case
where the touchpad is claimed by the Elantech driver but is nonetheless not
working.

Signed-off-by: Arjan Opmeer <arjan@opmeer.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2009-04-18 19:11:59 -07:00
Arjan Opmeer 3f8c0df43d Input: elantech - provide a workaround for jumpy cursor on firmware 2.34
It seems that Elantech touchpad firmware version 2.34 on the Hercules eCAFÉ
suffers from a problem where bogus coordinates get reported at the beginning
of a touch action. This causes the mouse cursor or the scrolled page to
jump.

Included patch provides a workaround that discards mouse packets that are
likely to contain bogus coordinates. The workaround is activated when we
detect touchpad with fimware version 2.34.

Signed-off-by: Arjan Opmeer <arjan@opmeer.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2009-04-18 19:11:51 -07:00
Arjan Opmeer 9ab7b25e6a Input: elantech - touchpad driver miss-recognising logitech mice
Some Logitech mice react to the magic knock like Elantech touchpad would.
This leads to those mice being misdetected as Elantech touchpads.  Add a
version query to elantech_detect() to distinguish the two.

[dtor@mail.ru:
 - lower severity of some messages - when we are not sure yet if
   device is Elantech or not not responding to knock is not an error.
]

Signed-off-by: Arjan Opmeer <arjan@opmeer.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2009-02-28 14:01:39 -08:00
Arjan Opmeer 2a0bd75e5e Input: psmouse - add support for Elantech touchpads
This is version 5 of the driver. Relative mode support has been
dropped (users wishing to use touchpad in relative mode can use
standard PS/2 protocol emulation done in hardware). The driver
supports both original version of Elantech protocol and the newer
one used by touchpads installed in EeePC.

Signed-off-by: Arjan Opmeer <arjan@opmeer.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2008-10-16 22:54:35 -04:00