- 27 8月, 2014 1 次提交
-
-
由 Ulrik De Bie 提交于
elantech_init() calls elantech_set_absolute_mode which sets the driver in an absolute mode. When after this the elantech_init fails, it is best to turn the ps/2 mouse emulation mode back on by calling psmouse_reset() so that it can work as a regular mouse. Reviewed-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NUlrik De Bie <ulrik.debie-os@e2big.org> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 08 6月, 2014 2 次提交
-
-
由 Hans de Goede 提交于
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: NJames Lademann <jwlademann@gmail.com> Tested-by: NPhilipp Wolfer <ph.wolfer@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Hans de Goede 提交于
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: NElder Marco <eldermarco@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 06 5月, 2014 1 次提交
-
-
由 Hans de Goede 提交于
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: NPhilipp Wolfer <ph.wolfer@gmail.com> Tested-by: NPhilipp Wolfer <ph.wolfer@gmail.com> Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 23 4月, 2014 1 次提交
-
-
由 Jordan Rife 提交于
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: NJordan Rife <jrife0@gmail.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 19 12月, 2013 1 次提交
-
-
由 Hans de Goede 提交于
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: NHans de Goede <hdegoede@redhat.com> Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 06 12月, 2013 1 次提交
-
-
由 Matt Walker 提交于
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: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 25 8月, 2013 1 次提交
-
-
由 Matteo Delfino 提交于
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: 9eebed7d 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: NGiovanni Frigione <gio.frigione@gmail.com> Signed-off-by: NMatteo Delfino <kendatsuba@gmail.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 07 7月, 2013 1 次提交
-
-
由 Matteo Delfino 提交于
* 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: NMatteo Delfino <kendatsuba@gmail.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 20 9月, 2012 1 次提交
-
-
由 Henrik Rydberg 提交于
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: NBenjamin Tissoires <benjamin.tissoires@enac.fr> Tested-by: NPing Cheng <pingc@wacom.com> Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
-
- 10 4月, 2012 2 次提交
-
-
由 JJ Ding 提交于
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: NJachiet Louis <louis@jachiet.com> Signed-off-by: NJJ Ding <jj_ding@emc.com.tw> Reviewed-by: NChase Douglas <chase.douglas@canonical.com> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
由 JJ Ding 提交于
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: NJJ Ding <jj_ding@emc.com.tw> Reviewed-by: NChase Douglas <chase.douglas@canonical.com> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 21 11月, 2011 2 次提交
-
-
由 JJ Ding 提交于
It turns out that v4's firmware provides a command so we can query the resolution. Let's use it. Signed-off-by: NJJ Ding <jj_ding@emc.com.tw> Reviewed-by: NDaniel Kurtz <djkurtz@chromium.org> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
由 JJ Ding 提交于
Starting with v3 hardware, the firmware supports this shorter elantech_send_cmd. Teach the driver to use it. Signed-off-by: NJJ Ding <jj_ding@emc.com.tw> Reviewed-by: NDaniel Kurtz <djkurtz@chromium.org> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 10 11月, 2011 2 次提交
-
-
由 JJ Ding 提交于
With commit 67d0a075 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: NJJ Ding <dgdunix@gmail.com> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
由 JJ Ding 提交于
This patch fixes some v3 hardware (fw_version: 0x150500) wrongly detected as v2 hardware. Reported-by: NMarc Dietrich <marvin24@gmx.de> Signed-off-by: NJJ Ding <jj_ding@emc.com.tw> Tested-By: NMarc Dietrich <marvin24@gmx.de> Acked-by: NÉric Piel <eric.piel@tremplin-utc.net> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 11 10月, 2011 1 次提交
-
-
由 Dmitry Torokhov 提交于
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: NWanlong Gao <gaowanlong@cn.fujitsu.com> Reviewed-by: NJJ Ding <dgdunix@gmail.com> Reviewed-by: NDaniel Kurtz <djkurtz@chromium.org> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 21 9月, 2011 2 次提交
-
-
由 JJ Ding 提交于
This essentially reverts commit f81bc788. With recent work on elantech driver, I believe we now have complete support for all elantech touchpads. So remove this hack. Signed-off-by: NJJ Ding <jj_ding@emc.com.tw> Reviewed-by: NÉric Piel <eric.piel@tremplin-utc.net> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
由 JJ Ding 提交于
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: NJJ Ding <jj_ding@emc.com.tw> Tested-by: NRichard Schütz <r.schtz@t-online.de> Reviewed-by: NÉric Piel <eric.piel@tremplin-utc.net> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 10 9月, 2011 7 次提交
-
-
由 JJ Ding 提交于
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: NJJ Ding <jj_ding@emc.com.tw> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
由 JJ Ding 提交于
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: NJJ Ding <jj_ding@emc.com.tw> Acked-by: NDaniel Kurtz <djkurtz@chromium.org> Acked-by: NÉric Piel <eric.piel@tremplin-utc.net> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
由 JJ Ding 提交于
Group property setting code into elantech_set_properties. Signed-off-by: NJJ Ding <jj_ding@emc.com.tw> Acked-by: NDaniel Kurtz <djkurtz@chromium.org> Acked-by: NÉric Piel <eric.piel@tremplin-utc.net> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
由 JJ Ding 提交于
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: NJJ Ding <jj_ding@emc.com.tw> Acked-by: NDaniel Kurtz <djkurtz@chromium.org> Acked-by: NÉric Piel <eric.piel@tremplin-utc.net> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
由 JJ Ding 提交于
With newer hardware, the touchpad provides range info. Let's use it. Signed-off-by: NJJ Ding <jj_ding@emc.com.tw> Acked-by: NDaniel Kurtz <djkurtz@chromium.org> Acked-by: NÉric Piel <eric.piel@tremplin-utc.net> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
由 JJ Ding 提交于
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: NDmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: NJJ Ding <jj_ding@emc.com.tw> Acked-by: NDaniel Kurtz <djkurtz@chromium.org> Acked-by: NÉric Piel <eric.piel@tremplin-utc.net> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
由 JJ Ding 提交于
x, y values are actually 12-bit long. Also update protocol document to reflect the change. Signed-off-by: NJJ Ding <jj_ding@emc.com.tw> Acked-by: NDaniel Kurtz <djkurtz@chromium.org> Acked-by: NÉric Piel <eric.piel@tremplin-utc.net> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 17 5月, 2011 3 次提交
-
-
由 Éric Piel 提交于
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: NÉric Piel <eric.piel@tremplin-utc.net> Reviewed-by: NHenrik Rydberg <rydberg@euromail.se> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
由 Éric Piel 提交于
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: NÉric Piel <eric.piel@tremplin-utc.net> Reviewed-by: NHenrik Rydberg <rydberg@euromail.se> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
由 Éric Piel 提交于
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: NÉric Piel <eric.piel@tremplin-utc.net> Reviewed-by: NHenrik Rydberg <rydberg@euromail.se> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 13 10月, 2010 1 次提交
-
-
由 Davidlohr Bueso 提交于
Instead of using -1 let's start using proper error codes. Signed-off-by: NDavidlohr Bueso <dave@gnu.org> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 06 8月, 2010 2 次提交
-
-
由 Éric Piel 提交于
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: NÉric Piel <eric.piel@tremplin-utc.net> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
由 Éric Piel 提交于
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: NÉric Piel <eric.piel@tremplin-utc.net> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 20 5月, 2010 2 次提交
-
-
由 Dmitry Torokhov 提交于
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: NEric Piel <eric.piel@tremplin-utc.net> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
由 Dmitry Torokhov 提交于
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 13 5月, 2010 1 次提交
-
-
由 Dmitry Torokhov 提交于
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: NEric Piel <eric.piel@tremplin-utc.net> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 04 5月, 2010 3 次提交
-
-
由 Florian Ragwitz 提交于
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: NFlorian Ragwitz <rafl@debian.org> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
由 Florian Ragwitz 提交于
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: NFlorian Ragwitz <rafl@debian.org> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
由 Florian Ragwitz 提交于
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: NFlorian Ragwitz <rafl@debian.org> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 30 3月, 2010 1 次提交
-
-
由 Tejun Heo 提交于
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: NTejun Heo <tj@kernel.org> Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
-
- 20 11月, 2009 1 次提交
-
-
由 Dmitry Torokhov 提交于
Elantech touchpads work in absolute mode and do not generate relative events so they should not be advertising them. Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-