2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* Synaptics TouchPad PS/2 mouse driver
|
|
|
|
*
|
|
|
|
* 2003 Dmitry Torokhov <dtor@mail.ru>
|
|
|
|
* Added support for pass-through port. Special thanks to Peter Berg Larsen
|
|
|
|
* for explaining various Synaptics quirks.
|
|
|
|
*
|
|
|
|
* 2003 Peter Osterlund <petero2@telia.com>
|
|
|
|
* Ported to 2.5 input device infrastructure.
|
|
|
|
*
|
|
|
|
* Copyright (C) 2001 Stefan Gmeiner <riddlebox@freesurf.ch>
|
|
|
|
* start merging tpconfig and gpm code to a xfree-input module
|
|
|
|
* adding some changes and extensions (ex. 3rd and 4th button)
|
|
|
|
*
|
|
|
|
* Copyright (c) 1997 C. Scott Ananian <cananian@alumni.priceton.edu>
|
|
|
|
* Copyright (c) 1998-2000 Bruce Kalk <kall@compass.com>
|
|
|
|
* code for the special synaptics commands (from the tpconfig-source)
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify it
|
|
|
|
* under the terms of the GNU General Public License version 2 as published by
|
|
|
|
* the Free Software Foundation.
|
|
|
|
*
|
|
|
|
* Trademarks are the property of their respective owners.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/module.h>
|
2011-12-12 08:05:53 +00:00
|
|
|
#include <linux/delay.h>
|
2009-12-04 07:21:14 +00:00
|
|
|
#include <linux/dmi.h>
|
2010-12-21 17:11:25 +00:00
|
|
|
#include <linux/input/mt.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
#include <linux/serio.h>
|
|
|
|
#include <linux/libps2.h>
|
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-24 08:04:11 +00:00
|
|
|
#include <linux/slab.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
#include "psmouse.h"
|
|
|
|
#include "synaptics.h"
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The x/y limits are taken from the Synaptics TouchPad interfacing Guide,
|
|
|
|
* section 2.3.2, which says that they should be valid regardless of the
|
|
|
|
* actual size of the sensor.
|
2010-05-11 06:06:52 +00:00
|
|
|
* Note that newer firmware allows querying device for maximum useable
|
|
|
|
* coordinates.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2012-07-25 06:54:11 +00:00
|
|
|
#define XMIN 0
|
|
|
|
#define XMAX 6143
|
|
|
|
#define YMIN 0
|
|
|
|
#define YMAX 6143
|
2005-04-16 22:20:36 +00:00
|
|
|
#define XMIN_NOMINAL 1472
|
|
|
|
#define XMAX_NOMINAL 5472
|
|
|
|
#define YMIN_NOMINAL 1408
|
|
|
|
#define YMAX_NOMINAL 4448
|
|
|
|
|
2012-07-25 06:54:11 +00:00
|
|
|
/* Size in bits of absolute position values reported by the hardware */
|
|
|
|
#define ABS_POS_BITS 13
|
|
|
|
|
|
|
|
/*
|
2012-09-28 17:29:21 +00:00
|
|
|
* These values should represent the absolute maximum value that will
|
|
|
|
* be reported for a positive position value. Some Synaptics firmware
|
|
|
|
* uses this value to indicate a finger near the edge of the touchpad
|
|
|
|
* whose precise position cannot be determined.
|
|
|
|
*
|
|
|
|
* At least one touchpad is known to report positions in excess of this
|
|
|
|
* value which are actually negative values truncated to the 13-bit
|
|
|
|
* reporting range. These values have never been observed to be lower
|
|
|
|
* than 8184 (i.e. -8), so we treat all values greater than 8176 as
|
|
|
|
* negative and any other value as positive.
|
2012-07-25 06:54:11 +00:00
|
|
|
*/
|
2012-09-28 17:29:21 +00:00
|
|
|
#define X_MAX_POSITIVE 8176
|
|
|
|
#define Y_MAX_POSITIVE 8176
|
2007-03-10 06:39:54 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/*****************************************************************************
|
2007-03-10 06:39:54 +00:00
|
|
|
* Stuff we need even when we do not want native Synaptics support
|
2005-04-16 22:20:36 +00:00
|
|
|
****************************************************************************/
|
|
|
|
|
|
|
|
/*
|
2007-03-10 06:39:54 +00:00
|
|
|
* Set the synaptics touchpad mode byte by special commands
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2007-03-10 06:39:54 +00:00
|
|
|
static int synaptics_mode_cmd(struct psmouse *psmouse, unsigned char mode)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2007-03-10 06:39:54 +00:00
|
|
|
unsigned char param[1];
|
|
|
|
|
|
|
|
if (psmouse_sliced_command(psmouse, mode))
|
2005-04-16 22:20:36 +00:00
|
|
|
return -1;
|
2007-03-10 06:39:54 +00:00
|
|
|
param[0] = SYN_PS_SET_MODE2;
|
|
|
|
if (ps2_command(&psmouse->ps2dev, param, PSMOUSE_CMD_SETRATE))
|
2005-04-16 22:20:36 +00:00
|
|
|
return -1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-09-10 02:13:20 +00:00
|
|
|
int synaptics_detect(struct psmouse *psmouse, bool set_properties)
|
2007-03-10 06:39:54 +00:00
|
|
|
{
|
|
|
|
struct ps2dev *ps2dev = &psmouse->ps2dev;
|
|
|
|
unsigned char param[4];
|
|
|
|
|
|
|
|
param[0] = 0;
|
|
|
|
|
|
|
|
ps2_command(ps2dev, param, PSMOUSE_CMD_SETRES);
|
|
|
|
ps2_command(ps2dev, param, PSMOUSE_CMD_SETRES);
|
|
|
|
ps2_command(ps2dev, param, PSMOUSE_CMD_SETRES);
|
|
|
|
ps2_command(ps2dev, param, PSMOUSE_CMD_SETRES);
|
|
|
|
ps2_command(ps2dev, param, PSMOUSE_CMD_GETINFO);
|
|
|
|
|
|
|
|
if (param[1] != 0x47)
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
if (set_properties) {
|
|
|
|
psmouse->vendor = "Synaptics";
|
|
|
|
psmouse->name = "TouchPad";
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
void synaptics_reset(struct psmouse *psmouse)
|
|
|
|
{
|
|
|
|
/* reset touchpad back to relative mode, gestures enabled */
|
|
|
|
synaptics_mode_cmd(psmouse, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef CONFIG_MOUSE_PS2_SYNAPTICS
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
* Synaptics communications functions
|
|
|
|
****************************************************************************/
|
|
|
|
|
2012-05-11 05:32:00 +00:00
|
|
|
/*
|
|
|
|
* Synaptics touchpads report the y coordinate from bottom to top, which is
|
|
|
|
* opposite from what userspace expects.
|
|
|
|
* This function is used to invert y before reporting.
|
|
|
|
*/
|
|
|
|
static int synaptics_invert_y(int y)
|
|
|
|
{
|
|
|
|
return YMAX_NOMINAL + YMIN_NOMINAL - y;
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
2007-03-10 06:39:54 +00:00
|
|
|
* Send a command to the synpatics touchpad by special commands
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2007-03-10 06:39:54 +00:00
|
|
|
static int synaptics_send_cmd(struct psmouse *psmouse, unsigned char c, unsigned char *param)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2007-03-10 06:39:54 +00:00
|
|
|
if (psmouse_sliced_command(psmouse, c))
|
2005-04-16 22:20:36 +00:00
|
|
|
return -1;
|
2007-03-10 06:39:54 +00:00
|
|
|
if (ps2_command(&psmouse->ps2dev, param, PSMOUSE_CMD_GETINFO))
|
2005-04-16 22:20:36 +00:00
|
|
|
return -1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Read the model-id bytes from the touchpad
|
|
|
|
* see also SYN_MODEL_* macros
|
|
|
|
*/
|
|
|
|
static int synaptics_model_id(struct psmouse *psmouse)
|
|
|
|
{
|
|
|
|
struct synaptics_data *priv = psmouse->private;
|
|
|
|
unsigned char mi[3];
|
|
|
|
|
|
|
|
if (synaptics_send_cmd(psmouse, SYN_QUE_MODEL, mi))
|
|
|
|
return -1;
|
|
|
|
priv->model_id = (mi[0]<<16) | (mi[1]<<8) | mi[2];
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-07-08 01:08:51 +00:00
|
|
|
/*
|
|
|
|
* Read the board id from the touchpad
|
|
|
|
* The board id is encoded in the "QUERY MODES" response
|
|
|
|
*/
|
|
|
|
static int synaptics_board_id(struct psmouse *psmouse)
|
|
|
|
{
|
|
|
|
struct synaptics_data *priv = psmouse->private;
|
|
|
|
unsigned char bid[3];
|
|
|
|
|
|
|
|
if (synaptics_send_cmd(psmouse, SYN_QUE_MODES, bid))
|
|
|
|
return -1;
|
|
|
|
priv->board_id = ((bid[0] & 0xfc) << 6) | bid[1];
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Read the firmware id from the touchpad
|
|
|
|
*/
|
|
|
|
static int synaptics_firmware_id(struct psmouse *psmouse)
|
|
|
|
{
|
|
|
|
struct synaptics_data *priv = psmouse->private;
|
|
|
|
unsigned char fwid[3];
|
|
|
|
|
|
|
|
if (synaptics_send_cmd(psmouse, SYN_QUE_FIRMWARE_ID, fwid))
|
|
|
|
return -1;
|
|
|
|
priv->firmware_id = (fwid[0] << 16) | (fwid[1] << 8) | fwid[2];
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* Read the capability-bits from the touchpad
|
|
|
|
* see also the SYN_CAP_* macros
|
|
|
|
*/
|
|
|
|
static int synaptics_capability(struct psmouse *psmouse)
|
|
|
|
{
|
|
|
|
struct synaptics_data *priv = psmouse->private;
|
|
|
|
unsigned char cap[3];
|
|
|
|
|
|
|
|
if (synaptics_send_cmd(psmouse, SYN_QUE_CAPABILITIES, cap))
|
|
|
|
return -1;
|
|
|
|
priv->capabilities = (cap[0] << 16) | (cap[1] << 8) | cap[2];
|
2010-04-19 17:37:21 +00:00
|
|
|
priv->ext_cap = priv->ext_cap_0c = 0;
|
|
|
|
|
2010-07-21 07:01:19 +00:00
|
|
|
/*
|
|
|
|
* Older firmwares had submodel ID fixed to 0x47
|
|
|
|
*/
|
|
|
|
if (SYN_ID_FULL(priv->identity) < 0x705 &&
|
|
|
|
SYN_CAP_SUBMODEL_ID(priv->capabilities) != 0x47) {
|
2005-04-16 22:20:36 +00:00
|
|
|
return -1;
|
2010-07-21 07:01:19 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Unless capExtended is set the rest of the flags should be ignored
|
|
|
|
*/
|
|
|
|
if (!SYN_CAP_EXTENDED(priv->capabilities))
|
|
|
|
priv->capabilities = 0;
|
|
|
|
|
|
|
|
if (SYN_EXT_CAP_REQUESTS(priv->capabilities) >= 1) {
|
|
|
|
if (synaptics_send_cmd(psmouse, SYN_QUE_EXT_CAPAB, cap)) {
|
2011-10-11 01:27:03 +00:00
|
|
|
psmouse_warn(psmouse,
|
|
|
|
"device claims to have extended capabilities, but I'm not able to read them.\n");
|
2005-04-16 22:20:36 +00:00
|
|
|
} else {
|
|
|
|
priv->ext_cap = (cap[0] << 16) | (cap[1] << 8) | cap[2];
|
|
|
|
|
|
|
|
/*
|
|
|
|
* if nExtBtn is greater than 8 it should be considered
|
|
|
|
* invalid and treated as 0
|
|
|
|
*/
|
|
|
|
if (SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap) > 8)
|
|
|
|
priv->ext_cap &= 0xff0fff;
|
|
|
|
}
|
|
|
|
}
|
2010-04-19 17:37:21 +00:00
|
|
|
|
|
|
|
if (SYN_EXT_CAP_REQUESTS(priv->capabilities) >= 4) {
|
|
|
|
if (synaptics_send_cmd(psmouse, SYN_QUE_EXT_CAPAB_0C, cap)) {
|
2011-10-11 01:27:03 +00:00
|
|
|
psmouse_warn(psmouse,
|
|
|
|
"device claims to have extended capability 0x0c, but I'm not able to read it.\n");
|
2010-04-19 17:37:21 +00:00
|
|
|
} else {
|
|
|
|
priv->ext_cap_0c = (cap[0] << 16) | (cap[1] << 8) | cap[2];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Identify Touchpad
|
|
|
|
* See also the SYN_ID_* macros
|
|
|
|
*/
|
|
|
|
static int synaptics_identify(struct psmouse *psmouse)
|
|
|
|
{
|
|
|
|
struct synaptics_data *priv = psmouse->private;
|
|
|
|
unsigned char id[3];
|
|
|
|
|
|
|
|
if (synaptics_send_cmd(psmouse, SYN_QUE_IDENTIFY, id))
|
|
|
|
return -1;
|
|
|
|
priv->identity = (id[0]<<16) | (id[1]<<8) | id[2];
|
|
|
|
if (SYN_ID_IS_SYNAPTICS(priv->identity))
|
|
|
|
return 0;
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2009-06-11 06:27:24 +00:00
|
|
|
/*
|
2010-05-11 06:06:52 +00:00
|
|
|
* Read touchpad resolution and maximum reported coordinates
|
2009-06-11 06:27:24 +00:00
|
|
|
* Resolution is left zero if touchpad does not support the query
|
|
|
|
*/
|
2014-03-28 07:43:00 +00:00
|
|
|
|
|
|
|
static const int *quirk_min_max;
|
|
|
|
|
2009-06-11 06:27:24 +00:00
|
|
|
static int synaptics_resolution(struct psmouse *psmouse)
|
|
|
|
{
|
|
|
|
struct synaptics_data *priv = psmouse->private;
|
2011-07-09 19:32:56 +00:00
|
|
|
unsigned char resp[3];
|
2009-06-11 06:27:24 +00:00
|
|
|
|
2014-03-28 07:43:00 +00:00
|
|
|
if (quirk_min_max) {
|
|
|
|
priv->x_min = quirk_min_max[0];
|
|
|
|
priv->x_max = quirk_min_max[1];
|
|
|
|
priv->y_min = quirk_min_max[2];
|
|
|
|
priv->y_max = quirk_min_max[3];
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-06-11 06:27:24 +00:00
|
|
|
if (SYN_ID_MAJOR(priv->identity) < 4)
|
2010-07-14 16:32:46 +00:00
|
|
|
return 0;
|
2009-06-11 06:27:24 +00:00
|
|
|
|
2011-07-09 19:32:56 +00:00
|
|
|
if (synaptics_send_cmd(psmouse, SYN_QUE_RESOLUTION, resp) == 0) {
|
|
|
|
if (resp[0] != 0 && (resp[1] & 0x80) && resp[2] != 0) {
|
|
|
|
priv->x_res = resp[0]; /* x resolution in units/mm */
|
|
|
|
priv->y_res = resp[2]; /* y resolution in units/mm */
|
2010-05-11 06:06:52 +00:00
|
|
|
}
|
|
|
|
}
|
2009-06-11 06:27:24 +00:00
|
|
|
|
2010-05-11 06:06:52 +00:00
|
|
|
if (SYN_EXT_CAP_REQUESTS(priv->capabilities) >= 5 &&
|
|
|
|
SYN_CAP_MAX_DIMENSIONS(priv->ext_cap_0c)) {
|
2011-07-09 19:32:56 +00:00
|
|
|
if (synaptics_send_cmd(psmouse, SYN_QUE_EXT_MAX_COORDS, resp)) {
|
2011-10-11 01:27:03 +00:00
|
|
|
psmouse_warn(psmouse,
|
|
|
|
"device claims to have max coordinates query, but I'm not able to read it.\n");
|
2011-07-09 19:32:56 +00:00
|
|
|
} else {
|
|
|
|
priv->x_max = (resp[0] << 5) | ((resp[1] & 0x0f) << 1);
|
|
|
|
priv->y_max = (resp[2] << 5) | ((resp[1] & 0xf0) >> 3);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (SYN_EXT_CAP_REQUESTS(priv->capabilities) >= 7 &&
|
|
|
|
SYN_CAP_MIN_DIMENSIONS(priv->ext_cap_0c)) {
|
|
|
|
if (synaptics_send_cmd(psmouse, SYN_QUE_EXT_MIN_COORDS, resp)) {
|
2011-10-11 01:27:03 +00:00
|
|
|
psmouse_warn(psmouse,
|
|
|
|
"device claims to have min coordinates query, but I'm not able to read it.\n");
|
2010-05-11 06:06:52 +00:00
|
|
|
} else {
|
2011-07-09 19:32:56 +00:00
|
|
|
priv->x_min = (resp[0] << 5) | ((resp[1] & 0x0f) << 1);
|
|
|
|
priv->y_min = (resp[2] << 5) | ((resp[1] & 0xf0) >> 3);
|
2010-05-11 06:06:52 +00:00
|
|
|
}
|
2009-06-11 06:27:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
static int synaptics_query_hardware(struct psmouse *psmouse)
|
|
|
|
{
|
|
|
|
if (synaptics_identify(psmouse))
|
|
|
|
return -1;
|
|
|
|
if (synaptics_model_id(psmouse))
|
|
|
|
return -1;
|
2012-07-08 01:08:51 +00:00
|
|
|
if (synaptics_firmware_id(psmouse))
|
|
|
|
return -1;
|
|
|
|
if (synaptics_board_id(psmouse))
|
|
|
|
return -1;
|
2005-04-16 22:20:36 +00:00
|
|
|
if (synaptics_capability(psmouse))
|
|
|
|
return -1;
|
2009-06-11 06:27:24 +00:00
|
|
|
if (synaptics_resolution(psmouse))
|
|
|
|
return -1;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
Input: synaptics - add support for Relative mode
Currently, the synaptics driver puts the device into Absolute mode.
As explained in the synaptics documentation section 3.2, in this mode,
the device sends a continuous stream of packets at the maximum rate
to the host when the user's fingers are near or on the pad or
pressing buttons, and continues streaming for 1 second afterwards.
These packets are even sent when there is no new information to report,
even when they are duplicates of the previous packet.
For embedded systems this is a bit much - it results in a huge
and uninterrupted stream of interrupts at high rate.
This patch adds support for Relative mode, which can be selected as
a new psmouse protocol. In this mode, the device does not send duplicate
packets and acts like a standard PS/2 mouse. However, synaptics-specific
functionality is still available, such as the ability to set the packet
rate, and rather than disabling gestures and taps at the hardware level
unconditionally, a 'synaptics_disable_gesture' sysfs attribute has
been added to allow control of this functionality.
This solves a long standing OLPC issue: synaptics hardware enables
tap to click by default (even in the default relative mode), but we
have found this to be inappropriate for young children and first
time computer users. Enabling the synaptics driver disables tap-to-click,
but we have previously been unable to use this because it also enables
Absolute mode, which is too "spammy" for our desires and actually
overloads our EC with its continuous stream of packets. Now we can enable
the synaptics driver, disabling tap to click while retaining the less
noisy Relative mode.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-11-08 08:00:35 +00:00
|
|
|
static int synaptics_set_advanced_gesture_mode(struct psmouse *psmouse)
|
|
|
|
{
|
|
|
|
static unsigned char param = 0xc8;
|
|
|
|
struct synaptics_data *priv = psmouse->private;
|
|
|
|
|
2012-04-21 05:34:49 +00:00
|
|
|
if (!(SYN_CAP_ADV_GESTURE(priv->ext_cap_0c) ||
|
|
|
|
SYN_CAP_IMAGE_SENSOR(priv->ext_cap_0c)))
|
Input: synaptics - add support for Relative mode
Currently, the synaptics driver puts the device into Absolute mode.
As explained in the synaptics documentation section 3.2, in this mode,
the device sends a continuous stream of packets at the maximum rate
to the host when the user's fingers are near or on the pad or
pressing buttons, and continues streaming for 1 second afterwards.
These packets are even sent when there is no new information to report,
even when they are duplicates of the previous packet.
For embedded systems this is a bit much - it results in a huge
and uninterrupted stream of interrupts at high rate.
This patch adds support for Relative mode, which can be selected as
a new psmouse protocol. In this mode, the device does not send duplicate
packets and acts like a standard PS/2 mouse. However, synaptics-specific
functionality is still available, such as the ability to set the packet
rate, and rather than disabling gestures and taps at the hardware level
unconditionally, a 'synaptics_disable_gesture' sysfs attribute has
been added to allow control of this functionality.
This solves a long standing OLPC issue: synaptics hardware enables
tap to click by default (even in the default relative mode), but we
have found this to be inappropriate for young children and first
time computer users. Enabling the synaptics driver disables tap-to-click,
but we have previously been unable to use this because it also enables
Absolute mode, which is too "spammy" for our desires and actually
overloads our EC with its continuous stream of packets. Now we can enable
the synaptics driver, disabling tap to click while retaining the less
noisy Relative mode.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-11-08 08:00:35 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (psmouse_sliced_command(psmouse, SYN_QUE_MODEL))
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
if (ps2_command(&psmouse->ps2dev, ¶m, PSMOUSE_CMD_SETRATE))
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
/* Advanced gesture mode also sends multi finger data */
|
|
|
|
priv->capabilities |= BIT(1);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int synaptics_set_mode(struct psmouse *psmouse)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
struct synaptics_data *priv = psmouse->private;
|
|
|
|
|
Input: synaptics - add support for Relative mode
Currently, the synaptics driver puts the device into Absolute mode.
As explained in the synaptics documentation section 3.2, in this mode,
the device sends a continuous stream of packets at the maximum rate
to the host when the user's fingers are near or on the pad or
pressing buttons, and continues streaming for 1 second afterwards.
These packets are even sent when there is no new information to report,
even when they are duplicates of the previous packet.
For embedded systems this is a bit much - it results in a huge
and uninterrupted stream of interrupts at high rate.
This patch adds support for Relative mode, which can be selected as
a new psmouse protocol. In this mode, the device does not send duplicate
packets and acts like a standard PS/2 mouse. However, synaptics-specific
functionality is still available, such as the ability to set the packet
rate, and rather than disabling gestures and taps at the hardware level
unconditionally, a 'synaptics_disable_gesture' sysfs attribute has
been added to allow control of this functionality.
This solves a long standing OLPC issue: synaptics hardware enables
tap to click by default (even in the default relative mode), but we
have found this to be inappropriate for young children and first
time computer users. Enabling the synaptics driver disables tap-to-click,
but we have previously been unable to use this because it also enables
Absolute mode, which is too "spammy" for our desires and actually
overloads our EC with its continuous stream of packets. Now we can enable
the synaptics driver, disabling tap to click while retaining the less
noisy Relative mode.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-11-08 08:00:35 +00:00
|
|
|
priv->mode = 0;
|
|
|
|
if (priv->absolute_mode)
|
|
|
|
priv->mode |= SYN_BIT_ABSOLUTE_MODE;
|
|
|
|
if (priv->disable_gesture)
|
2005-04-16 22:20:36 +00:00
|
|
|
priv->mode |= SYN_BIT_DISABLE_GESTURE;
|
Input: synaptics - add support for Relative mode
Currently, the synaptics driver puts the device into Absolute mode.
As explained in the synaptics documentation section 3.2, in this mode,
the device sends a continuous stream of packets at the maximum rate
to the host when the user's fingers are near or on the pad or
pressing buttons, and continues streaming for 1 second afterwards.
These packets are even sent when there is no new information to report,
even when they are duplicates of the previous packet.
For embedded systems this is a bit much - it results in a huge
and uninterrupted stream of interrupts at high rate.
This patch adds support for Relative mode, which can be selected as
a new psmouse protocol. In this mode, the device does not send duplicate
packets and acts like a standard PS/2 mouse. However, synaptics-specific
functionality is still available, such as the ability to set the packet
rate, and rather than disabling gestures and taps at the hardware level
unconditionally, a 'synaptics_disable_gesture' sysfs attribute has
been added to allow control of this functionality.
This solves a long standing OLPC issue: synaptics hardware enables
tap to click by default (even in the default relative mode), but we
have found this to be inappropriate for young children and first
time computer users. Enabling the synaptics driver disables tap-to-click,
but we have previously been unable to use this because it also enables
Absolute mode, which is too "spammy" for our desires and actually
overloads our EC with its continuous stream of packets. Now we can enable
the synaptics driver, disabling tap to click while retaining the less
noisy Relative mode.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-11-08 08:00:35 +00:00
|
|
|
if (psmouse->rate >= 80)
|
|
|
|
priv->mode |= SYN_BIT_HIGH_RATE;
|
2005-04-16 22:20:36 +00:00
|
|
|
if (SYN_CAP_EXTENDED(priv->capabilities))
|
|
|
|
priv->mode |= SYN_BIT_W_MODE;
|
|
|
|
|
|
|
|
if (synaptics_mode_cmd(psmouse, priv->mode))
|
|
|
|
return -1;
|
|
|
|
|
Input: synaptics - add support for Relative mode
Currently, the synaptics driver puts the device into Absolute mode.
As explained in the synaptics documentation section 3.2, in this mode,
the device sends a continuous stream of packets at the maximum rate
to the host when the user's fingers are near or on the pad or
pressing buttons, and continues streaming for 1 second afterwards.
These packets are even sent when there is no new information to report,
even when they are duplicates of the previous packet.
For embedded systems this is a bit much - it results in a huge
and uninterrupted stream of interrupts at high rate.
This patch adds support for Relative mode, which can be selected as
a new psmouse protocol. In this mode, the device does not send duplicate
packets and acts like a standard PS/2 mouse. However, synaptics-specific
functionality is still available, such as the ability to set the packet
rate, and rather than disabling gestures and taps at the hardware level
unconditionally, a 'synaptics_disable_gesture' sysfs attribute has
been added to allow control of this functionality.
This solves a long standing OLPC issue: synaptics hardware enables
tap to click by default (even in the default relative mode), but we
have found this to be inappropriate for young children and first
time computer users. Enabling the synaptics driver disables tap-to-click,
but we have previously been unable to use this because it also enables
Absolute mode, which is too "spammy" for our desires and actually
overloads our EC with its continuous stream of packets. Now we can enable
the synaptics driver, disabling tap to click while retaining the less
noisy Relative mode.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-11-08 08:00:35 +00:00
|
|
|
if (priv->absolute_mode &&
|
|
|
|
synaptics_set_advanced_gesture_mode(psmouse)) {
|
|
|
|
psmouse_err(psmouse, "Advanced gesture mode init failed.\n");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void synaptics_set_rate(struct psmouse *psmouse, unsigned int rate)
|
|
|
|
{
|
|
|
|
struct synaptics_data *priv = psmouse->private;
|
|
|
|
|
|
|
|
if (rate >= 80) {
|
|
|
|
priv->mode |= SYN_BIT_HIGH_RATE;
|
|
|
|
psmouse->rate = 80;
|
|
|
|
} else {
|
|
|
|
priv->mode &= ~SYN_BIT_HIGH_RATE;
|
|
|
|
psmouse->rate = 40;
|
|
|
|
}
|
|
|
|
|
|
|
|
synaptics_mode_cmd(psmouse, priv->mode);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
* Synaptics pass-through PS/2 port support
|
|
|
|
****************************************************************************/
|
|
|
|
static int synaptics_pt_write(struct serio *serio, unsigned char c)
|
|
|
|
{
|
|
|
|
struct psmouse *parent = serio_get_drvdata(serio->parent);
|
|
|
|
char rate_param = SYN_PS_CLIENT_CMD; /* indicates that we want pass-through port */
|
|
|
|
|
|
|
|
if (psmouse_sliced_command(parent, c))
|
|
|
|
return -1;
|
|
|
|
if (ps2_command(&parent->ps2dev, &rate_param, PSMOUSE_CMD_SETRATE))
|
|
|
|
return -1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-10-05 04:46:10 +00:00
|
|
|
static int synaptics_pt_start(struct serio *serio)
|
|
|
|
{
|
|
|
|
struct psmouse *parent = serio_get_drvdata(serio->parent);
|
|
|
|
struct synaptics_data *priv = parent->private;
|
|
|
|
|
|
|
|
serio_pause_rx(parent->ps2dev.serio);
|
|
|
|
priv->pt_port = serio;
|
|
|
|
serio_continue_rx(parent->ps2dev.serio);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void synaptics_pt_stop(struct serio *serio)
|
|
|
|
{
|
|
|
|
struct psmouse *parent = serio_get_drvdata(serio->parent);
|
|
|
|
struct synaptics_data *priv = parent->private;
|
|
|
|
|
|
|
|
serio_pause_rx(parent->ps2dev.serio);
|
|
|
|
priv->pt_port = NULL;
|
|
|
|
serio_continue_rx(parent->ps2dev.serio);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int synaptics_is_pt_packet(unsigned char *buf)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
return (buf[0] & 0xFC) == 0x84 && (buf[3] & 0xCC) == 0xC4;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void synaptics_pass_pt_packet(struct serio *ptport, unsigned char *packet)
|
|
|
|
{
|
|
|
|
struct psmouse *child = serio_get_drvdata(ptport);
|
|
|
|
|
|
|
|
if (child && child->state == PSMOUSE_ACTIVATED) {
|
IRQ: Maintain regs pointer globally rather than passing to IRQ handlers
Maintain a per-CPU global "struct pt_regs *" variable which can be used instead
of passing regs around manually through all ~1800 interrupt handlers in the
Linux kernel.
The regs pointer is used in few places, but it potentially costs both stack
space and code to pass it around. On the FRV arch, removing the regs parameter
from all the genirq function results in a 20% speed up of the IRQ exit path
(ie: from leaving timer_interrupt() to leaving do_IRQ()).
Where appropriate, an arch may override the generic storage facility and do
something different with the variable. On FRV, for instance, the address is
maintained in GR28 at all times inside the kernel as part of general exception
handling.
Having looked over the code, it appears that the parameter may be handed down
through up to twenty or so layers of functions. Consider a USB character
device attached to a USB hub, attached to a USB controller that posts its
interrupts through a cascaded auxiliary interrupt controller. A character
device driver may want to pass regs to the sysrq handler through the input
layer which adds another few layers of parameter passing.
I've build this code with allyesconfig for x86_64 and i386. I've runtested the
main part of the code on FRV and i386, though I can't test most of the drivers.
I've also done partial conversion for powerpc and MIPS - these at least compile
with minimal configurations.
This will affect all archs. Mostly the changes should be relatively easy.
Take do_IRQ(), store the regs pointer at the beginning, saving the old one:
struct pt_regs *old_regs = set_irq_regs(regs);
And put the old one back at the end:
set_irq_regs(old_regs);
Don't pass regs through to generic_handle_irq() or __do_IRQ().
In timer_interrupt(), this sort of change will be necessary:
- update_process_times(user_mode(regs));
- profile_tick(CPU_PROFILING, regs);
+ update_process_times(user_mode(get_irq_regs()));
+ profile_tick(CPU_PROFILING);
I'd like to move update_process_times()'s use of get_irq_regs() into itself,
except that i386, alone of the archs, uses something other than user_mode().
Some notes on the interrupt handling in the drivers:
(*) input_dev() is now gone entirely. The regs pointer is no longer stored in
the input_dev struct.
(*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking. It does
something different depending on whether it's been supplied with a regs
pointer or not.
(*) Various IRQ handler function pointers have been moved to type
irq_handler_t.
Signed-Off-By: David Howells <dhowells@redhat.com>
(cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)
2006-10-05 13:55:46 +00:00
|
|
|
serio_interrupt(ptport, packet[1], 0);
|
|
|
|
serio_interrupt(ptport, packet[4], 0);
|
|
|
|
serio_interrupt(ptport, packet[5], 0);
|
2005-07-24 05:53:32 +00:00
|
|
|
if (child->pktsize == 4)
|
IRQ: Maintain regs pointer globally rather than passing to IRQ handlers
Maintain a per-CPU global "struct pt_regs *" variable which can be used instead
of passing regs around manually through all ~1800 interrupt handlers in the
Linux kernel.
The regs pointer is used in few places, but it potentially costs both stack
space and code to pass it around. On the FRV arch, removing the regs parameter
from all the genirq function results in a 20% speed up of the IRQ exit path
(ie: from leaving timer_interrupt() to leaving do_IRQ()).
Where appropriate, an arch may override the generic storage facility and do
something different with the variable. On FRV, for instance, the address is
maintained in GR28 at all times inside the kernel as part of general exception
handling.
Having looked over the code, it appears that the parameter may be handed down
through up to twenty or so layers of functions. Consider a USB character
device attached to a USB hub, attached to a USB controller that posts its
interrupts through a cascaded auxiliary interrupt controller. A character
device driver may want to pass regs to the sysrq handler through the input
layer which adds another few layers of parameter passing.
I've build this code with allyesconfig for x86_64 and i386. I've runtested the
main part of the code on FRV and i386, though I can't test most of the drivers.
I've also done partial conversion for powerpc and MIPS - these at least compile
with minimal configurations.
This will affect all archs. Mostly the changes should be relatively easy.
Take do_IRQ(), store the regs pointer at the beginning, saving the old one:
struct pt_regs *old_regs = set_irq_regs(regs);
And put the old one back at the end:
set_irq_regs(old_regs);
Don't pass regs through to generic_handle_irq() or __do_IRQ().
In timer_interrupt(), this sort of change will be necessary:
- update_process_times(user_mode(regs));
- profile_tick(CPU_PROFILING, regs);
+ update_process_times(user_mode(get_irq_regs()));
+ profile_tick(CPU_PROFILING);
I'd like to move update_process_times()'s use of get_irq_regs() into itself,
except that i386, alone of the archs, uses something other than user_mode().
Some notes on the interrupt handling in the drivers:
(*) input_dev() is now gone entirely. The regs pointer is no longer stored in
the input_dev struct.
(*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking. It does
something different depending on whether it's been supplied with a regs
pointer or not.
(*) Various IRQ handler function pointers have been moved to type
irq_handler_t.
Signed-Off-By: David Howells <dhowells@redhat.com>
(cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)
2006-10-05 13:55:46 +00:00
|
|
|
serio_interrupt(ptport, packet[2], 0);
|
2005-04-16 22:20:36 +00:00
|
|
|
} else
|
IRQ: Maintain regs pointer globally rather than passing to IRQ handlers
Maintain a per-CPU global "struct pt_regs *" variable which can be used instead
of passing regs around manually through all ~1800 interrupt handlers in the
Linux kernel.
The regs pointer is used in few places, but it potentially costs both stack
space and code to pass it around. On the FRV arch, removing the regs parameter
from all the genirq function results in a 20% speed up of the IRQ exit path
(ie: from leaving timer_interrupt() to leaving do_IRQ()).
Where appropriate, an arch may override the generic storage facility and do
something different with the variable. On FRV, for instance, the address is
maintained in GR28 at all times inside the kernel as part of general exception
handling.
Having looked over the code, it appears that the parameter may be handed down
through up to twenty or so layers of functions. Consider a USB character
device attached to a USB hub, attached to a USB controller that posts its
interrupts through a cascaded auxiliary interrupt controller. A character
device driver may want to pass regs to the sysrq handler through the input
layer which adds another few layers of parameter passing.
I've build this code with allyesconfig for x86_64 and i386. I've runtested the
main part of the code on FRV and i386, though I can't test most of the drivers.
I've also done partial conversion for powerpc and MIPS - these at least compile
with minimal configurations.
This will affect all archs. Mostly the changes should be relatively easy.
Take do_IRQ(), store the regs pointer at the beginning, saving the old one:
struct pt_regs *old_regs = set_irq_regs(regs);
And put the old one back at the end:
set_irq_regs(old_regs);
Don't pass regs through to generic_handle_irq() or __do_IRQ().
In timer_interrupt(), this sort of change will be necessary:
- update_process_times(user_mode(regs));
- profile_tick(CPU_PROFILING, regs);
+ update_process_times(user_mode(get_irq_regs()));
+ profile_tick(CPU_PROFILING);
I'd like to move update_process_times()'s use of get_irq_regs() into itself,
except that i386, alone of the archs, uses something other than user_mode().
Some notes on the interrupt handling in the drivers:
(*) input_dev() is now gone entirely. The regs pointer is no longer stored in
the input_dev struct.
(*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking. It does
something different depending on whether it's been supplied with a regs
pointer or not.
(*) Various IRQ handler function pointers have been moved to type
irq_handler_t.
Signed-Off-By: David Howells <dhowells@redhat.com>
(cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)
2006-10-05 13:55:46 +00:00
|
|
|
serio_interrupt(ptport, packet[1], 0);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void synaptics_pt_activate(struct psmouse *psmouse)
|
|
|
|
{
|
|
|
|
struct synaptics_data *priv = psmouse->private;
|
2010-10-05 04:46:10 +00:00
|
|
|
struct psmouse *child = serio_get_drvdata(priv->pt_port);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* adjust the touchpad to child's choice of protocol */
|
|
|
|
if (child) {
|
2005-07-24 05:53:32 +00:00
|
|
|
if (child->pktsize == 4)
|
2005-04-16 22:20:36 +00:00
|
|
|
priv->mode |= SYN_BIT_FOUR_BYTE_CLIENT;
|
|
|
|
else
|
|
|
|
priv->mode &= ~SYN_BIT_FOUR_BYTE_CLIENT;
|
|
|
|
|
|
|
|
if (synaptics_mode_cmd(psmouse, priv->mode))
|
2011-10-11 01:27:03 +00:00
|
|
|
psmouse_warn(psmouse,
|
|
|
|
"failed to switch guest protocol\n");
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void synaptics_pt_create(struct psmouse *psmouse)
|
|
|
|
{
|
|
|
|
struct serio *serio;
|
|
|
|
|
2006-03-14 05:09:16 +00:00
|
|
|
serio = kzalloc(sizeof(struct serio), GFP_KERNEL);
|
2005-04-16 22:20:36 +00:00
|
|
|
if (!serio) {
|
2011-10-11 01:27:03 +00:00
|
|
|
psmouse_err(psmouse,
|
|
|
|
"not enough memory for pass-through port\n");
|
2005-04-16 22:20:36 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
serio->id.type = SERIO_PS_PSTHRU;
|
|
|
|
strlcpy(serio->name, "Synaptics pass-through", sizeof(serio->name));
|
|
|
|
strlcpy(serio->phys, "synaptics-pt/serio0", sizeof(serio->name));
|
|
|
|
serio->write = synaptics_pt_write;
|
2010-10-05 04:46:10 +00:00
|
|
|
serio->start = synaptics_pt_start;
|
|
|
|
serio->stop = synaptics_pt_stop;
|
2005-04-16 22:20:36 +00:00
|
|
|
serio->parent = psmouse->ps2dev.serio;
|
|
|
|
|
|
|
|
psmouse->pt_activate = synaptics_pt_activate;
|
|
|
|
|
2011-10-11 01:27:03 +00:00
|
|
|
psmouse_info(psmouse, "serio: %s port at %s\n",
|
|
|
|
serio->name, psmouse->phys);
|
2005-04-16 22:20:36 +00:00
|
|
|
serio_register_port(serio);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
* Functions to interpret the absolute mode packets
|
|
|
|
****************************************************************************/
|
|
|
|
|
Input: synaptics - decode AGM packet types
A Synaptics image sensor tracks 5 fingers, but can only report 2.
The algorithm for choosing which 2 fingers to report and in which packet:
Touchpad maintains 5 slots, numbered 0 to 4
Initially all slots are empty
As new fingers are detected, assign them to the lowest available slots
The touchpad always reports:
SGM: lowest numbered non-empty slot
AGM: highest numbered non-empty slot, if there is one
In addition, these touchpads have a special AGM packet type which reports
the number of fingers currently being tracked, and which finger is in
each of the two slots. Unfortunately, these "TYPE=2" packets are only used
when more than 3 fingers are being tracked. When less than 4 fingers
are present, the 'w' value must be used to track how many fingers are
present, and knowing which fingers are being reported is much more
difficult, if not impossible.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:31 +00:00
|
|
|
static void synaptics_mt_state_set(struct synaptics_mt_state *state, int count,
|
|
|
|
int sgm, int agm)
|
|
|
|
{
|
|
|
|
state->count = count;
|
|
|
|
state->sgm = sgm;
|
|
|
|
state->agm = agm;
|
|
|
|
}
|
|
|
|
|
2011-08-24 06:00:33 +00:00
|
|
|
static void synaptics_parse_agm(const unsigned char buf[],
|
Input: synaptics - decode AGM packet types
A Synaptics image sensor tracks 5 fingers, but can only report 2.
The algorithm for choosing which 2 fingers to report and in which packet:
Touchpad maintains 5 slots, numbered 0 to 4
Initially all slots are empty
As new fingers are detected, assign them to the lowest available slots
The touchpad always reports:
SGM: lowest numbered non-empty slot
AGM: highest numbered non-empty slot, if there is one
In addition, these touchpads have a special AGM packet type which reports
the number of fingers currently being tracked, and which finger is in
each of the two slots. Unfortunately, these "TYPE=2" packets are only used
when more than 3 fingers are being tracked. When less than 4 fingers
are present, the 'w' value must be used to track how many fingers are
present, and knowing which fingers are being reported is much more
difficult, if not impossible.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:31 +00:00
|
|
|
struct synaptics_data *priv,
|
|
|
|
struct synaptics_hw_state *hw)
|
2011-08-24 06:00:33 +00:00
|
|
|
{
|
|
|
|
struct synaptics_hw_state *agm = &priv->agm;
|
Input: synaptics - decode AGM packet types
A Synaptics image sensor tracks 5 fingers, but can only report 2.
The algorithm for choosing which 2 fingers to report and in which packet:
Touchpad maintains 5 slots, numbered 0 to 4
Initially all slots are empty
As new fingers are detected, assign them to the lowest available slots
The touchpad always reports:
SGM: lowest numbered non-empty slot
AGM: highest numbered non-empty slot, if there is one
In addition, these touchpads have a special AGM packet type which reports
the number of fingers currently being tracked, and which finger is in
each of the two slots. Unfortunately, these "TYPE=2" packets are only used
when more than 3 fingers are being tracked. When less than 4 fingers
are present, the 'w' value must be used to track how many fingers are
present, and knowing which fingers are being reported is much more
difficult, if not impossible.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:31 +00:00
|
|
|
int agm_packet_type;
|
|
|
|
|
|
|
|
agm_packet_type = (buf[5] & 0x30) >> 4;
|
|
|
|
switch (agm_packet_type) {
|
|
|
|
case 1:
|
|
|
|
/* Gesture packet: (x, y, z) half resolution */
|
|
|
|
agm->w = hw->w;
|
|
|
|
agm->x = (((buf[4] & 0x0f) << 8) | buf[1]) << 1;
|
|
|
|
agm->y = (((buf[4] & 0xf0) << 4) | buf[2]) << 1;
|
|
|
|
agm->z = ((buf[3] & 0x30) | (buf[5] & 0x0f)) << 1;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case 2:
|
|
|
|
/* AGM-CONTACT packet: (count, sgm, agm) */
|
|
|
|
synaptics_mt_state_set(&agm->mt_state, buf[1], buf[2], buf[4]);
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
Input: synaptics - process finger (<=3) transitions
Synaptics image sensor touchpads track 5 fingers, but only report 2.
This patch attempts to deal with some idiosyncrasies of these touchpads:
* When there are 3 or more fingers, only two are reported.
* The touchpad tracks the 5 fingers in slot[0] through slot[4].
* It always reports the lowest and highest valid slots in SGM and AGM
packets, respectively.
* The number of fingers is only reported in the SGM packet. However,
the number of fingers can change either before or after an AGM
packet.
* Thus, if an SGM reports a different number of fingers than the last
SGM, it is impossible to tell whether the intervening AGM corresponds
to the old number of fingers or the new number of fingers.
* For example, when going from 2->3 fingers, it is not possible to tell
whether tell AGM contains slot[1] (old 2nd finger) or slot[2] (new
3rd finger).
* When fingers are added one at at time, from 1->2->3, it is possible to
track which slots are contained in the SGM and AGM packets:
1 finger: SGM = slot[0], no AGM
2 fingers: SGM = slot[0], AGM = slot[1]
3 fingers: SGM = slot[0], AGM = slot[2]
* It is also possible to track which slot is contained in the SGM when 1
of 2 fingers is removed. This is because the touchpad sends a special
(0,0,0) AGM packet whenever all fingers are removed except slot[0]:
Last AGM == (0,0,0): SGM contains slot[1]
Else: SGM contains slot[0]
* However, once there are 3 fingers, if exactly 1 finger is removed, it
is impossible to tell which 2 slots are contained in SGM and AGM.
The (SGM,AGM) could be (0,1), (0,2), or (1,2). There is no way to know.
* Similarly, if two fingers are simultaneously removed (3->1), then it
is only possible to know if SGM still contains slot[0].
* Since it is not possible to reliably track which slot is being
reported, we invalidate the tracking_id every time the number of
fingers changes until this ambiguity is resolved when:
a) All fingers are removed.
b) 4 or 5 fingers are touched, generates an AGM-CONTACT packet.
c) All fingers are removed except slot[0]. In this special case, the
ambiguity is resolved since by the (0,0,0) AGM packet.
Behavior of the driver:
When 2 or more fingers are present on the touchpad, the kernel reports
up to two MT-B slots containing the position data for two of the fingers
reported by the touchpad. If the identity of a finger cannot be tracked
when the number-of-fingers changes, the corresponding MT-B slot will be
invalidated (track_id set to -1), and a new track_id will be assigned in
a subsequent input event report.
The driver always reports the total number of fingers using one of the
EV_KEY/BTN_TOOL_*TAP events. This could differ from the number of valid
MT-B slots for two reasons:
a) There are more than 2 fingers on the pad.
b) During ambiguous number-of-fingers transitions, the correct track_id
for one or both of the slots cannot be determined, so the slots are
invalidated.
Thus, this is a hybrid singletouch/MT-B scheme. Userspace can detect
this behavior by noting that the driver supports more EV_KEY/BTN_TOOL_*TAP
events than its maximum EV_ABS/ABS_MT_SLOT.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:40 +00:00
|
|
|
|
|
|
|
/* Record that at least one AGM has been received since last SGM */
|
|
|
|
priv->agm_pending = true;
|
2011-08-24 06:00:33 +00:00
|
|
|
}
|
|
|
|
|
2010-12-21 17:11:25 +00:00
|
|
|
static int synaptics_parse_hw_state(const unsigned char buf[],
|
|
|
|
struct synaptics_data *priv,
|
|
|
|
struct synaptics_hw_state *hw)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
memset(hw, 0, sizeof(struct synaptics_hw_state));
|
|
|
|
|
|
|
|
if (SYN_MODEL_NEWABS(priv->model_id)) {
|
|
|
|
hw->w = (((buf[0] & 0x30) >> 2) |
|
|
|
|
((buf[0] & 0x04) >> 1) |
|
|
|
|
((buf[3] & 0x04) >> 2));
|
|
|
|
|
|
|
|
hw->left = (buf[0] & 0x01) ? 1 : 0;
|
|
|
|
hw->right = (buf[0] & 0x02) ? 1 : 0;
|
|
|
|
|
2010-04-19 17:37:21 +00:00
|
|
|
if (SYN_CAP_CLICKPAD(priv->ext_cap_0c)) {
|
|
|
|
/*
|
|
|
|
* Clickpad's button is transmitted as middle button,
|
|
|
|
* however, since it is primary button, we will report
|
|
|
|
* it as BTN_LEFT.
|
|
|
|
*/
|
|
|
|
hw->left = ((buf[0] ^ buf[3]) & 0x01) ? 1 : 0;
|
|
|
|
|
|
|
|
} else if (SYN_CAP_MIDDLE_BUTTON(priv->capabilities)) {
|
2005-04-16 22:20:36 +00:00
|
|
|
hw->middle = ((buf[0] ^ buf[3]) & 0x01) ? 1 : 0;
|
|
|
|
if (hw->w == 2)
|
|
|
|
hw->scroll = (signed char)(buf[1]);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (SYN_CAP_FOUR_BUTTON(priv->capabilities)) {
|
|
|
|
hw->up = ((buf[0] ^ buf[3]) & 0x01) ? 1 : 0;
|
|
|
|
hw->down = ((buf[0] ^ buf[3]) & 0x02) ? 1 : 0;
|
|
|
|
}
|
|
|
|
|
Input: synaptics - add image sensor support
Synaptics makes (at least) two kinds of touchpad sensors:
* Older pads use a profile sensor that could only infer the location
of individual fingers based on the projection of their profiles
onto row and column sensors.
* Newer pads use an image sensor that can track true finger position
using a two-dimensional sensor grid.
Both sensor types support an "Advanced Gesture Mode":
When multiple fingers are detected, the touchpad sends alternating
"Advanced Gesture Mode" (AGM) and "Simple Gesture Mode" (SGM)
packets.
The AGM packets have w=2, and contain reduced resolution finger data
The SGM packets have w={0,1} and contain full resolution finger data
Profile sensors try to report the "upper" (larger y value) finger in
the SGM packet, and the lower (smaller y value) in the AGM packet.
However, due to the nature of the profile sensor, they easily get
confused when fingers cross, and can start reporting the x-coordinate
of one with the y-coordinate of the other. Thus, for profile
sensors, "semi-mt" was created, which reports a "bounding box"
created by pairing min and max coordinates of the two pairs of
reported fingers.
Image sensors can report the actual coordinates of two of the fingers
present. This patch detects if the touchpad is an image sensor and
reports finger data using the MT-B protocol.
NOTE: This patch only adds partial support for 2-finger gestures.
The proper interpretation of the slot contents when more than
two fingers are present is left to later patches. Also,
handling of 'number of fingers' transitions is incomplete.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:25 +00:00
|
|
|
if ((SYN_CAP_ADV_GESTURE(priv->ext_cap_0c) ||
|
|
|
|
SYN_CAP_IMAGE_SENSOR(priv->ext_cap_0c)) &&
|
|
|
|
hw->w == 2) {
|
Input: synaptics - decode AGM packet types
A Synaptics image sensor tracks 5 fingers, but can only report 2.
The algorithm for choosing which 2 fingers to report and in which packet:
Touchpad maintains 5 slots, numbered 0 to 4
Initially all slots are empty
As new fingers are detected, assign them to the lowest available slots
The touchpad always reports:
SGM: lowest numbered non-empty slot
AGM: highest numbered non-empty slot, if there is one
In addition, these touchpads have a special AGM packet type which reports
the number of fingers currently being tracked, and which finger is in
each of the two slots. Unfortunately, these "TYPE=2" packets are only used
when more than 3 fingers are being tracked. When less than 4 fingers
are present, the 'w' value must be used to track how many fingers are
present, and knowing which fingers are being reported is much more
difficult, if not impossible.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:31 +00:00
|
|
|
synaptics_parse_agm(buf, priv, hw);
|
2011-07-07 05:57:39 +00:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
hw->x = (((buf[3] & 0x10) << 8) |
|
|
|
|
((buf[1] & 0x0f) << 8) |
|
|
|
|
buf[4]);
|
|
|
|
hw->y = (((buf[3] & 0x20) << 7) |
|
|
|
|
((buf[1] & 0xf0) << 4) |
|
|
|
|
buf[5]);
|
|
|
|
hw->z = buf[2];
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
if (SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap) &&
|
|
|
|
((buf[0] ^ buf[3]) & 0x02)) {
|
|
|
|
switch (SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap) & ~0x01) {
|
|
|
|
default:
|
|
|
|
/*
|
|
|
|
* if nExtBtn is greater than 8 it should be
|
|
|
|
* considered invalid and treated as 0
|
|
|
|
*/
|
|
|
|
break;
|
|
|
|
case 8:
|
|
|
|
hw->ext_buttons |= ((buf[5] & 0x08)) ? 0x80 : 0;
|
|
|
|
hw->ext_buttons |= ((buf[4] & 0x08)) ? 0x40 : 0;
|
|
|
|
case 6:
|
|
|
|
hw->ext_buttons |= ((buf[5] & 0x04)) ? 0x20 : 0;
|
|
|
|
hw->ext_buttons |= ((buf[4] & 0x04)) ? 0x10 : 0;
|
|
|
|
case 4:
|
|
|
|
hw->ext_buttons |= ((buf[5] & 0x02)) ? 0x08 : 0;
|
|
|
|
hw->ext_buttons |= ((buf[4] & 0x02)) ? 0x04 : 0;
|
|
|
|
case 2:
|
|
|
|
hw->ext_buttons |= ((buf[5] & 0x01)) ? 0x02 : 0;
|
|
|
|
hw->ext_buttons |= ((buf[4] & 0x01)) ? 0x01 : 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
hw->x = (((buf[1] & 0x1f) << 8) | buf[2]);
|
|
|
|
hw->y = (((buf[4] & 0x1f) << 8) | buf[5]);
|
|
|
|
|
|
|
|
hw->z = (((buf[0] & 0x30) << 2) | (buf[3] & 0x3F));
|
|
|
|
hw->w = (((buf[1] & 0x80) >> 4) | ((buf[0] & 0x04) >> 1));
|
|
|
|
|
|
|
|
hw->left = (buf[0] & 0x01) ? 1 : 0;
|
|
|
|
hw->right = (buf[0] & 0x02) ? 1 : 0;
|
|
|
|
}
|
2010-12-21 17:11:25 +00:00
|
|
|
|
2012-09-28 17:29:21 +00:00
|
|
|
/*
|
|
|
|
* Convert wrap-around values to negative. (X|Y)_MAX_POSITIVE
|
|
|
|
* is used by some firmware to indicate a finger at the edge of
|
|
|
|
* the touchpad whose precise position cannot be determined, so
|
|
|
|
* convert these values to the maximum axis value.
|
|
|
|
*/
|
2012-07-25 06:54:11 +00:00
|
|
|
if (hw->x > X_MAX_POSITIVE)
|
|
|
|
hw->x -= 1 << ABS_POS_BITS;
|
2012-09-28 17:29:21 +00:00
|
|
|
else if (hw->x == X_MAX_POSITIVE)
|
|
|
|
hw->x = XMAX;
|
|
|
|
|
2012-07-25 06:54:11 +00:00
|
|
|
if (hw->y > Y_MAX_POSITIVE)
|
|
|
|
hw->y -= 1 << ABS_POS_BITS;
|
2012-09-28 17:29:21 +00:00
|
|
|
else if (hw->y == Y_MAX_POSITIVE)
|
|
|
|
hw->y = YMAX;
|
2012-07-25 06:54:11 +00:00
|
|
|
|
2010-12-21 17:11:25 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-07-07 05:42:52 +00:00
|
|
|
static void synaptics_report_semi_mt_slot(struct input_dev *dev, int slot,
|
|
|
|
bool active, int x, int y)
|
2010-12-21 17:11:25 +00:00
|
|
|
{
|
|
|
|
input_mt_slot(dev, slot);
|
|
|
|
input_mt_report_slot_state(dev, MT_TOOL_FINGER, active);
|
|
|
|
if (active) {
|
|
|
|
input_report_abs(dev, ABS_MT_POSITION_X, x);
|
2011-08-24 06:00:24 +00:00
|
|
|
input_report_abs(dev, ABS_MT_POSITION_Y, synaptics_invert_y(y));
|
2010-12-21 17:11:25 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void synaptics_report_semi_mt_data(struct input_dev *dev,
|
|
|
|
const struct synaptics_hw_state *a,
|
|
|
|
const struct synaptics_hw_state *b,
|
|
|
|
int num_fingers)
|
|
|
|
{
|
|
|
|
if (num_fingers >= 2) {
|
2011-07-07 05:42:52 +00:00
|
|
|
synaptics_report_semi_mt_slot(dev, 0, true, min(a->x, b->x),
|
|
|
|
min(a->y, b->y));
|
|
|
|
synaptics_report_semi_mt_slot(dev, 1, true, max(a->x, b->x),
|
|
|
|
max(a->y, b->y));
|
2010-12-21 17:11:25 +00:00
|
|
|
} else if (num_fingers == 1) {
|
2011-07-07 05:42:52 +00:00
|
|
|
synaptics_report_semi_mt_slot(dev, 0, true, a->x, a->y);
|
|
|
|
synaptics_report_semi_mt_slot(dev, 1, false, 0, 0);
|
2010-12-21 17:11:25 +00:00
|
|
|
} else {
|
2011-07-07 05:42:52 +00:00
|
|
|
synaptics_report_semi_mt_slot(dev, 0, false, 0, 0);
|
|
|
|
synaptics_report_semi_mt_slot(dev, 1, false, 0, 0);
|
2010-12-21 17:11:25 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
Input: synaptics - add image sensor support
Synaptics makes (at least) two kinds of touchpad sensors:
* Older pads use a profile sensor that could only infer the location
of individual fingers based on the projection of their profiles
onto row and column sensors.
* Newer pads use an image sensor that can track true finger position
using a two-dimensional sensor grid.
Both sensor types support an "Advanced Gesture Mode":
When multiple fingers are detected, the touchpad sends alternating
"Advanced Gesture Mode" (AGM) and "Simple Gesture Mode" (SGM)
packets.
The AGM packets have w=2, and contain reduced resolution finger data
The SGM packets have w={0,1} and contain full resolution finger data
Profile sensors try to report the "upper" (larger y value) finger in
the SGM packet, and the lower (smaller y value) in the AGM packet.
However, due to the nature of the profile sensor, they easily get
confused when fingers cross, and can start reporting the x-coordinate
of one with the y-coordinate of the other. Thus, for profile
sensors, "semi-mt" was created, which reports a "bounding box"
created by pairing min and max coordinates of the two pairs of
reported fingers.
Image sensors can report the actual coordinates of two of the fingers
present. This patch detects if the touchpad is an image sensor and
reports finger data using the MT-B protocol.
NOTE: This patch only adds partial support for 2-finger gestures.
The proper interpretation of the slot contents when more than
two fingers are present is left to later patches. Also,
handling of 'number of fingers' transitions is incomplete.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:25 +00:00
|
|
|
static void synaptics_report_buttons(struct psmouse *psmouse,
|
|
|
|
const struct synaptics_hw_state *hw)
|
|
|
|
{
|
|
|
|
struct input_dev *dev = psmouse->dev;
|
|
|
|
struct synaptics_data *priv = psmouse->private;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
input_report_key(dev, BTN_LEFT, hw->left);
|
|
|
|
input_report_key(dev, BTN_RIGHT, hw->right);
|
|
|
|
|
|
|
|
if (SYN_CAP_MIDDLE_BUTTON(priv->capabilities))
|
|
|
|
input_report_key(dev, BTN_MIDDLE, hw->middle);
|
|
|
|
|
|
|
|
if (SYN_CAP_FOUR_BUTTON(priv->capabilities)) {
|
|
|
|
input_report_key(dev, BTN_FORWARD, hw->up);
|
|
|
|
input_report_key(dev, BTN_BACK, hw->down);
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap); i++)
|
|
|
|
input_report_key(dev, BTN_0 + i, hw->ext_buttons & (1 << i));
|
|
|
|
}
|
|
|
|
|
|
|
|
static void synaptics_report_slot(struct input_dev *dev, int slot,
|
|
|
|
const struct synaptics_hw_state *hw)
|
|
|
|
{
|
|
|
|
input_mt_slot(dev, slot);
|
|
|
|
input_mt_report_slot_state(dev, MT_TOOL_FINGER, (hw != NULL));
|
|
|
|
if (!hw)
|
|
|
|
return;
|
|
|
|
|
|
|
|
input_report_abs(dev, ABS_MT_POSITION_X, hw->x);
|
|
|
|
input_report_abs(dev, ABS_MT_POSITION_Y, synaptics_invert_y(hw->y));
|
|
|
|
input_report_abs(dev, ABS_MT_PRESSURE, hw->z);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void synaptics_report_mt_data(struct psmouse *psmouse,
|
Input: synaptics - process finger (<=3) transitions
Synaptics image sensor touchpads track 5 fingers, but only report 2.
This patch attempts to deal with some idiosyncrasies of these touchpads:
* When there are 3 or more fingers, only two are reported.
* The touchpad tracks the 5 fingers in slot[0] through slot[4].
* It always reports the lowest and highest valid slots in SGM and AGM
packets, respectively.
* The number of fingers is only reported in the SGM packet. However,
the number of fingers can change either before or after an AGM
packet.
* Thus, if an SGM reports a different number of fingers than the last
SGM, it is impossible to tell whether the intervening AGM corresponds
to the old number of fingers or the new number of fingers.
* For example, when going from 2->3 fingers, it is not possible to tell
whether tell AGM contains slot[1] (old 2nd finger) or slot[2] (new
3rd finger).
* When fingers are added one at at time, from 1->2->3, it is possible to
track which slots are contained in the SGM and AGM packets:
1 finger: SGM = slot[0], no AGM
2 fingers: SGM = slot[0], AGM = slot[1]
3 fingers: SGM = slot[0], AGM = slot[2]
* It is also possible to track which slot is contained in the SGM when 1
of 2 fingers is removed. This is because the touchpad sends a special
(0,0,0) AGM packet whenever all fingers are removed except slot[0]:
Last AGM == (0,0,0): SGM contains slot[1]
Else: SGM contains slot[0]
* However, once there are 3 fingers, if exactly 1 finger is removed, it
is impossible to tell which 2 slots are contained in SGM and AGM.
The (SGM,AGM) could be (0,1), (0,2), or (1,2). There is no way to know.
* Similarly, if two fingers are simultaneously removed (3->1), then it
is only possible to know if SGM still contains slot[0].
* Since it is not possible to reliably track which slot is being
reported, we invalidate the tracking_id every time the number of
fingers changes until this ambiguity is resolved when:
a) All fingers are removed.
b) 4 or 5 fingers are touched, generates an AGM-CONTACT packet.
c) All fingers are removed except slot[0]. In this special case, the
ambiguity is resolved since by the (0,0,0) AGM packet.
Behavior of the driver:
When 2 or more fingers are present on the touchpad, the kernel reports
up to two MT-B slots containing the position data for two of the fingers
reported by the touchpad. If the identity of a finger cannot be tracked
when the number-of-fingers changes, the corresponding MT-B slot will be
invalidated (track_id set to -1), and a new track_id will be assigned in
a subsequent input event report.
The driver always reports the total number of fingers using one of the
EV_KEY/BTN_TOOL_*TAP events. This could differ from the number of valid
MT-B slots for two reasons:
a) There are more than 2 fingers on the pad.
b) During ambiguous number-of-fingers transitions, the correct track_id
for one or both of the slots cannot be determined, so the slots are
invalidated.
Thus, this is a hybrid singletouch/MT-B scheme. Userspace can detect
this behavior by noting that the driver supports more EV_KEY/BTN_TOOL_*TAP
events than its maximum EV_ABS/ABS_MT_SLOT.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:40 +00:00
|
|
|
struct synaptics_mt_state *mt_state,
|
Input: synaptics - add image sensor support
Synaptics makes (at least) two kinds of touchpad sensors:
* Older pads use a profile sensor that could only infer the location
of individual fingers based on the projection of their profiles
onto row and column sensors.
* Newer pads use an image sensor that can track true finger position
using a two-dimensional sensor grid.
Both sensor types support an "Advanced Gesture Mode":
When multiple fingers are detected, the touchpad sends alternating
"Advanced Gesture Mode" (AGM) and "Simple Gesture Mode" (SGM)
packets.
The AGM packets have w=2, and contain reduced resolution finger data
The SGM packets have w={0,1} and contain full resolution finger data
Profile sensors try to report the "upper" (larger y value) finger in
the SGM packet, and the lower (smaller y value) in the AGM packet.
However, due to the nature of the profile sensor, they easily get
confused when fingers cross, and can start reporting the x-coordinate
of one with the y-coordinate of the other. Thus, for profile
sensors, "semi-mt" was created, which reports a "bounding box"
created by pairing min and max coordinates of the two pairs of
reported fingers.
Image sensors can report the actual coordinates of two of the fingers
present. This patch detects if the touchpad is an image sensor and
reports finger data using the MT-B protocol.
NOTE: This patch only adds partial support for 2-finger gestures.
The proper interpretation of the slot contents when more than
two fingers are present is left to later patches. Also,
handling of 'number of fingers' transitions is incomplete.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:25 +00:00
|
|
|
const struct synaptics_hw_state *sgm)
|
|
|
|
{
|
|
|
|
struct input_dev *dev = psmouse->dev;
|
|
|
|
struct synaptics_data *priv = psmouse->private;
|
|
|
|
struct synaptics_hw_state *agm = &priv->agm;
|
Input: synaptics - process finger (<=3) transitions
Synaptics image sensor touchpads track 5 fingers, but only report 2.
This patch attempts to deal with some idiosyncrasies of these touchpads:
* When there are 3 or more fingers, only two are reported.
* The touchpad tracks the 5 fingers in slot[0] through slot[4].
* It always reports the lowest and highest valid slots in SGM and AGM
packets, respectively.
* The number of fingers is only reported in the SGM packet. However,
the number of fingers can change either before or after an AGM
packet.
* Thus, if an SGM reports a different number of fingers than the last
SGM, it is impossible to tell whether the intervening AGM corresponds
to the old number of fingers or the new number of fingers.
* For example, when going from 2->3 fingers, it is not possible to tell
whether tell AGM contains slot[1] (old 2nd finger) or slot[2] (new
3rd finger).
* When fingers are added one at at time, from 1->2->3, it is possible to
track which slots are contained in the SGM and AGM packets:
1 finger: SGM = slot[0], no AGM
2 fingers: SGM = slot[0], AGM = slot[1]
3 fingers: SGM = slot[0], AGM = slot[2]
* It is also possible to track which slot is contained in the SGM when 1
of 2 fingers is removed. This is because the touchpad sends a special
(0,0,0) AGM packet whenever all fingers are removed except slot[0]:
Last AGM == (0,0,0): SGM contains slot[1]
Else: SGM contains slot[0]
* However, once there are 3 fingers, if exactly 1 finger is removed, it
is impossible to tell which 2 slots are contained in SGM and AGM.
The (SGM,AGM) could be (0,1), (0,2), or (1,2). There is no way to know.
* Similarly, if two fingers are simultaneously removed (3->1), then it
is only possible to know if SGM still contains slot[0].
* Since it is not possible to reliably track which slot is being
reported, we invalidate the tracking_id every time the number of
fingers changes until this ambiguity is resolved when:
a) All fingers are removed.
b) 4 or 5 fingers are touched, generates an AGM-CONTACT packet.
c) All fingers are removed except slot[0]. In this special case, the
ambiguity is resolved since by the (0,0,0) AGM packet.
Behavior of the driver:
When 2 or more fingers are present on the touchpad, the kernel reports
up to two MT-B slots containing the position data for two of the fingers
reported by the touchpad. If the identity of a finger cannot be tracked
when the number-of-fingers changes, the corresponding MT-B slot will be
invalidated (track_id set to -1), and a new track_id will be assigned in
a subsequent input event report.
The driver always reports the total number of fingers using one of the
EV_KEY/BTN_TOOL_*TAP events. This could differ from the number of valid
MT-B slots for two reasons:
a) There are more than 2 fingers on the pad.
b) During ambiguous number-of-fingers transitions, the correct track_id
for one or both of the slots cannot be determined, so the slots are
invalidated.
Thus, this is a hybrid singletouch/MT-B scheme. Userspace can detect
this behavior by noting that the driver supports more EV_KEY/BTN_TOOL_*TAP
events than its maximum EV_ABS/ABS_MT_SLOT.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:40 +00:00
|
|
|
struct synaptics_mt_state *old = &priv->mt_state;
|
Input: synaptics - add image sensor support
Synaptics makes (at least) two kinds of touchpad sensors:
* Older pads use a profile sensor that could only infer the location
of individual fingers based on the projection of their profiles
onto row and column sensors.
* Newer pads use an image sensor that can track true finger position
using a two-dimensional sensor grid.
Both sensor types support an "Advanced Gesture Mode":
When multiple fingers are detected, the touchpad sends alternating
"Advanced Gesture Mode" (AGM) and "Simple Gesture Mode" (SGM)
packets.
The AGM packets have w=2, and contain reduced resolution finger data
The SGM packets have w={0,1} and contain full resolution finger data
Profile sensors try to report the "upper" (larger y value) finger in
the SGM packet, and the lower (smaller y value) in the AGM packet.
However, due to the nature of the profile sensor, they easily get
confused when fingers cross, and can start reporting the x-coordinate
of one with the y-coordinate of the other. Thus, for profile
sensors, "semi-mt" was created, which reports a "bounding box"
created by pairing min and max coordinates of the two pairs of
reported fingers.
Image sensors can report the actual coordinates of two of the fingers
present. This patch detects if the touchpad is an image sensor and
reports finger data using the MT-B protocol.
NOTE: This patch only adds partial support for 2-finger gestures.
The proper interpretation of the slot contents when more than
two fingers are present is left to later patches. Also,
handling of 'number of fingers' transitions is incomplete.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:25 +00:00
|
|
|
|
Input: synaptics - process finger (<=3) transitions
Synaptics image sensor touchpads track 5 fingers, but only report 2.
This patch attempts to deal with some idiosyncrasies of these touchpads:
* When there are 3 or more fingers, only two are reported.
* The touchpad tracks the 5 fingers in slot[0] through slot[4].
* It always reports the lowest and highest valid slots in SGM and AGM
packets, respectively.
* The number of fingers is only reported in the SGM packet. However,
the number of fingers can change either before or after an AGM
packet.
* Thus, if an SGM reports a different number of fingers than the last
SGM, it is impossible to tell whether the intervening AGM corresponds
to the old number of fingers or the new number of fingers.
* For example, when going from 2->3 fingers, it is not possible to tell
whether tell AGM contains slot[1] (old 2nd finger) or slot[2] (new
3rd finger).
* When fingers are added one at at time, from 1->2->3, it is possible to
track which slots are contained in the SGM and AGM packets:
1 finger: SGM = slot[0], no AGM
2 fingers: SGM = slot[0], AGM = slot[1]
3 fingers: SGM = slot[0], AGM = slot[2]
* It is also possible to track which slot is contained in the SGM when 1
of 2 fingers is removed. This is because the touchpad sends a special
(0,0,0) AGM packet whenever all fingers are removed except slot[0]:
Last AGM == (0,0,0): SGM contains slot[1]
Else: SGM contains slot[0]
* However, once there are 3 fingers, if exactly 1 finger is removed, it
is impossible to tell which 2 slots are contained in SGM and AGM.
The (SGM,AGM) could be (0,1), (0,2), or (1,2). There is no way to know.
* Similarly, if two fingers are simultaneously removed (3->1), then it
is only possible to know if SGM still contains slot[0].
* Since it is not possible to reliably track which slot is being
reported, we invalidate the tracking_id every time the number of
fingers changes until this ambiguity is resolved when:
a) All fingers are removed.
b) 4 or 5 fingers are touched, generates an AGM-CONTACT packet.
c) All fingers are removed except slot[0]. In this special case, the
ambiguity is resolved since by the (0,0,0) AGM packet.
Behavior of the driver:
When 2 or more fingers are present on the touchpad, the kernel reports
up to two MT-B slots containing the position data for two of the fingers
reported by the touchpad. If the identity of a finger cannot be tracked
when the number-of-fingers changes, the corresponding MT-B slot will be
invalidated (track_id set to -1), and a new track_id will be assigned in
a subsequent input event report.
The driver always reports the total number of fingers using one of the
EV_KEY/BTN_TOOL_*TAP events. This could differ from the number of valid
MT-B slots for two reasons:
a) There are more than 2 fingers on the pad.
b) During ambiguous number-of-fingers transitions, the correct track_id
for one or both of the slots cannot be determined, so the slots are
invalidated.
Thus, this is a hybrid singletouch/MT-B scheme. Userspace can detect
this behavior by noting that the driver supports more EV_KEY/BTN_TOOL_*TAP
events than its maximum EV_ABS/ABS_MT_SLOT.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:40 +00:00
|
|
|
switch (mt_state->count) {
|
Input: synaptics - add image sensor support
Synaptics makes (at least) two kinds of touchpad sensors:
* Older pads use a profile sensor that could only infer the location
of individual fingers based on the projection of their profiles
onto row and column sensors.
* Newer pads use an image sensor that can track true finger position
using a two-dimensional sensor grid.
Both sensor types support an "Advanced Gesture Mode":
When multiple fingers are detected, the touchpad sends alternating
"Advanced Gesture Mode" (AGM) and "Simple Gesture Mode" (SGM)
packets.
The AGM packets have w=2, and contain reduced resolution finger data
The SGM packets have w={0,1} and contain full resolution finger data
Profile sensors try to report the "upper" (larger y value) finger in
the SGM packet, and the lower (smaller y value) in the AGM packet.
However, due to the nature of the profile sensor, they easily get
confused when fingers cross, and can start reporting the x-coordinate
of one with the y-coordinate of the other. Thus, for profile
sensors, "semi-mt" was created, which reports a "bounding box"
created by pairing min and max coordinates of the two pairs of
reported fingers.
Image sensors can report the actual coordinates of two of the fingers
present. This patch detects if the touchpad is an image sensor and
reports finger data using the MT-B protocol.
NOTE: This patch only adds partial support for 2-finger gestures.
The proper interpretation of the slot contents when more than
two fingers are present is left to later patches. Also,
handling of 'number of fingers' transitions is incomplete.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:25 +00:00
|
|
|
case 0:
|
|
|
|
synaptics_report_slot(dev, 0, NULL);
|
|
|
|
synaptics_report_slot(dev, 1, NULL);
|
|
|
|
break;
|
|
|
|
case 1:
|
Input: synaptics - process finger (<=3) transitions
Synaptics image sensor touchpads track 5 fingers, but only report 2.
This patch attempts to deal with some idiosyncrasies of these touchpads:
* When there are 3 or more fingers, only two are reported.
* The touchpad tracks the 5 fingers in slot[0] through slot[4].
* It always reports the lowest and highest valid slots in SGM and AGM
packets, respectively.
* The number of fingers is only reported in the SGM packet. However,
the number of fingers can change either before or after an AGM
packet.
* Thus, if an SGM reports a different number of fingers than the last
SGM, it is impossible to tell whether the intervening AGM corresponds
to the old number of fingers or the new number of fingers.
* For example, when going from 2->3 fingers, it is not possible to tell
whether tell AGM contains slot[1] (old 2nd finger) or slot[2] (new
3rd finger).
* When fingers are added one at at time, from 1->2->3, it is possible to
track which slots are contained in the SGM and AGM packets:
1 finger: SGM = slot[0], no AGM
2 fingers: SGM = slot[0], AGM = slot[1]
3 fingers: SGM = slot[0], AGM = slot[2]
* It is also possible to track which slot is contained in the SGM when 1
of 2 fingers is removed. This is because the touchpad sends a special
(0,0,0) AGM packet whenever all fingers are removed except slot[0]:
Last AGM == (0,0,0): SGM contains slot[1]
Else: SGM contains slot[0]
* However, once there are 3 fingers, if exactly 1 finger is removed, it
is impossible to tell which 2 slots are contained in SGM and AGM.
The (SGM,AGM) could be (0,1), (0,2), or (1,2). There is no way to know.
* Similarly, if two fingers are simultaneously removed (3->1), then it
is only possible to know if SGM still contains slot[0].
* Since it is not possible to reliably track which slot is being
reported, we invalidate the tracking_id every time the number of
fingers changes until this ambiguity is resolved when:
a) All fingers are removed.
b) 4 or 5 fingers are touched, generates an AGM-CONTACT packet.
c) All fingers are removed except slot[0]. In this special case, the
ambiguity is resolved since by the (0,0,0) AGM packet.
Behavior of the driver:
When 2 or more fingers are present on the touchpad, the kernel reports
up to two MT-B slots containing the position data for two of the fingers
reported by the touchpad. If the identity of a finger cannot be tracked
when the number-of-fingers changes, the corresponding MT-B slot will be
invalidated (track_id set to -1), and a new track_id will be assigned in
a subsequent input event report.
The driver always reports the total number of fingers using one of the
EV_KEY/BTN_TOOL_*TAP events. This could differ from the number of valid
MT-B slots for two reasons:
a) There are more than 2 fingers on the pad.
b) During ambiguous number-of-fingers transitions, the correct track_id
for one or both of the slots cannot be determined, so the slots are
invalidated.
Thus, this is a hybrid singletouch/MT-B scheme. Userspace can detect
this behavior by noting that the driver supports more EV_KEY/BTN_TOOL_*TAP
events than its maximum EV_ABS/ABS_MT_SLOT.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:40 +00:00
|
|
|
if (mt_state->sgm == -1) {
|
|
|
|
synaptics_report_slot(dev, 0, NULL);
|
|
|
|
synaptics_report_slot(dev, 1, NULL);
|
|
|
|
} else if (mt_state->sgm == 0) {
|
|
|
|
synaptics_report_slot(dev, 0, sgm);
|
|
|
|
synaptics_report_slot(dev, 1, NULL);
|
|
|
|
} else {
|
|
|
|
synaptics_report_slot(dev, 0, NULL);
|
|
|
|
synaptics_report_slot(dev, 1, sgm);
|
|
|
|
}
|
Input: synaptics - add image sensor support
Synaptics makes (at least) two kinds of touchpad sensors:
* Older pads use a profile sensor that could only infer the location
of individual fingers based on the projection of their profiles
onto row and column sensors.
* Newer pads use an image sensor that can track true finger position
using a two-dimensional sensor grid.
Both sensor types support an "Advanced Gesture Mode":
When multiple fingers are detected, the touchpad sends alternating
"Advanced Gesture Mode" (AGM) and "Simple Gesture Mode" (SGM)
packets.
The AGM packets have w=2, and contain reduced resolution finger data
The SGM packets have w={0,1} and contain full resolution finger data
Profile sensors try to report the "upper" (larger y value) finger in
the SGM packet, and the lower (smaller y value) in the AGM packet.
However, due to the nature of the profile sensor, they easily get
confused when fingers cross, and can start reporting the x-coordinate
of one with the y-coordinate of the other. Thus, for profile
sensors, "semi-mt" was created, which reports a "bounding box"
created by pairing min and max coordinates of the two pairs of
reported fingers.
Image sensors can report the actual coordinates of two of the fingers
present. This patch detects if the touchpad is an image sensor and
reports finger data using the MT-B protocol.
NOTE: This patch only adds partial support for 2-finger gestures.
The proper interpretation of the slot contents when more than
two fingers are present is left to later patches. Also,
handling of 'number of fingers' transitions is incomplete.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:25 +00:00
|
|
|
break;
|
Input: synaptics - process finger (<=3) transitions
Synaptics image sensor touchpads track 5 fingers, but only report 2.
This patch attempts to deal with some idiosyncrasies of these touchpads:
* When there are 3 or more fingers, only two are reported.
* The touchpad tracks the 5 fingers in slot[0] through slot[4].
* It always reports the lowest and highest valid slots in SGM and AGM
packets, respectively.
* The number of fingers is only reported in the SGM packet. However,
the number of fingers can change either before or after an AGM
packet.
* Thus, if an SGM reports a different number of fingers than the last
SGM, it is impossible to tell whether the intervening AGM corresponds
to the old number of fingers or the new number of fingers.
* For example, when going from 2->3 fingers, it is not possible to tell
whether tell AGM contains slot[1] (old 2nd finger) or slot[2] (new
3rd finger).
* When fingers are added one at at time, from 1->2->3, it is possible to
track which slots are contained in the SGM and AGM packets:
1 finger: SGM = slot[0], no AGM
2 fingers: SGM = slot[0], AGM = slot[1]
3 fingers: SGM = slot[0], AGM = slot[2]
* It is also possible to track which slot is contained in the SGM when 1
of 2 fingers is removed. This is because the touchpad sends a special
(0,0,0) AGM packet whenever all fingers are removed except slot[0]:
Last AGM == (0,0,0): SGM contains slot[1]
Else: SGM contains slot[0]
* However, once there are 3 fingers, if exactly 1 finger is removed, it
is impossible to tell which 2 slots are contained in SGM and AGM.
The (SGM,AGM) could be (0,1), (0,2), or (1,2). There is no way to know.
* Similarly, if two fingers are simultaneously removed (3->1), then it
is only possible to know if SGM still contains slot[0].
* Since it is not possible to reliably track which slot is being
reported, we invalidate the tracking_id every time the number of
fingers changes until this ambiguity is resolved when:
a) All fingers are removed.
b) 4 or 5 fingers are touched, generates an AGM-CONTACT packet.
c) All fingers are removed except slot[0]. In this special case, the
ambiguity is resolved since by the (0,0,0) AGM packet.
Behavior of the driver:
When 2 or more fingers are present on the touchpad, the kernel reports
up to two MT-B slots containing the position data for two of the fingers
reported by the touchpad. If the identity of a finger cannot be tracked
when the number-of-fingers changes, the corresponding MT-B slot will be
invalidated (track_id set to -1), and a new track_id will be assigned in
a subsequent input event report.
The driver always reports the total number of fingers using one of the
EV_KEY/BTN_TOOL_*TAP events. This could differ from the number of valid
MT-B slots for two reasons:
a) There are more than 2 fingers on the pad.
b) During ambiguous number-of-fingers transitions, the correct track_id
for one or both of the slots cannot be determined, so the slots are
invalidated.
Thus, this is a hybrid singletouch/MT-B scheme. Userspace can detect
this behavior by noting that the driver supports more EV_KEY/BTN_TOOL_*TAP
events than its maximum EV_ABS/ABS_MT_SLOT.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:40 +00:00
|
|
|
default:
|
|
|
|
/*
|
|
|
|
* If the finger slot contained in SGM is valid, and either
|
Input: synaptics - fix 1->3 contact transition reporting
Investigating the following gesture highlighted two slight implementation
errors with choosing which slots to report in which slot when multiple
contacts are present:
Action SGM AGM (MTB slot:Contact)
1. Touch contact 0 (0:0)
2. Touch contact 1 (0:0, 1:1)
3. Lift contact 0 (1:1)
4. Touch contacts 2,3 (0:2, 1:3)
In step 4, slot 1 was not being cleared first, which means the same
tracking ID was being used for reporting both the old contact 1 and the
new contact 3. This could result in "drumroll", where the old contact 1
would appear to suddenly jump to new finger 3 position.
Similarly, if contacts 2 & 3 are not detected at the same sample, step 4
is split into two:
Action SGM AGM (MTB slot:contact)
1. Touch contact 0 (0:0)
2. Touch contact 1 (0:0, 1:1)
3. Lift contact 0 (1:1)
4. Touch contact 2 (0:2, 1:1)
5. Touch contact 3 (0:2, 1:3)
In this case, there was also a bug. In step 4, when contact 1 moves from
SGM to AGM and contact 2 is first reported in SGM, slot 0 was actually
empty. So slot 0 can be used to report the new SGM (contact 0),
immediately. Since it was empty, contact 2 in slot 0 will get a new
tracking ID.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2013-02-13 21:53:07 +00:00
|
|
|
* hasn't changed, or is new, or the old SGM has now moved to
|
|
|
|
* AGM, then report SGM in MTB slot 0.
|
Input: synaptics - process finger (<=3) transitions
Synaptics image sensor touchpads track 5 fingers, but only report 2.
This patch attempts to deal with some idiosyncrasies of these touchpads:
* When there are 3 or more fingers, only two are reported.
* The touchpad tracks the 5 fingers in slot[0] through slot[4].
* It always reports the lowest and highest valid slots in SGM and AGM
packets, respectively.
* The number of fingers is only reported in the SGM packet. However,
the number of fingers can change either before or after an AGM
packet.
* Thus, if an SGM reports a different number of fingers than the last
SGM, it is impossible to tell whether the intervening AGM corresponds
to the old number of fingers or the new number of fingers.
* For example, when going from 2->3 fingers, it is not possible to tell
whether tell AGM contains slot[1] (old 2nd finger) or slot[2] (new
3rd finger).
* When fingers are added one at at time, from 1->2->3, it is possible to
track which slots are contained in the SGM and AGM packets:
1 finger: SGM = slot[0], no AGM
2 fingers: SGM = slot[0], AGM = slot[1]
3 fingers: SGM = slot[0], AGM = slot[2]
* It is also possible to track which slot is contained in the SGM when 1
of 2 fingers is removed. This is because the touchpad sends a special
(0,0,0) AGM packet whenever all fingers are removed except slot[0]:
Last AGM == (0,0,0): SGM contains slot[1]
Else: SGM contains slot[0]
* However, once there are 3 fingers, if exactly 1 finger is removed, it
is impossible to tell which 2 slots are contained in SGM and AGM.
The (SGM,AGM) could be (0,1), (0,2), or (1,2). There is no way to know.
* Similarly, if two fingers are simultaneously removed (3->1), then it
is only possible to know if SGM still contains slot[0].
* Since it is not possible to reliably track which slot is being
reported, we invalidate the tracking_id every time the number of
fingers changes until this ambiguity is resolved when:
a) All fingers are removed.
b) 4 or 5 fingers are touched, generates an AGM-CONTACT packet.
c) All fingers are removed except slot[0]. In this special case, the
ambiguity is resolved since by the (0,0,0) AGM packet.
Behavior of the driver:
When 2 or more fingers are present on the touchpad, the kernel reports
up to two MT-B slots containing the position data for two of the fingers
reported by the touchpad. If the identity of a finger cannot be tracked
when the number-of-fingers changes, the corresponding MT-B slot will be
invalidated (track_id set to -1), and a new track_id will be assigned in
a subsequent input event report.
The driver always reports the total number of fingers using one of the
EV_KEY/BTN_TOOL_*TAP events. This could differ from the number of valid
MT-B slots for two reasons:
a) There are more than 2 fingers on the pad.
b) During ambiguous number-of-fingers transitions, the correct track_id
for one or both of the slots cannot be determined, so the slots are
invalidated.
Thus, this is a hybrid singletouch/MT-B scheme. Userspace can detect
this behavior by noting that the driver supports more EV_KEY/BTN_TOOL_*TAP
events than its maximum EV_ABS/ABS_MT_SLOT.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:40 +00:00
|
|
|
* Otherwise, empty MTB slot 0.
|
|
|
|
*/
|
|
|
|
if (mt_state->sgm != -1 &&
|
Input: synaptics - fix 1->3 contact transition reporting
Investigating the following gesture highlighted two slight implementation
errors with choosing which slots to report in which slot when multiple
contacts are present:
Action SGM AGM (MTB slot:Contact)
1. Touch contact 0 (0:0)
2. Touch contact 1 (0:0, 1:1)
3. Lift contact 0 (1:1)
4. Touch contacts 2,3 (0:2, 1:3)
In step 4, slot 1 was not being cleared first, which means the same
tracking ID was being used for reporting both the old contact 1 and the
new contact 3. This could result in "drumroll", where the old contact 1
would appear to suddenly jump to new finger 3 position.
Similarly, if contacts 2 & 3 are not detected at the same sample, step 4
is split into two:
Action SGM AGM (MTB slot:contact)
1. Touch contact 0 (0:0)
2. Touch contact 1 (0:0, 1:1)
3. Lift contact 0 (1:1)
4. Touch contact 2 (0:2, 1:1)
5. Touch contact 3 (0:2, 1:3)
In this case, there was also a bug. In step 4, when contact 1 moves from
SGM to AGM and contact 2 is first reported in SGM, slot 0 was actually
empty. So slot 0 can be used to report the new SGM (contact 0),
immediately. Since it was empty, contact 2 in slot 0 will get a new
tracking ID.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2013-02-13 21:53:07 +00:00
|
|
|
(mt_state->sgm == old->sgm ||
|
|
|
|
old->sgm == -1 || mt_state->agm == old->sgm))
|
Input: synaptics - process finger (<=3) transitions
Synaptics image sensor touchpads track 5 fingers, but only report 2.
This patch attempts to deal with some idiosyncrasies of these touchpads:
* When there are 3 or more fingers, only two are reported.
* The touchpad tracks the 5 fingers in slot[0] through slot[4].
* It always reports the lowest and highest valid slots in SGM and AGM
packets, respectively.
* The number of fingers is only reported in the SGM packet. However,
the number of fingers can change either before or after an AGM
packet.
* Thus, if an SGM reports a different number of fingers than the last
SGM, it is impossible to tell whether the intervening AGM corresponds
to the old number of fingers or the new number of fingers.
* For example, when going from 2->3 fingers, it is not possible to tell
whether tell AGM contains slot[1] (old 2nd finger) or slot[2] (new
3rd finger).
* When fingers are added one at at time, from 1->2->3, it is possible to
track which slots are contained in the SGM and AGM packets:
1 finger: SGM = slot[0], no AGM
2 fingers: SGM = slot[0], AGM = slot[1]
3 fingers: SGM = slot[0], AGM = slot[2]
* It is also possible to track which slot is contained in the SGM when 1
of 2 fingers is removed. This is because the touchpad sends a special
(0,0,0) AGM packet whenever all fingers are removed except slot[0]:
Last AGM == (0,0,0): SGM contains slot[1]
Else: SGM contains slot[0]
* However, once there are 3 fingers, if exactly 1 finger is removed, it
is impossible to tell which 2 slots are contained in SGM and AGM.
The (SGM,AGM) could be (0,1), (0,2), or (1,2). There is no way to know.
* Similarly, if two fingers are simultaneously removed (3->1), then it
is only possible to know if SGM still contains slot[0].
* Since it is not possible to reliably track which slot is being
reported, we invalidate the tracking_id every time the number of
fingers changes until this ambiguity is resolved when:
a) All fingers are removed.
b) 4 or 5 fingers are touched, generates an AGM-CONTACT packet.
c) All fingers are removed except slot[0]. In this special case, the
ambiguity is resolved since by the (0,0,0) AGM packet.
Behavior of the driver:
When 2 or more fingers are present on the touchpad, the kernel reports
up to two MT-B slots containing the position data for two of the fingers
reported by the touchpad. If the identity of a finger cannot be tracked
when the number-of-fingers changes, the corresponding MT-B slot will be
invalidated (track_id set to -1), and a new track_id will be assigned in
a subsequent input event report.
The driver always reports the total number of fingers using one of the
EV_KEY/BTN_TOOL_*TAP events. This could differ from the number of valid
MT-B slots for two reasons:
a) There are more than 2 fingers on the pad.
b) During ambiguous number-of-fingers transitions, the correct track_id
for one or both of the slots cannot be determined, so the slots are
invalidated.
Thus, this is a hybrid singletouch/MT-B scheme. Userspace can detect
this behavior by noting that the driver supports more EV_KEY/BTN_TOOL_*TAP
events than its maximum EV_ABS/ABS_MT_SLOT.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:40 +00:00
|
|
|
synaptics_report_slot(dev, 0, sgm);
|
|
|
|
else
|
|
|
|
synaptics_report_slot(dev, 0, NULL);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the finger slot contained in AGM is valid, and either
|
|
|
|
* hasn't changed, or is new, then report AGM in MTB slot 1.
|
|
|
|
* Otherwise, empty MTB slot 1.
|
Input: synaptics - fix 1->3 contact transition reporting
Investigating the following gesture highlighted two slight implementation
errors with choosing which slots to report in which slot when multiple
contacts are present:
Action SGM AGM (MTB slot:Contact)
1. Touch contact 0 (0:0)
2. Touch contact 1 (0:0, 1:1)
3. Lift contact 0 (1:1)
4. Touch contacts 2,3 (0:2, 1:3)
In step 4, slot 1 was not being cleared first, which means the same
tracking ID was being used for reporting both the old contact 1 and the
new contact 3. This could result in "drumroll", where the old contact 1
would appear to suddenly jump to new finger 3 position.
Similarly, if contacts 2 & 3 are not detected at the same sample, step 4
is split into two:
Action SGM AGM (MTB slot:contact)
1. Touch contact 0 (0:0)
2. Touch contact 1 (0:0, 1:1)
3. Lift contact 0 (1:1)
4. Touch contact 2 (0:2, 1:1)
5. Touch contact 3 (0:2, 1:3)
In this case, there was also a bug. In step 4, when contact 1 moves from
SGM to AGM and contact 2 is first reported in SGM, slot 0 was actually
empty. So slot 0 can be used to report the new SGM (contact 0),
immediately. Since it was empty, contact 2 in slot 0 will get a new
tracking ID.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2013-02-13 21:53:07 +00:00
|
|
|
*
|
|
|
|
* However, in the case where the AGM is new, make sure that
|
|
|
|
* that it is either the same as the old SGM, or there was no
|
|
|
|
* SGM.
|
|
|
|
*
|
|
|
|
* Otherwise, if the SGM was just 1, and the new AGM is 2, then
|
|
|
|
* the new AGM will keep the old SGM's tracking ID, which can
|
|
|
|
* cause apparent drumroll. This happens if in the following
|
|
|
|
* valid finger sequence:
|
|
|
|
*
|
|
|
|
* Action SGM AGM (MTB slot:Contact)
|
|
|
|
* 1. Touch contact 0 (0:0)
|
|
|
|
* 2. Touch contact 1 (0:0, 1:1)
|
|
|
|
* 3. Lift contact 0 (1:1)
|
|
|
|
* 4. Touch contacts 2,3 (0:2, 1:3)
|
|
|
|
*
|
|
|
|
* In step 4, contact 3, in AGM must not be given the same
|
|
|
|
* tracking ID as contact 1 had in step 3. To avoid this,
|
|
|
|
* the first agm with contact 3 is dropped and slot 1 is
|
|
|
|
* invalidated (tracking ID = -1).
|
Input: synaptics - process finger (<=3) transitions
Synaptics image sensor touchpads track 5 fingers, but only report 2.
This patch attempts to deal with some idiosyncrasies of these touchpads:
* When there are 3 or more fingers, only two are reported.
* The touchpad tracks the 5 fingers in slot[0] through slot[4].
* It always reports the lowest and highest valid slots in SGM and AGM
packets, respectively.
* The number of fingers is only reported in the SGM packet. However,
the number of fingers can change either before or after an AGM
packet.
* Thus, if an SGM reports a different number of fingers than the last
SGM, it is impossible to tell whether the intervening AGM corresponds
to the old number of fingers or the new number of fingers.
* For example, when going from 2->3 fingers, it is not possible to tell
whether tell AGM contains slot[1] (old 2nd finger) or slot[2] (new
3rd finger).
* When fingers are added one at at time, from 1->2->3, it is possible to
track which slots are contained in the SGM and AGM packets:
1 finger: SGM = slot[0], no AGM
2 fingers: SGM = slot[0], AGM = slot[1]
3 fingers: SGM = slot[0], AGM = slot[2]
* It is also possible to track which slot is contained in the SGM when 1
of 2 fingers is removed. This is because the touchpad sends a special
(0,0,0) AGM packet whenever all fingers are removed except slot[0]:
Last AGM == (0,0,0): SGM contains slot[1]
Else: SGM contains slot[0]
* However, once there are 3 fingers, if exactly 1 finger is removed, it
is impossible to tell which 2 slots are contained in SGM and AGM.
The (SGM,AGM) could be (0,1), (0,2), or (1,2). There is no way to know.
* Similarly, if two fingers are simultaneously removed (3->1), then it
is only possible to know if SGM still contains slot[0].
* Since it is not possible to reliably track which slot is being
reported, we invalidate the tracking_id every time the number of
fingers changes until this ambiguity is resolved when:
a) All fingers are removed.
b) 4 or 5 fingers are touched, generates an AGM-CONTACT packet.
c) All fingers are removed except slot[0]. In this special case, the
ambiguity is resolved since by the (0,0,0) AGM packet.
Behavior of the driver:
When 2 or more fingers are present on the touchpad, the kernel reports
up to two MT-B slots containing the position data for two of the fingers
reported by the touchpad. If the identity of a finger cannot be tracked
when the number-of-fingers changes, the corresponding MT-B slot will be
invalidated (track_id set to -1), and a new track_id will be assigned in
a subsequent input event report.
The driver always reports the total number of fingers using one of the
EV_KEY/BTN_TOOL_*TAP events. This could differ from the number of valid
MT-B slots for two reasons:
a) There are more than 2 fingers on the pad.
b) During ambiguous number-of-fingers transitions, the correct track_id
for one or both of the slots cannot be determined, so the slots are
invalidated.
Thus, this is a hybrid singletouch/MT-B scheme. Userspace can detect
this behavior by noting that the driver supports more EV_KEY/BTN_TOOL_*TAP
events than its maximum EV_ABS/ABS_MT_SLOT.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:40 +00:00
|
|
|
*/
|
|
|
|
if (mt_state->agm != -1 &&
|
Input: synaptics - fix 1->3 contact transition reporting
Investigating the following gesture highlighted two slight implementation
errors with choosing which slots to report in which slot when multiple
contacts are present:
Action SGM AGM (MTB slot:Contact)
1. Touch contact 0 (0:0)
2. Touch contact 1 (0:0, 1:1)
3. Lift contact 0 (1:1)
4. Touch contacts 2,3 (0:2, 1:3)
In step 4, slot 1 was not being cleared first, which means the same
tracking ID was being used for reporting both the old contact 1 and the
new contact 3. This could result in "drumroll", where the old contact 1
would appear to suddenly jump to new finger 3 position.
Similarly, if contacts 2 & 3 are not detected at the same sample, step 4
is split into two:
Action SGM AGM (MTB slot:contact)
1. Touch contact 0 (0:0)
2. Touch contact 1 (0:0, 1:1)
3. Lift contact 0 (1:1)
4. Touch contact 2 (0:2, 1:1)
5. Touch contact 3 (0:2, 1:3)
In this case, there was also a bug. In step 4, when contact 1 moves from
SGM to AGM and contact 2 is first reported in SGM, slot 0 was actually
empty. So slot 0 can be used to report the new SGM (contact 0),
immediately. Since it was empty, contact 2 in slot 0 will get a new
tracking ID.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2013-02-13 21:53:07 +00:00
|
|
|
(mt_state->agm == old->agm ||
|
|
|
|
(old->agm == -1 &&
|
|
|
|
(old->sgm == -1 || mt_state->agm == old->sgm))))
|
Input: synaptics - process finger (<=3) transitions
Synaptics image sensor touchpads track 5 fingers, but only report 2.
This patch attempts to deal with some idiosyncrasies of these touchpads:
* When there are 3 or more fingers, only two are reported.
* The touchpad tracks the 5 fingers in slot[0] through slot[4].
* It always reports the lowest and highest valid slots in SGM and AGM
packets, respectively.
* The number of fingers is only reported in the SGM packet. However,
the number of fingers can change either before or after an AGM
packet.
* Thus, if an SGM reports a different number of fingers than the last
SGM, it is impossible to tell whether the intervening AGM corresponds
to the old number of fingers or the new number of fingers.
* For example, when going from 2->3 fingers, it is not possible to tell
whether tell AGM contains slot[1] (old 2nd finger) or slot[2] (new
3rd finger).
* When fingers are added one at at time, from 1->2->3, it is possible to
track which slots are contained in the SGM and AGM packets:
1 finger: SGM = slot[0], no AGM
2 fingers: SGM = slot[0], AGM = slot[1]
3 fingers: SGM = slot[0], AGM = slot[2]
* It is also possible to track which slot is contained in the SGM when 1
of 2 fingers is removed. This is because the touchpad sends a special
(0,0,0) AGM packet whenever all fingers are removed except slot[0]:
Last AGM == (0,0,0): SGM contains slot[1]
Else: SGM contains slot[0]
* However, once there are 3 fingers, if exactly 1 finger is removed, it
is impossible to tell which 2 slots are contained in SGM and AGM.
The (SGM,AGM) could be (0,1), (0,2), or (1,2). There is no way to know.
* Similarly, if two fingers are simultaneously removed (3->1), then it
is only possible to know if SGM still contains slot[0].
* Since it is not possible to reliably track which slot is being
reported, we invalidate the tracking_id every time the number of
fingers changes until this ambiguity is resolved when:
a) All fingers are removed.
b) 4 or 5 fingers are touched, generates an AGM-CONTACT packet.
c) All fingers are removed except slot[0]. In this special case, the
ambiguity is resolved since by the (0,0,0) AGM packet.
Behavior of the driver:
When 2 or more fingers are present on the touchpad, the kernel reports
up to two MT-B slots containing the position data for two of the fingers
reported by the touchpad. If the identity of a finger cannot be tracked
when the number-of-fingers changes, the corresponding MT-B slot will be
invalidated (track_id set to -1), and a new track_id will be assigned in
a subsequent input event report.
The driver always reports the total number of fingers using one of the
EV_KEY/BTN_TOOL_*TAP events. This could differ from the number of valid
MT-B slots for two reasons:
a) There are more than 2 fingers on the pad.
b) During ambiguous number-of-fingers transitions, the correct track_id
for one or both of the slots cannot be determined, so the slots are
invalidated.
Thus, this is a hybrid singletouch/MT-B scheme. Userspace can detect
this behavior by noting that the driver supports more EV_KEY/BTN_TOOL_*TAP
events than its maximum EV_ABS/ABS_MT_SLOT.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:40 +00:00
|
|
|
synaptics_report_slot(dev, 1, agm);
|
|
|
|
else
|
|
|
|
synaptics_report_slot(dev, 1, NULL);
|
Input: synaptics - add image sensor support
Synaptics makes (at least) two kinds of touchpad sensors:
* Older pads use a profile sensor that could only infer the location
of individual fingers based on the projection of their profiles
onto row and column sensors.
* Newer pads use an image sensor that can track true finger position
using a two-dimensional sensor grid.
Both sensor types support an "Advanced Gesture Mode":
When multiple fingers are detected, the touchpad sends alternating
"Advanced Gesture Mode" (AGM) and "Simple Gesture Mode" (SGM)
packets.
The AGM packets have w=2, and contain reduced resolution finger data
The SGM packets have w={0,1} and contain full resolution finger data
Profile sensors try to report the "upper" (larger y value) finger in
the SGM packet, and the lower (smaller y value) in the AGM packet.
However, due to the nature of the profile sensor, they easily get
confused when fingers cross, and can start reporting the x-coordinate
of one with the y-coordinate of the other. Thus, for profile
sensors, "semi-mt" was created, which reports a "bounding box"
created by pairing min and max coordinates of the two pairs of
reported fingers.
Image sensors can report the actual coordinates of two of the fingers
present. This patch detects if the touchpad is an image sensor and
reports finger data using the MT-B protocol.
NOTE: This patch only adds partial support for 2-finger gestures.
The proper interpretation of the slot contents when more than
two fingers are present is left to later patches. Also,
handling of 'number of fingers' transitions is incomplete.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:25 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Don't use active slot count to generate BTN_TOOL events. */
|
|
|
|
input_mt_report_pointer_emulation(dev, false);
|
|
|
|
|
|
|
|
/* Send the number of fingers reported by touchpad itself. */
|
Input: synaptics - process finger (<=3) transitions
Synaptics image sensor touchpads track 5 fingers, but only report 2.
This patch attempts to deal with some idiosyncrasies of these touchpads:
* When there are 3 or more fingers, only two are reported.
* The touchpad tracks the 5 fingers in slot[0] through slot[4].
* It always reports the lowest and highest valid slots in SGM and AGM
packets, respectively.
* The number of fingers is only reported in the SGM packet. However,
the number of fingers can change either before or after an AGM
packet.
* Thus, if an SGM reports a different number of fingers than the last
SGM, it is impossible to tell whether the intervening AGM corresponds
to the old number of fingers or the new number of fingers.
* For example, when going from 2->3 fingers, it is not possible to tell
whether tell AGM contains slot[1] (old 2nd finger) or slot[2] (new
3rd finger).
* When fingers are added one at at time, from 1->2->3, it is possible to
track which slots are contained in the SGM and AGM packets:
1 finger: SGM = slot[0], no AGM
2 fingers: SGM = slot[0], AGM = slot[1]
3 fingers: SGM = slot[0], AGM = slot[2]
* It is also possible to track which slot is contained in the SGM when 1
of 2 fingers is removed. This is because the touchpad sends a special
(0,0,0) AGM packet whenever all fingers are removed except slot[0]:
Last AGM == (0,0,0): SGM contains slot[1]
Else: SGM contains slot[0]
* However, once there are 3 fingers, if exactly 1 finger is removed, it
is impossible to tell which 2 slots are contained in SGM and AGM.
The (SGM,AGM) could be (0,1), (0,2), or (1,2). There is no way to know.
* Similarly, if two fingers are simultaneously removed (3->1), then it
is only possible to know if SGM still contains slot[0].
* Since it is not possible to reliably track which slot is being
reported, we invalidate the tracking_id every time the number of
fingers changes until this ambiguity is resolved when:
a) All fingers are removed.
b) 4 or 5 fingers are touched, generates an AGM-CONTACT packet.
c) All fingers are removed except slot[0]. In this special case, the
ambiguity is resolved since by the (0,0,0) AGM packet.
Behavior of the driver:
When 2 or more fingers are present on the touchpad, the kernel reports
up to two MT-B slots containing the position data for two of the fingers
reported by the touchpad. If the identity of a finger cannot be tracked
when the number-of-fingers changes, the corresponding MT-B slot will be
invalidated (track_id set to -1), and a new track_id will be assigned in
a subsequent input event report.
The driver always reports the total number of fingers using one of the
EV_KEY/BTN_TOOL_*TAP events. This could differ from the number of valid
MT-B slots for two reasons:
a) There are more than 2 fingers on the pad.
b) During ambiguous number-of-fingers transitions, the correct track_id
for one or both of the slots cannot be determined, so the slots are
invalidated.
Thus, this is a hybrid singletouch/MT-B scheme. Userspace can detect
this behavior by noting that the driver supports more EV_KEY/BTN_TOOL_*TAP
events than its maximum EV_ABS/ABS_MT_SLOT.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:40 +00:00
|
|
|
input_mt_report_finger_count(dev, mt_state->count);
|
Input: synaptics - add image sensor support
Synaptics makes (at least) two kinds of touchpad sensors:
* Older pads use a profile sensor that could only infer the location
of individual fingers based on the projection of their profiles
onto row and column sensors.
* Newer pads use an image sensor that can track true finger position
using a two-dimensional sensor grid.
Both sensor types support an "Advanced Gesture Mode":
When multiple fingers are detected, the touchpad sends alternating
"Advanced Gesture Mode" (AGM) and "Simple Gesture Mode" (SGM)
packets.
The AGM packets have w=2, and contain reduced resolution finger data
The SGM packets have w={0,1} and contain full resolution finger data
Profile sensors try to report the "upper" (larger y value) finger in
the SGM packet, and the lower (smaller y value) in the AGM packet.
However, due to the nature of the profile sensor, they easily get
confused when fingers cross, and can start reporting the x-coordinate
of one with the y-coordinate of the other. Thus, for profile
sensors, "semi-mt" was created, which reports a "bounding box"
created by pairing min and max coordinates of the two pairs of
reported fingers.
Image sensors can report the actual coordinates of two of the fingers
present. This patch detects if the touchpad is an image sensor and
reports finger data using the MT-B protocol.
NOTE: This patch only adds partial support for 2-finger gestures.
The proper interpretation of the slot contents when more than
two fingers are present is left to later patches. Also,
handling of 'number of fingers' transitions is incomplete.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:25 +00:00
|
|
|
|
|
|
|
synaptics_report_buttons(psmouse, sgm);
|
|
|
|
|
|
|
|
input_sync(dev);
|
|
|
|
}
|
|
|
|
|
Input: synaptics - process finger (<=3) transitions
Synaptics image sensor touchpads track 5 fingers, but only report 2.
This patch attempts to deal with some idiosyncrasies of these touchpads:
* When there are 3 or more fingers, only two are reported.
* The touchpad tracks the 5 fingers in slot[0] through slot[4].
* It always reports the lowest and highest valid slots in SGM and AGM
packets, respectively.
* The number of fingers is only reported in the SGM packet. However,
the number of fingers can change either before or after an AGM
packet.
* Thus, if an SGM reports a different number of fingers than the last
SGM, it is impossible to tell whether the intervening AGM corresponds
to the old number of fingers or the new number of fingers.
* For example, when going from 2->3 fingers, it is not possible to tell
whether tell AGM contains slot[1] (old 2nd finger) or slot[2] (new
3rd finger).
* When fingers are added one at at time, from 1->2->3, it is possible to
track which slots are contained in the SGM and AGM packets:
1 finger: SGM = slot[0], no AGM
2 fingers: SGM = slot[0], AGM = slot[1]
3 fingers: SGM = slot[0], AGM = slot[2]
* It is also possible to track which slot is contained in the SGM when 1
of 2 fingers is removed. This is because the touchpad sends a special
(0,0,0) AGM packet whenever all fingers are removed except slot[0]:
Last AGM == (0,0,0): SGM contains slot[1]
Else: SGM contains slot[0]
* However, once there are 3 fingers, if exactly 1 finger is removed, it
is impossible to tell which 2 slots are contained in SGM and AGM.
The (SGM,AGM) could be (0,1), (0,2), or (1,2). There is no way to know.
* Similarly, if two fingers are simultaneously removed (3->1), then it
is only possible to know if SGM still contains slot[0].
* Since it is not possible to reliably track which slot is being
reported, we invalidate the tracking_id every time the number of
fingers changes until this ambiguity is resolved when:
a) All fingers are removed.
b) 4 or 5 fingers are touched, generates an AGM-CONTACT packet.
c) All fingers are removed except slot[0]. In this special case, the
ambiguity is resolved since by the (0,0,0) AGM packet.
Behavior of the driver:
When 2 or more fingers are present on the touchpad, the kernel reports
up to two MT-B slots containing the position data for two of the fingers
reported by the touchpad. If the identity of a finger cannot be tracked
when the number-of-fingers changes, the corresponding MT-B slot will be
invalidated (track_id set to -1), and a new track_id will be assigned in
a subsequent input event report.
The driver always reports the total number of fingers using one of the
EV_KEY/BTN_TOOL_*TAP events. This could differ from the number of valid
MT-B slots for two reasons:
a) There are more than 2 fingers on the pad.
b) During ambiguous number-of-fingers transitions, the correct track_id
for one or both of the slots cannot be determined, so the slots are
invalidated.
Thus, this is a hybrid singletouch/MT-B scheme. Userspace can detect
this behavior by noting that the driver supports more EV_KEY/BTN_TOOL_*TAP
events than its maximum EV_ABS/ABS_MT_SLOT.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:40 +00:00
|
|
|
/* Handle case where mt_state->count = 0 */
|
|
|
|
static void synaptics_image_sensor_0f(struct synaptics_data *priv,
|
|
|
|
struct synaptics_mt_state *mt_state)
|
|
|
|
{
|
|
|
|
synaptics_mt_state_set(mt_state, 0, -1, -1);
|
|
|
|
priv->mt_state_lost = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Handle case where mt_state->count = 1 */
|
|
|
|
static void synaptics_image_sensor_1f(struct synaptics_data *priv,
|
|
|
|
struct synaptics_mt_state *mt_state)
|
|
|
|
{
|
|
|
|
struct synaptics_hw_state *agm = &priv->agm;
|
|
|
|
struct synaptics_mt_state *old = &priv->mt_state;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the last AGM was (0,0,0), and there is only one finger left,
|
|
|
|
* then we absolutely know that SGM contains slot 0, and all other
|
|
|
|
* fingers have been removed.
|
|
|
|
*/
|
|
|
|
if (priv->agm_pending && agm->z == 0) {
|
|
|
|
synaptics_mt_state_set(mt_state, 1, 0, -1);
|
|
|
|
priv->mt_state_lost = false;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (old->count) {
|
|
|
|
case 0:
|
|
|
|
synaptics_mt_state_set(mt_state, 1, 0, -1);
|
|
|
|
break;
|
|
|
|
case 1:
|
|
|
|
/*
|
|
|
|
* If mt_state_lost, then the previous transition was 3->1,
|
|
|
|
* and SGM now contains either slot 0 or 1, but we don't know
|
|
|
|
* which. So, we just assume that the SGM now contains slot 1.
|
|
|
|
*
|
|
|
|
* If pending AGM and either:
|
|
|
|
* (a) the previous SGM slot contains slot 0, or
|
|
|
|
* (b) there was no SGM slot
|
|
|
|
* then, the SGM now contains slot 1
|
|
|
|
*
|
|
|
|
* Case (a) happens with very rapid "drum roll" gestures, where
|
|
|
|
* slot 0 finger is lifted and a new slot 1 finger touches
|
|
|
|
* within one reporting interval.
|
|
|
|
*
|
|
|
|
* Case (b) happens if initially two or more fingers tap
|
|
|
|
* briefly, and all but one lift before the end of the first
|
|
|
|
* reporting interval.
|
|
|
|
*
|
|
|
|
* (In both these cases, slot 0 will becomes empty, so SGM
|
|
|
|
* contains slot 1 with the new finger)
|
|
|
|
*
|
|
|
|
* Else, if there was no previous SGM, it now contains slot 0.
|
|
|
|
*
|
|
|
|
* Otherwise, SGM still contains the same slot.
|
|
|
|
*/
|
|
|
|
if (priv->mt_state_lost ||
|
|
|
|
(priv->agm_pending && old->sgm <= 0))
|
|
|
|
synaptics_mt_state_set(mt_state, 1, 1, -1);
|
|
|
|
else if (old->sgm == -1)
|
|
|
|
synaptics_mt_state_set(mt_state, 1, 0, -1);
|
|
|
|
break;
|
|
|
|
case 2:
|
|
|
|
/*
|
|
|
|
* If mt_state_lost, we don't know which finger SGM contains.
|
|
|
|
*
|
|
|
|
* So, report 1 finger, but with both slots empty.
|
|
|
|
* We will use slot 1 on subsequent 1->1
|
|
|
|
*/
|
|
|
|
if (priv->mt_state_lost) {
|
|
|
|
synaptics_mt_state_set(mt_state, 1, -1, -1);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* Since the last AGM was NOT (0,0,0), it was the finger in
|
|
|
|
* slot 0 that has been removed.
|
|
|
|
* So, SGM now contains previous AGM's slot, and AGM is now
|
|
|
|
* empty.
|
|
|
|
*/
|
|
|
|
synaptics_mt_state_set(mt_state, 1, old->agm, -1);
|
|
|
|
break;
|
|
|
|
case 3:
|
|
|
|
/*
|
|
|
|
* Since last AGM was not (0,0,0), we don't know which finger
|
|
|
|
* is left.
|
|
|
|
*
|
|
|
|
* So, report 1 finger, but with both slots empty.
|
|
|
|
* We will use slot 1 on subsequent 1->1
|
|
|
|
*/
|
|
|
|
synaptics_mt_state_set(mt_state, 1, -1, -1);
|
|
|
|
priv->mt_state_lost = true;
|
|
|
|
break;
|
2011-08-24 06:02:56 +00:00
|
|
|
case 4:
|
|
|
|
case 5:
|
|
|
|
/* mt_state was updated by AGM-CONTACT packet */
|
|
|
|
break;
|
Input: synaptics - process finger (<=3) transitions
Synaptics image sensor touchpads track 5 fingers, but only report 2.
This patch attempts to deal with some idiosyncrasies of these touchpads:
* When there are 3 or more fingers, only two are reported.
* The touchpad tracks the 5 fingers in slot[0] through slot[4].
* It always reports the lowest and highest valid slots in SGM and AGM
packets, respectively.
* The number of fingers is only reported in the SGM packet. However,
the number of fingers can change either before or after an AGM
packet.
* Thus, if an SGM reports a different number of fingers than the last
SGM, it is impossible to tell whether the intervening AGM corresponds
to the old number of fingers or the new number of fingers.
* For example, when going from 2->3 fingers, it is not possible to tell
whether tell AGM contains slot[1] (old 2nd finger) or slot[2] (new
3rd finger).
* When fingers are added one at at time, from 1->2->3, it is possible to
track which slots are contained in the SGM and AGM packets:
1 finger: SGM = slot[0], no AGM
2 fingers: SGM = slot[0], AGM = slot[1]
3 fingers: SGM = slot[0], AGM = slot[2]
* It is also possible to track which slot is contained in the SGM when 1
of 2 fingers is removed. This is because the touchpad sends a special
(0,0,0) AGM packet whenever all fingers are removed except slot[0]:
Last AGM == (0,0,0): SGM contains slot[1]
Else: SGM contains slot[0]
* However, once there are 3 fingers, if exactly 1 finger is removed, it
is impossible to tell which 2 slots are contained in SGM and AGM.
The (SGM,AGM) could be (0,1), (0,2), or (1,2). There is no way to know.
* Similarly, if two fingers are simultaneously removed (3->1), then it
is only possible to know if SGM still contains slot[0].
* Since it is not possible to reliably track which slot is being
reported, we invalidate the tracking_id every time the number of
fingers changes until this ambiguity is resolved when:
a) All fingers are removed.
b) 4 or 5 fingers are touched, generates an AGM-CONTACT packet.
c) All fingers are removed except slot[0]. In this special case, the
ambiguity is resolved since by the (0,0,0) AGM packet.
Behavior of the driver:
When 2 or more fingers are present on the touchpad, the kernel reports
up to two MT-B slots containing the position data for two of the fingers
reported by the touchpad. If the identity of a finger cannot be tracked
when the number-of-fingers changes, the corresponding MT-B slot will be
invalidated (track_id set to -1), and a new track_id will be assigned in
a subsequent input event report.
The driver always reports the total number of fingers using one of the
EV_KEY/BTN_TOOL_*TAP events. This could differ from the number of valid
MT-B slots for two reasons:
a) There are more than 2 fingers on the pad.
b) During ambiguous number-of-fingers transitions, the correct track_id
for one or both of the slots cannot be determined, so the slots are
invalidated.
Thus, this is a hybrid singletouch/MT-B scheme. Userspace can detect
this behavior by noting that the driver supports more EV_KEY/BTN_TOOL_*TAP
events than its maximum EV_ABS/ABS_MT_SLOT.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:40 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Handle case where mt_state->count = 2 */
|
|
|
|
static void synaptics_image_sensor_2f(struct synaptics_data *priv,
|
|
|
|
struct synaptics_mt_state *mt_state)
|
|
|
|
{
|
|
|
|
struct synaptics_mt_state *old = &priv->mt_state;
|
|
|
|
|
|
|
|
switch (old->count) {
|
|
|
|
case 0:
|
|
|
|
synaptics_mt_state_set(mt_state, 2, 0, 1);
|
|
|
|
break;
|
|
|
|
case 1:
|
|
|
|
/*
|
|
|
|
* If previous SGM contained slot 1 or higher, SGM now contains
|
|
|
|
* slot 0 (the newly touching finger) and AGM contains SGM's
|
|
|
|
* previous slot.
|
|
|
|
*
|
|
|
|
* Otherwise, SGM still contains slot 0 and AGM now contains
|
|
|
|
* slot 1.
|
|
|
|
*/
|
|
|
|
if (old->sgm >= 1)
|
|
|
|
synaptics_mt_state_set(mt_state, 2, 0, old->sgm);
|
|
|
|
else
|
|
|
|
synaptics_mt_state_set(mt_state, 2, 0, 1);
|
|
|
|
break;
|
|
|
|
case 2:
|
|
|
|
/*
|
|
|
|
* If mt_state_lost, SGM now contains either finger 1 or 2, but
|
|
|
|
* we don't know which.
|
|
|
|
* So, we just assume that the SGM contains slot 0 and AGM 1.
|
|
|
|
*/
|
|
|
|
if (priv->mt_state_lost)
|
|
|
|
synaptics_mt_state_set(mt_state, 2, 0, 1);
|
|
|
|
/*
|
|
|
|
* Otherwise, use the same mt_state, since it either hasn't
|
|
|
|
* changed, or was updated by a recently received AGM-CONTACT
|
|
|
|
* packet.
|
|
|
|
*/
|
|
|
|
break;
|
|
|
|
case 3:
|
|
|
|
/*
|
|
|
|
* 3->2 transitions have two unsolvable problems:
|
|
|
|
* 1) no indication is given which finger was removed
|
|
|
|
* 2) no way to tell if agm packet was for finger 3
|
|
|
|
* before 3->2, or finger 2 after 3->2.
|
|
|
|
*
|
|
|
|
* So, report 2 fingers, but empty all slots.
|
|
|
|
* We will guess slots [0,1] on subsequent 2->2.
|
|
|
|
*/
|
|
|
|
synaptics_mt_state_set(mt_state, 2, -1, -1);
|
|
|
|
priv->mt_state_lost = true;
|
|
|
|
break;
|
2011-08-24 06:02:56 +00:00
|
|
|
case 4:
|
|
|
|
case 5:
|
|
|
|
/* mt_state was updated by AGM-CONTACT packet */
|
|
|
|
break;
|
Input: synaptics - process finger (<=3) transitions
Synaptics image sensor touchpads track 5 fingers, but only report 2.
This patch attempts to deal with some idiosyncrasies of these touchpads:
* When there are 3 or more fingers, only two are reported.
* The touchpad tracks the 5 fingers in slot[0] through slot[4].
* It always reports the lowest and highest valid slots in SGM and AGM
packets, respectively.
* The number of fingers is only reported in the SGM packet. However,
the number of fingers can change either before or after an AGM
packet.
* Thus, if an SGM reports a different number of fingers than the last
SGM, it is impossible to tell whether the intervening AGM corresponds
to the old number of fingers or the new number of fingers.
* For example, when going from 2->3 fingers, it is not possible to tell
whether tell AGM contains slot[1] (old 2nd finger) or slot[2] (new
3rd finger).
* When fingers are added one at at time, from 1->2->3, it is possible to
track which slots are contained in the SGM and AGM packets:
1 finger: SGM = slot[0], no AGM
2 fingers: SGM = slot[0], AGM = slot[1]
3 fingers: SGM = slot[0], AGM = slot[2]
* It is also possible to track which slot is contained in the SGM when 1
of 2 fingers is removed. This is because the touchpad sends a special
(0,0,0) AGM packet whenever all fingers are removed except slot[0]:
Last AGM == (0,0,0): SGM contains slot[1]
Else: SGM contains slot[0]
* However, once there are 3 fingers, if exactly 1 finger is removed, it
is impossible to tell which 2 slots are contained in SGM and AGM.
The (SGM,AGM) could be (0,1), (0,2), or (1,2). There is no way to know.
* Similarly, if two fingers are simultaneously removed (3->1), then it
is only possible to know if SGM still contains slot[0].
* Since it is not possible to reliably track which slot is being
reported, we invalidate the tracking_id every time the number of
fingers changes until this ambiguity is resolved when:
a) All fingers are removed.
b) 4 or 5 fingers are touched, generates an AGM-CONTACT packet.
c) All fingers are removed except slot[0]. In this special case, the
ambiguity is resolved since by the (0,0,0) AGM packet.
Behavior of the driver:
When 2 or more fingers are present on the touchpad, the kernel reports
up to two MT-B slots containing the position data for two of the fingers
reported by the touchpad. If the identity of a finger cannot be tracked
when the number-of-fingers changes, the corresponding MT-B slot will be
invalidated (track_id set to -1), and a new track_id will be assigned in
a subsequent input event report.
The driver always reports the total number of fingers using one of the
EV_KEY/BTN_TOOL_*TAP events. This could differ from the number of valid
MT-B slots for two reasons:
a) There are more than 2 fingers on the pad.
b) During ambiguous number-of-fingers transitions, the correct track_id
for one or both of the slots cannot be determined, so the slots are
invalidated.
Thus, this is a hybrid singletouch/MT-B scheme. Userspace can detect
this behavior by noting that the driver supports more EV_KEY/BTN_TOOL_*TAP
events than its maximum EV_ABS/ABS_MT_SLOT.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:40 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Handle case where mt_state->count = 3 */
|
|
|
|
static void synaptics_image_sensor_3f(struct synaptics_data *priv,
|
|
|
|
struct synaptics_mt_state *mt_state)
|
|
|
|
{
|
|
|
|
struct synaptics_mt_state *old = &priv->mt_state;
|
|
|
|
|
|
|
|
switch (old->count) {
|
|
|
|
case 0:
|
|
|
|
synaptics_mt_state_set(mt_state, 3, 0, 2);
|
|
|
|
break;
|
|
|
|
case 1:
|
|
|
|
/*
|
|
|
|
* If previous SGM contained slot 2 or higher, SGM now contains
|
|
|
|
* slot 0 (one of the newly touching fingers) and AGM contains
|
|
|
|
* SGM's previous slot.
|
|
|
|
*
|
|
|
|
* Otherwise, SGM now contains slot 0 and AGM contains slot 2.
|
|
|
|
*/
|
|
|
|
if (old->sgm >= 2)
|
|
|
|
synaptics_mt_state_set(mt_state, 3, 0, old->sgm);
|
|
|
|
else
|
|
|
|
synaptics_mt_state_set(mt_state, 3, 0, 2);
|
|
|
|
break;
|
|
|
|
case 2:
|
2011-08-24 06:02:56 +00:00
|
|
|
/*
|
|
|
|
* If the AGM previously contained slot 3 or higher, then the
|
|
|
|
* newly touching finger is in the lowest available slot.
|
|
|
|
*
|
|
|
|
* If SGM was previously 1 or higher, then the new SGM is
|
|
|
|
* now slot 0 (with a new finger), otherwise, the new finger
|
|
|
|
* is now in a hidden slot between 0 and AGM's slot.
|
|
|
|
*
|
|
|
|
* In all such cases, the SGM now contains slot 0, and the AGM
|
|
|
|
* continues to contain the same slot as before.
|
|
|
|
*/
|
|
|
|
if (old->agm >= 3) {
|
|
|
|
synaptics_mt_state_set(mt_state, 3, 0, old->agm);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
Input: synaptics - process finger (<=3) transitions
Synaptics image sensor touchpads track 5 fingers, but only report 2.
This patch attempts to deal with some idiosyncrasies of these touchpads:
* When there are 3 or more fingers, only two are reported.
* The touchpad tracks the 5 fingers in slot[0] through slot[4].
* It always reports the lowest and highest valid slots in SGM and AGM
packets, respectively.
* The number of fingers is only reported in the SGM packet. However,
the number of fingers can change either before or after an AGM
packet.
* Thus, if an SGM reports a different number of fingers than the last
SGM, it is impossible to tell whether the intervening AGM corresponds
to the old number of fingers or the new number of fingers.
* For example, when going from 2->3 fingers, it is not possible to tell
whether tell AGM contains slot[1] (old 2nd finger) or slot[2] (new
3rd finger).
* When fingers are added one at at time, from 1->2->3, it is possible to
track which slots are contained in the SGM and AGM packets:
1 finger: SGM = slot[0], no AGM
2 fingers: SGM = slot[0], AGM = slot[1]
3 fingers: SGM = slot[0], AGM = slot[2]
* It is also possible to track which slot is contained in the SGM when 1
of 2 fingers is removed. This is because the touchpad sends a special
(0,0,0) AGM packet whenever all fingers are removed except slot[0]:
Last AGM == (0,0,0): SGM contains slot[1]
Else: SGM contains slot[0]
* However, once there are 3 fingers, if exactly 1 finger is removed, it
is impossible to tell which 2 slots are contained in SGM and AGM.
The (SGM,AGM) could be (0,1), (0,2), or (1,2). There is no way to know.
* Similarly, if two fingers are simultaneously removed (3->1), then it
is only possible to know if SGM still contains slot[0].
* Since it is not possible to reliably track which slot is being
reported, we invalidate the tracking_id every time the number of
fingers changes until this ambiguity is resolved when:
a) All fingers are removed.
b) 4 or 5 fingers are touched, generates an AGM-CONTACT packet.
c) All fingers are removed except slot[0]. In this special case, the
ambiguity is resolved since by the (0,0,0) AGM packet.
Behavior of the driver:
When 2 or more fingers are present on the touchpad, the kernel reports
up to two MT-B slots containing the position data for two of the fingers
reported by the touchpad. If the identity of a finger cannot be tracked
when the number-of-fingers changes, the corresponding MT-B slot will be
invalidated (track_id set to -1), and a new track_id will be assigned in
a subsequent input event report.
The driver always reports the total number of fingers using one of the
EV_KEY/BTN_TOOL_*TAP events. This could differ from the number of valid
MT-B slots for two reasons:
a) There are more than 2 fingers on the pad.
b) During ambiguous number-of-fingers transitions, the correct track_id
for one or both of the slots cannot be determined, so the slots are
invalidated.
Thus, this is a hybrid singletouch/MT-B scheme. Userspace can detect
this behavior by noting that the driver supports more EV_KEY/BTN_TOOL_*TAP
events than its maximum EV_ABS/ABS_MT_SLOT.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:40 +00:00
|
|
|
/*
|
|
|
|
* After some 3->1 and all 3->2 transitions, we lose track
|
|
|
|
* of which slot is reported by SGM and AGM.
|
|
|
|
*
|
|
|
|
* For 2->3 in this state, report 3 fingers, but empty all
|
|
|
|
* slots, and we will guess (0,2) on a subsequent 0->3.
|
|
|
|
*
|
|
|
|
* To userspace, the resulting transition will look like:
|
|
|
|
* 2:[0,1] -> 3:[-1,-1] -> 3:[0,2]
|
|
|
|
*/
|
|
|
|
if (priv->mt_state_lost) {
|
|
|
|
synaptics_mt_state_set(mt_state, 3, -1, -1);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the (SGM,AGM) really previously contained slots (0, 1),
|
|
|
|
* then we cannot know what slot was just reported by the AGM,
|
|
|
|
* because the 2->3 transition can occur either before or after
|
|
|
|
* the AGM packet. Thus, this most recent AGM could contain
|
|
|
|
* either the same old slot 1 or the new slot 2.
|
|
|
|
* Subsequent AGMs will be reporting slot 2.
|
|
|
|
*
|
|
|
|
* To userspace, the resulting transition will look like:
|
|
|
|
* 2:[0,1] -> 3:[0,-1] -> 3:[0,2]
|
|
|
|
*/
|
|
|
|
synaptics_mt_state_set(mt_state, 3, 0, -1);
|
|
|
|
break;
|
|
|
|
case 3:
|
|
|
|
/*
|
|
|
|
* If, for whatever reason, the previous agm was invalid,
|
|
|
|
* Assume SGM now contains slot 0, AGM now contains slot 2.
|
|
|
|
*/
|
|
|
|
if (old->agm <= 2)
|
|
|
|
synaptics_mt_state_set(mt_state, 3, 0, 2);
|
|
|
|
/*
|
|
|
|
* mt_state either hasn't changed, or was updated by a recently
|
|
|
|
* received AGM-CONTACT packet.
|
|
|
|
*/
|
|
|
|
break;
|
2011-08-24 06:02:56 +00:00
|
|
|
|
|
|
|
case 4:
|
|
|
|
case 5:
|
|
|
|
/* mt_state was updated by AGM-CONTACT packet */
|
|
|
|
break;
|
Input: synaptics - process finger (<=3) transitions
Synaptics image sensor touchpads track 5 fingers, but only report 2.
This patch attempts to deal with some idiosyncrasies of these touchpads:
* When there are 3 or more fingers, only two are reported.
* The touchpad tracks the 5 fingers in slot[0] through slot[4].
* It always reports the lowest and highest valid slots in SGM and AGM
packets, respectively.
* The number of fingers is only reported in the SGM packet. However,
the number of fingers can change either before or after an AGM
packet.
* Thus, if an SGM reports a different number of fingers than the last
SGM, it is impossible to tell whether the intervening AGM corresponds
to the old number of fingers or the new number of fingers.
* For example, when going from 2->3 fingers, it is not possible to tell
whether tell AGM contains slot[1] (old 2nd finger) or slot[2] (new
3rd finger).
* When fingers are added one at at time, from 1->2->3, it is possible to
track which slots are contained in the SGM and AGM packets:
1 finger: SGM = slot[0], no AGM
2 fingers: SGM = slot[0], AGM = slot[1]
3 fingers: SGM = slot[0], AGM = slot[2]
* It is also possible to track which slot is contained in the SGM when 1
of 2 fingers is removed. This is because the touchpad sends a special
(0,0,0) AGM packet whenever all fingers are removed except slot[0]:
Last AGM == (0,0,0): SGM contains slot[1]
Else: SGM contains slot[0]
* However, once there are 3 fingers, if exactly 1 finger is removed, it
is impossible to tell which 2 slots are contained in SGM and AGM.
The (SGM,AGM) could be (0,1), (0,2), or (1,2). There is no way to know.
* Similarly, if two fingers are simultaneously removed (3->1), then it
is only possible to know if SGM still contains slot[0].
* Since it is not possible to reliably track which slot is being
reported, we invalidate the tracking_id every time the number of
fingers changes until this ambiguity is resolved when:
a) All fingers are removed.
b) 4 or 5 fingers are touched, generates an AGM-CONTACT packet.
c) All fingers are removed except slot[0]. In this special case, the
ambiguity is resolved since by the (0,0,0) AGM packet.
Behavior of the driver:
When 2 or more fingers are present on the touchpad, the kernel reports
up to two MT-B slots containing the position data for two of the fingers
reported by the touchpad. If the identity of a finger cannot be tracked
when the number-of-fingers changes, the corresponding MT-B slot will be
invalidated (track_id set to -1), and a new track_id will be assigned in
a subsequent input event report.
The driver always reports the total number of fingers using one of the
EV_KEY/BTN_TOOL_*TAP events. This could differ from the number of valid
MT-B slots for two reasons:
a) There are more than 2 fingers on the pad.
b) During ambiguous number-of-fingers transitions, the correct track_id
for one or both of the slots cannot be determined, so the slots are
invalidated.
Thus, this is a hybrid singletouch/MT-B scheme. Userspace can detect
this behavior by noting that the driver supports more EV_KEY/BTN_TOOL_*TAP
events than its maximum EV_ABS/ABS_MT_SLOT.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:40 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-08-24 06:02:56 +00:00
|
|
|
/* Handle case where mt_state->count = 4, or = 5 */
|
|
|
|
static void synaptics_image_sensor_45f(struct synaptics_data *priv,
|
|
|
|
struct synaptics_mt_state *mt_state)
|
|
|
|
{
|
|
|
|
/* mt_state was updated correctly by AGM-CONTACT packet */
|
|
|
|
priv->mt_state_lost = false;
|
|
|
|
}
|
|
|
|
|
Input: synaptics - add image sensor support
Synaptics makes (at least) two kinds of touchpad sensors:
* Older pads use a profile sensor that could only infer the location
of individual fingers based on the projection of their profiles
onto row and column sensors.
* Newer pads use an image sensor that can track true finger position
using a two-dimensional sensor grid.
Both sensor types support an "Advanced Gesture Mode":
When multiple fingers are detected, the touchpad sends alternating
"Advanced Gesture Mode" (AGM) and "Simple Gesture Mode" (SGM)
packets.
The AGM packets have w=2, and contain reduced resolution finger data
The SGM packets have w={0,1} and contain full resolution finger data
Profile sensors try to report the "upper" (larger y value) finger in
the SGM packet, and the lower (smaller y value) in the AGM packet.
However, due to the nature of the profile sensor, they easily get
confused when fingers cross, and can start reporting the x-coordinate
of one with the y-coordinate of the other. Thus, for profile
sensors, "semi-mt" was created, which reports a "bounding box"
created by pairing min and max coordinates of the two pairs of
reported fingers.
Image sensors can report the actual coordinates of two of the fingers
present. This patch detects if the touchpad is an image sensor and
reports finger data using the MT-B protocol.
NOTE: This patch only adds partial support for 2-finger gestures.
The proper interpretation of the slot contents when more than
two fingers are present is left to later patches. Also,
handling of 'number of fingers' transitions is incomplete.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:25 +00:00
|
|
|
static void synaptics_image_sensor_process(struct psmouse *psmouse,
|
|
|
|
struct synaptics_hw_state *sgm)
|
|
|
|
{
|
Input: synaptics - process finger (<=3) transitions
Synaptics image sensor touchpads track 5 fingers, but only report 2.
This patch attempts to deal with some idiosyncrasies of these touchpads:
* When there are 3 or more fingers, only two are reported.
* The touchpad tracks the 5 fingers in slot[0] through slot[4].
* It always reports the lowest and highest valid slots in SGM and AGM
packets, respectively.
* The number of fingers is only reported in the SGM packet. However,
the number of fingers can change either before or after an AGM
packet.
* Thus, if an SGM reports a different number of fingers than the last
SGM, it is impossible to tell whether the intervening AGM corresponds
to the old number of fingers or the new number of fingers.
* For example, when going from 2->3 fingers, it is not possible to tell
whether tell AGM contains slot[1] (old 2nd finger) or slot[2] (new
3rd finger).
* When fingers are added one at at time, from 1->2->3, it is possible to
track which slots are contained in the SGM and AGM packets:
1 finger: SGM = slot[0], no AGM
2 fingers: SGM = slot[0], AGM = slot[1]
3 fingers: SGM = slot[0], AGM = slot[2]
* It is also possible to track which slot is contained in the SGM when 1
of 2 fingers is removed. This is because the touchpad sends a special
(0,0,0) AGM packet whenever all fingers are removed except slot[0]:
Last AGM == (0,0,0): SGM contains slot[1]
Else: SGM contains slot[0]
* However, once there are 3 fingers, if exactly 1 finger is removed, it
is impossible to tell which 2 slots are contained in SGM and AGM.
The (SGM,AGM) could be (0,1), (0,2), or (1,2). There is no way to know.
* Similarly, if two fingers are simultaneously removed (3->1), then it
is only possible to know if SGM still contains slot[0].
* Since it is not possible to reliably track which slot is being
reported, we invalidate the tracking_id every time the number of
fingers changes until this ambiguity is resolved when:
a) All fingers are removed.
b) 4 or 5 fingers are touched, generates an AGM-CONTACT packet.
c) All fingers are removed except slot[0]. In this special case, the
ambiguity is resolved since by the (0,0,0) AGM packet.
Behavior of the driver:
When 2 or more fingers are present on the touchpad, the kernel reports
up to two MT-B slots containing the position data for two of the fingers
reported by the touchpad. If the identity of a finger cannot be tracked
when the number-of-fingers changes, the corresponding MT-B slot will be
invalidated (track_id set to -1), and a new track_id will be assigned in
a subsequent input event report.
The driver always reports the total number of fingers using one of the
EV_KEY/BTN_TOOL_*TAP events. This could differ from the number of valid
MT-B slots for two reasons:
a) There are more than 2 fingers on the pad.
b) During ambiguous number-of-fingers transitions, the correct track_id
for one or both of the slots cannot be determined, so the slots are
invalidated.
Thus, this is a hybrid singletouch/MT-B scheme. Userspace can detect
this behavior by noting that the driver supports more EV_KEY/BTN_TOOL_*TAP
events than its maximum EV_ABS/ABS_MT_SLOT.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:40 +00:00
|
|
|
struct synaptics_data *priv = psmouse->private;
|
|
|
|
struct synaptics_hw_state *agm = &priv->agm;
|
|
|
|
struct synaptics_mt_state mt_state;
|
Input: synaptics - add image sensor support
Synaptics makes (at least) two kinds of touchpad sensors:
* Older pads use a profile sensor that could only infer the location
of individual fingers based on the projection of their profiles
onto row and column sensors.
* Newer pads use an image sensor that can track true finger position
using a two-dimensional sensor grid.
Both sensor types support an "Advanced Gesture Mode":
When multiple fingers are detected, the touchpad sends alternating
"Advanced Gesture Mode" (AGM) and "Simple Gesture Mode" (SGM)
packets.
The AGM packets have w=2, and contain reduced resolution finger data
The SGM packets have w={0,1} and contain full resolution finger data
Profile sensors try to report the "upper" (larger y value) finger in
the SGM packet, and the lower (smaller y value) in the AGM packet.
However, due to the nature of the profile sensor, they easily get
confused when fingers cross, and can start reporting the x-coordinate
of one with the y-coordinate of the other. Thus, for profile
sensors, "semi-mt" was created, which reports a "bounding box"
created by pairing min and max coordinates of the two pairs of
reported fingers.
Image sensors can report the actual coordinates of two of the fingers
present. This patch detects if the touchpad is an image sensor and
reports finger data using the MT-B protocol.
NOTE: This patch only adds partial support for 2-finger gestures.
The proper interpretation of the slot contents when more than
two fingers are present is left to later patches. Also,
handling of 'number of fingers' transitions is incomplete.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:25 +00:00
|
|
|
|
Input: synaptics - process finger (<=3) transitions
Synaptics image sensor touchpads track 5 fingers, but only report 2.
This patch attempts to deal with some idiosyncrasies of these touchpads:
* When there are 3 or more fingers, only two are reported.
* The touchpad tracks the 5 fingers in slot[0] through slot[4].
* It always reports the lowest and highest valid slots in SGM and AGM
packets, respectively.
* The number of fingers is only reported in the SGM packet. However,
the number of fingers can change either before or after an AGM
packet.
* Thus, if an SGM reports a different number of fingers than the last
SGM, it is impossible to tell whether the intervening AGM corresponds
to the old number of fingers or the new number of fingers.
* For example, when going from 2->3 fingers, it is not possible to tell
whether tell AGM contains slot[1] (old 2nd finger) or slot[2] (new
3rd finger).
* When fingers are added one at at time, from 1->2->3, it is possible to
track which slots are contained in the SGM and AGM packets:
1 finger: SGM = slot[0], no AGM
2 fingers: SGM = slot[0], AGM = slot[1]
3 fingers: SGM = slot[0], AGM = slot[2]
* It is also possible to track which slot is contained in the SGM when 1
of 2 fingers is removed. This is because the touchpad sends a special
(0,0,0) AGM packet whenever all fingers are removed except slot[0]:
Last AGM == (0,0,0): SGM contains slot[1]
Else: SGM contains slot[0]
* However, once there are 3 fingers, if exactly 1 finger is removed, it
is impossible to tell which 2 slots are contained in SGM and AGM.
The (SGM,AGM) could be (0,1), (0,2), or (1,2). There is no way to know.
* Similarly, if two fingers are simultaneously removed (3->1), then it
is only possible to know if SGM still contains slot[0].
* Since it is not possible to reliably track which slot is being
reported, we invalidate the tracking_id every time the number of
fingers changes until this ambiguity is resolved when:
a) All fingers are removed.
b) 4 or 5 fingers are touched, generates an AGM-CONTACT packet.
c) All fingers are removed except slot[0]. In this special case, the
ambiguity is resolved since by the (0,0,0) AGM packet.
Behavior of the driver:
When 2 or more fingers are present on the touchpad, the kernel reports
up to two MT-B slots containing the position data for two of the fingers
reported by the touchpad. If the identity of a finger cannot be tracked
when the number-of-fingers changes, the corresponding MT-B slot will be
invalidated (track_id set to -1), and a new track_id will be assigned in
a subsequent input event report.
The driver always reports the total number of fingers using one of the
EV_KEY/BTN_TOOL_*TAP events. This could differ from the number of valid
MT-B slots for two reasons:
a) There are more than 2 fingers on the pad.
b) During ambiguous number-of-fingers transitions, the correct track_id
for one or both of the slots cannot be determined, so the slots are
invalidated.
Thus, this is a hybrid singletouch/MT-B scheme. Userspace can detect
this behavior by noting that the driver supports more EV_KEY/BTN_TOOL_*TAP
events than its maximum EV_ABS/ABS_MT_SLOT.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:40 +00:00
|
|
|
/* Initialize using current mt_state (as updated by last agm) */
|
|
|
|
mt_state = agm->mt_state;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Update mt_state using the new finger count and current mt_state.
|
|
|
|
*/
|
Input: synaptics - add image sensor support
Synaptics makes (at least) two kinds of touchpad sensors:
* Older pads use a profile sensor that could only infer the location
of individual fingers based on the projection of their profiles
onto row and column sensors.
* Newer pads use an image sensor that can track true finger position
using a two-dimensional sensor grid.
Both sensor types support an "Advanced Gesture Mode":
When multiple fingers are detected, the touchpad sends alternating
"Advanced Gesture Mode" (AGM) and "Simple Gesture Mode" (SGM)
packets.
The AGM packets have w=2, and contain reduced resolution finger data
The SGM packets have w={0,1} and contain full resolution finger data
Profile sensors try to report the "upper" (larger y value) finger in
the SGM packet, and the lower (smaller y value) in the AGM packet.
However, due to the nature of the profile sensor, they easily get
confused when fingers cross, and can start reporting the x-coordinate
of one with the y-coordinate of the other. Thus, for profile
sensors, "semi-mt" was created, which reports a "bounding box"
created by pairing min and max coordinates of the two pairs of
reported fingers.
Image sensors can report the actual coordinates of two of the fingers
present. This patch detects if the touchpad is an image sensor and
reports finger data using the MT-B protocol.
NOTE: This patch only adds partial support for 2-finger gestures.
The proper interpretation of the slot contents when more than
two fingers are present is left to later patches. Also,
handling of 'number of fingers' transitions is incomplete.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:25 +00:00
|
|
|
if (sgm->z == 0)
|
Input: synaptics - process finger (<=3) transitions
Synaptics image sensor touchpads track 5 fingers, but only report 2.
This patch attempts to deal with some idiosyncrasies of these touchpads:
* When there are 3 or more fingers, only two are reported.
* The touchpad tracks the 5 fingers in slot[0] through slot[4].
* It always reports the lowest and highest valid slots in SGM and AGM
packets, respectively.
* The number of fingers is only reported in the SGM packet. However,
the number of fingers can change either before or after an AGM
packet.
* Thus, if an SGM reports a different number of fingers than the last
SGM, it is impossible to tell whether the intervening AGM corresponds
to the old number of fingers or the new number of fingers.
* For example, when going from 2->3 fingers, it is not possible to tell
whether tell AGM contains slot[1] (old 2nd finger) or slot[2] (new
3rd finger).
* When fingers are added one at at time, from 1->2->3, it is possible to
track which slots are contained in the SGM and AGM packets:
1 finger: SGM = slot[0], no AGM
2 fingers: SGM = slot[0], AGM = slot[1]
3 fingers: SGM = slot[0], AGM = slot[2]
* It is also possible to track which slot is contained in the SGM when 1
of 2 fingers is removed. This is because the touchpad sends a special
(0,0,0) AGM packet whenever all fingers are removed except slot[0]:
Last AGM == (0,0,0): SGM contains slot[1]
Else: SGM contains slot[0]
* However, once there are 3 fingers, if exactly 1 finger is removed, it
is impossible to tell which 2 slots are contained in SGM and AGM.
The (SGM,AGM) could be (0,1), (0,2), or (1,2). There is no way to know.
* Similarly, if two fingers are simultaneously removed (3->1), then it
is only possible to know if SGM still contains slot[0].
* Since it is not possible to reliably track which slot is being
reported, we invalidate the tracking_id every time the number of
fingers changes until this ambiguity is resolved when:
a) All fingers are removed.
b) 4 or 5 fingers are touched, generates an AGM-CONTACT packet.
c) All fingers are removed except slot[0]. In this special case, the
ambiguity is resolved since by the (0,0,0) AGM packet.
Behavior of the driver:
When 2 or more fingers are present on the touchpad, the kernel reports
up to two MT-B slots containing the position data for two of the fingers
reported by the touchpad. If the identity of a finger cannot be tracked
when the number-of-fingers changes, the corresponding MT-B slot will be
invalidated (track_id set to -1), and a new track_id will be assigned in
a subsequent input event report.
The driver always reports the total number of fingers using one of the
EV_KEY/BTN_TOOL_*TAP events. This could differ from the number of valid
MT-B slots for two reasons:
a) There are more than 2 fingers on the pad.
b) During ambiguous number-of-fingers transitions, the correct track_id
for one or both of the slots cannot be determined, so the slots are
invalidated.
Thus, this is a hybrid singletouch/MT-B scheme. Userspace can detect
this behavior by noting that the driver supports more EV_KEY/BTN_TOOL_*TAP
events than its maximum EV_ABS/ABS_MT_SLOT.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:40 +00:00
|
|
|
synaptics_image_sensor_0f(priv, &mt_state);
|
Input: synaptics - add image sensor support
Synaptics makes (at least) two kinds of touchpad sensors:
* Older pads use a profile sensor that could only infer the location
of individual fingers based on the projection of their profiles
onto row and column sensors.
* Newer pads use an image sensor that can track true finger position
using a two-dimensional sensor grid.
Both sensor types support an "Advanced Gesture Mode":
When multiple fingers are detected, the touchpad sends alternating
"Advanced Gesture Mode" (AGM) and "Simple Gesture Mode" (SGM)
packets.
The AGM packets have w=2, and contain reduced resolution finger data
The SGM packets have w={0,1} and contain full resolution finger data
Profile sensors try to report the "upper" (larger y value) finger in
the SGM packet, and the lower (smaller y value) in the AGM packet.
However, due to the nature of the profile sensor, they easily get
confused when fingers cross, and can start reporting the x-coordinate
of one with the y-coordinate of the other. Thus, for profile
sensors, "semi-mt" was created, which reports a "bounding box"
created by pairing min and max coordinates of the two pairs of
reported fingers.
Image sensors can report the actual coordinates of two of the fingers
present. This patch detects if the touchpad is an image sensor and
reports finger data using the MT-B protocol.
NOTE: This patch only adds partial support for 2-finger gestures.
The proper interpretation of the slot contents when more than
two fingers are present is left to later patches. Also,
handling of 'number of fingers' transitions is incomplete.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:25 +00:00
|
|
|
else if (sgm->w >= 4)
|
Input: synaptics - process finger (<=3) transitions
Synaptics image sensor touchpads track 5 fingers, but only report 2.
This patch attempts to deal with some idiosyncrasies of these touchpads:
* When there are 3 or more fingers, only two are reported.
* The touchpad tracks the 5 fingers in slot[0] through slot[4].
* It always reports the lowest and highest valid slots in SGM and AGM
packets, respectively.
* The number of fingers is only reported in the SGM packet. However,
the number of fingers can change either before or after an AGM
packet.
* Thus, if an SGM reports a different number of fingers than the last
SGM, it is impossible to tell whether the intervening AGM corresponds
to the old number of fingers or the new number of fingers.
* For example, when going from 2->3 fingers, it is not possible to tell
whether tell AGM contains slot[1] (old 2nd finger) or slot[2] (new
3rd finger).
* When fingers are added one at at time, from 1->2->3, it is possible to
track which slots are contained in the SGM and AGM packets:
1 finger: SGM = slot[0], no AGM
2 fingers: SGM = slot[0], AGM = slot[1]
3 fingers: SGM = slot[0], AGM = slot[2]
* It is also possible to track which slot is contained in the SGM when 1
of 2 fingers is removed. This is because the touchpad sends a special
(0,0,0) AGM packet whenever all fingers are removed except slot[0]:
Last AGM == (0,0,0): SGM contains slot[1]
Else: SGM contains slot[0]
* However, once there are 3 fingers, if exactly 1 finger is removed, it
is impossible to tell which 2 slots are contained in SGM and AGM.
The (SGM,AGM) could be (0,1), (0,2), or (1,2). There is no way to know.
* Similarly, if two fingers are simultaneously removed (3->1), then it
is only possible to know if SGM still contains slot[0].
* Since it is not possible to reliably track which slot is being
reported, we invalidate the tracking_id every time the number of
fingers changes until this ambiguity is resolved when:
a) All fingers are removed.
b) 4 or 5 fingers are touched, generates an AGM-CONTACT packet.
c) All fingers are removed except slot[0]. In this special case, the
ambiguity is resolved since by the (0,0,0) AGM packet.
Behavior of the driver:
When 2 or more fingers are present on the touchpad, the kernel reports
up to two MT-B slots containing the position data for two of the fingers
reported by the touchpad. If the identity of a finger cannot be tracked
when the number-of-fingers changes, the corresponding MT-B slot will be
invalidated (track_id set to -1), and a new track_id will be assigned in
a subsequent input event report.
The driver always reports the total number of fingers using one of the
EV_KEY/BTN_TOOL_*TAP events. This could differ from the number of valid
MT-B slots for two reasons:
a) There are more than 2 fingers on the pad.
b) During ambiguous number-of-fingers transitions, the correct track_id
for one or both of the slots cannot be determined, so the slots are
invalidated.
Thus, this is a hybrid singletouch/MT-B scheme. Userspace can detect
this behavior by noting that the driver supports more EV_KEY/BTN_TOOL_*TAP
events than its maximum EV_ABS/ABS_MT_SLOT.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:40 +00:00
|
|
|
synaptics_image_sensor_1f(priv, &mt_state);
|
Input: synaptics - add image sensor support
Synaptics makes (at least) two kinds of touchpad sensors:
* Older pads use a profile sensor that could only infer the location
of individual fingers based on the projection of their profiles
onto row and column sensors.
* Newer pads use an image sensor that can track true finger position
using a two-dimensional sensor grid.
Both sensor types support an "Advanced Gesture Mode":
When multiple fingers are detected, the touchpad sends alternating
"Advanced Gesture Mode" (AGM) and "Simple Gesture Mode" (SGM)
packets.
The AGM packets have w=2, and contain reduced resolution finger data
The SGM packets have w={0,1} and contain full resolution finger data
Profile sensors try to report the "upper" (larger y value) finger in
the SGM packet, and the lower (smaller y value) in the AGM packet.
However, due to the nature of the profile sensor, they easily get
confused when fingers cross, and can start reporting the x-coordinate
of one with the y-coordinate of the other. Thus, for profile
sensors, "semi-mt" was created, which reports a "bounding box"
created by pairing min and max coordinates of the two pairs of
reported fingers.
Image sensors can report the actual coordinates of two of the fingers
present. This patch detects if the touchpad is an image sensor and
reports finger data using the MT-B protocol.
NOTE: This patch only adds partial support for 2-finger gestures.
The proper interpretation of the slot contents when more than
two fingers are present is left to later patches. Also,
handling of 'number of fingers' transitions is incomplete.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:25 +00:00
|
|
|
else if (sgm->w == 0)
|
Input: synaptics - process finger (<=3) transitions
Synaptics image sensor touchpads track 5 fingers, but only report 2.
This patch attempts to deal with some idiosyncrasies of these touchpads:
* When there are 3 or more fingers, only two are reported.
* The touchpad tracks the 5 fingers in slot[0] through slot[4].
* It always reports the lowest and highest valid slots in SGM and AGM
packets, respectively.
* The number of fingers is only reported in the SGM packet. However,
the number of fingers can change either before or after an AGM
packet.
* Thus, if an SGM reports a different number of fingers than the last
SGM, it is impossible to tell whether the intervening AGM corresponds
to the old number of fingers or the new number of fingers.
* For example, when going from 2->3 fingers, it is not possible to tell
whether tell AGM contains slot[1] (old 2nd finger) or slot[2] (new
3rd finger).
* When fingers are added one at at time, from 1->2->3, it is possible to
track which slots are contained in the SGM and AGM packets:
1 finger: SGM = slot[0], no AGM
2 fingers: SGM = slot[0], AGM = slot[1]
3 fingers: SGM = slot[0], AGM = slot[2]
* It is also possible to track which slot is contained in the SGM when 1
of 2 fingers is removed. This is because the touchpad sends a special
(0,0,0) AGM packet whenever all fingers are removed except slot[0]:
Last AGM == (0,0,0): SGM contains slot[1]
Else: SGM contains slot[0]
* However, once there are 3 fingers, if exactly 1 finger is removed, it
is impossible to tell which 2 slots are contained in SGM and AGM.
The (SGM,AGM) could be (0,1), (0,2), or (1,2). There is no way to know.
* Similarly, if two fingers are simultaneously removed (3->1), then it
is only possible to know if SGM still contains slot[0].
* Since it is not possible to reliably track which slot is being
reported, we invalidate the tracking_id every time the number of
fingers changes until this ambiguity is resolved when:
a) All fingers are removed.
b) 4 or 5 fingers are touched, generates an AGM-CONTACT packet.
c) All fingers are removed except slot[0]. In this special case, the
ambiguity is resolved since by the (0,0,0) AGM packet.
Behavior of the driver:
When 2 or more fingers are present on the touchpad, the kernel reports
up to two MT-B slots containing the position data for two of the fingers
reported by the touchpad. If the identity of a finger cannot be tracked
when the number-of-fingers changes, the corresponding MT-B slot will be
invalidated (track_id set to -1), and a new track_id will be assigned in
a subsequent input event report.
The driver always reports the total number of fingers using one of the
EV_KEY/BTN_TOOL_*TAP events. This could differ from the number of valid
MT-B slots for two reasons:
a) There are more than 2 fingers on the pad.
b) During ambiguous number-of-fingers transitions, the correct track_id
for one or both of the slots cannot be determined, so the slots are
invalidated.
Thus, this is a hybrid singletouch/MT-B scheme. Userspace can detect
this behavior by noting that the driver supports more EV_KEY/BTN_TOOL_*TAP
events than its maximum EV_ABS/ABS_MT_SLOT.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:40 +00:00
|
|
|
synaptics_image_sensor_2f(priv, &mt_state);
|
2011-08-24 06:02:56 +00:00
|
|
|
else if (sgm->w == 1 && mt_state.count <= 3)
|
Input: synaptics - process finger (<=3) transitions
Synaptics image sensor touchpads track 5 fingers, but only report 2.
This patch attempts to deal with some idiosyncrasies of these touchpads:
* When there are 3 or more fingers, only two are reported.
* The touchpad tracks the 5 fingers in slot[0] through slot[4].
* It always reports the lowest and highest valid slots in SGM and AGM
packets, respectively.
* The number of fingers is only reported in the SGM packet. However,
the number of fingers can change either before or after an AGM
packet.
* Thus, if an SGM reports a different number of fingers than the last
SGM, it is impossible to tell whether the intervening AGM corresponds
to the old number of fingers or the new number of fingers.
* For example, when going from 2->3 fingers, it is not possible to tell
whether tell AGM contains slot[1] (old 2nd finger) or slot[2] (new
3rd finger).
* When fingers are added one at at time, from 1->2->3, it is possible to
track which slots are contained in the SGM and AGM packets:
1 finger: SGM = slot[0], no AGM
2 fingers: SGM = slot[0], AGM = slot[1]
3 fingers: SGM = slot[0], AGM = slot[2]
* It is also possible to track which slot is contained in the SGM when 1
of 2 fingers is removed. This is because the touchpad sends a special
(0,0,0) AGM packet whenever all fingers are removed except slot[0]:
Last AGM == (0,0,0): SGM contains slot[1]
Else: SGM contains slot[0]
* However, once there are 3 fingers, if exactly 1 finger is removed, it
is impossible to tell which 2 slots are contained in SGM and AGM.
The (SGM,AGM) could be (0,1), (0,2), or (1,2). There is no way to know.
* Similarly, if two fingers are simultaneously removed (3->1), then it
is only possible to know if SGM still contains slot[0].
* Since it is not possible to reliably track which slot is being
reported, we invalidate the tracking_id every time the number of
fingers changes until this ambiguity is resolved when:
a) All fingers are removed.
b) 4 or 5 fingers are touched, generates an AGM-CONTACT packet.
c) All fingers are removed except slot[0]. In this special case, the
ambiguity is resolved since by the (0,0,0) AGM packet.
Behavior of the driver:
When 2 or more fingers are present on the touchpad, the kernel reports
up to two MT-B slots containing the position data for two of the fingers
reported by the touchpad. If the identity of a finger cannot be tracked
when the number-of-fingers changes, the corresponding MT-B slot will be
invalidated (track_id set to -1), and a new track_id will be assigned in
a subsequent input event report.
The driver always reports the total number of fingers using one of the
EV_KEY/BTN_TOOL_*TAP events. This could differ from the number of valid
MT-B slots for two reasons:
a) There are more than 2 fingers on the pad.
b) During ambiguous number-of-fingers transitions, the correct track_id
for one or both of the slots cannot be determined, so the slots are
invalidated.
Thus, this is a hybrid singletouch/MT-B scheme. Userspace can detect
this behavior by noting that the driver supports more EV_KEY/BTN_TOOL_*TAP
events than its maximum EV_ABS/ABS_MT_SLOT.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:40 +00:00
|
|
|
synaptics_image_sensor_3f(priv, &mt_state);
|
2011-08-24 06:02:56 +00:00
|
|
|
else
|
|
|
|
synaptics_image_sensor_45f(priv, &mt_state);
|
Input: synaptics - add image sensor support
Synaptics makes (at least) two kinds of touchpad sensors:
* Older pads use a profile sensor that could only infer the location
of individual fingers based on the projection of their profiles
onto row and column sensors.
* Newer pads use an image sensor that can track true finger position
using a two-dimensional sensor grid.
Both sensor types support an "Advanced Gesture Mode":
When multiple fingers are detected, the touchpad sends alternating
"Advanced Gesture Mode" (AGM) and "Simple Gesture Mode" (SGM)
packets.
The AGM packets have w=2, and contain reduced resolution finger data
The SGM packets have w={0,1} and contain full resolution finger data
Profile sensors try to report the "upper" (larger y value) finger in
the SGM packet, and the lower (smaller y value) in the AGM packet.
However, due to the nature of the profile sensor, they easily get
confused when fingers cross, and can start reporting the x-coordinate
of one with the y-coordinate of the other. Thus, for profile
sensors, "semi-mt" was created, which reports a "bounding box"
created by pairing min and max coordinates of the two pairs of
reported fingers.
Image sensors can report the actual coordinates of two of the fingers
present. This patch detects if the touchpad is an image sensor and
reports finger data using the MT-B protocol.
NOTE: This patch only adds partial support for 2-finger gestures.
The proper interpretation of the slot contents when more than
two fingers are present is left to later patches. Also,
handling of 'number of fingers' transitions is incomplete.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:25 +00:00
|
|
|
|
|
|
|
/* Send resulting input events to user space */
|
Input: synaptics - process finger (<=3) transitions
Synaptics image sensor touchpads track 5 fingers, but only report 2.
This patch attempts to deal with some idiosyncrasies of these touchpads:
* When there are 3 or more fingers, only two are reported.
* The touchpad tracks the 5 fingers in slot[0] through slot[4].
* It always reports the lowest and highest valid slots in SGM and AGM
packets, respectively.
* The number of fingers is only reported in the SGM packet. However,
the number of fingers can change either before or after an AGM
packet.
* Thus, if an SGM reports a different number of fingers than the last
SGM, it is impossible to tell whether the intervening AGM corresponds
to the old number of fingers or the new number of fingers.
* For example, when going from 2->3 fingers, it is not possible to tell
whether tell AGM contains slot[1] (old 2nd finger) or slot[2] (new
3rd finger).
* When fingers are added one at at time, from 1->2->3, it is possible to
track which slots are contained in the SGM and AGM packets:
1 finger: SGM = slot[0], no AGM
2 fingers: SGM = slot[0], AGM = slot[1]
3 fingers: SGM = slot[0], AGM = slot[2]
* It is also possible to track which slot is contained in the SGM when 1
of 2 fingers is removed. This is because the touchpad sends a special
(0,0,0) AGM packet whenever all fingers are removed except slot[0]:
Last AGM == (0,0,0): SGM contains slot[1]
Else: SGM contains slot[0]
* However, once there are 3 fingers, if exactly 1 finger is removed, it
is impossible to tell which 2 slots are contained in SGM and AGM.
The (SGM,AGM) could be (0,1), (0,2), or (1,2). There is no way to know.
* Similarly, if two fingers are simultaneously removed (3->1), then it
is only possible to know if SGM still contains slot[0].
* Since it is not possible to reliably track which slot is being
reported, we invalidate the tracking_id every time the number of
fingers changes until this ambiguity is resolved when:
a) All fingers are removed.
b) 4 or 5 fingers are touched, generates an AGM-CONTACT packet.
c) All fingers are removed except slot[0]. In this special case, the
ambiguity is resolved since by the (0,0,0) AGM packet.
Behavior of the driver:
When 2 or more fingers are present on the touchpad, the kernel reports
up to two MT-B slots containing the position data for two of the fingers
reported by the touchpad. If the identity of a finger cannot be tracked
when the number-of-fingers changes, the corresponding MT-B slot will be
invalidated (track_id set to -1), and a new track_id will be assigned in
a subsequent input event report.
The driver always reports the total number of fingers using one of the
EV_KEY/BTN_TOOL_*TAP events. This could differ from the number of valid
MT-B slots for two reasons:
a) There are more than 2 fingers on the pad.
b) During ambiguous number-of-fingers transitions, the correct track_id
for one or both of the slots cannot be determined, so the slots are
invalidated.
Thus, this is a hybrid singletouch/MT-B scheme. Userspace can detect
this behavior by noting that the driver supports more EV_KEY/BTN_TOOL_*TAP
events than its maximum EV_ABS/ABS_MT_SLOT.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:40 +00:00
|
|
|
synaptics_report_mt_data(psmouse, &mt_state, sgm);
|
|
|
|
|
|
|
|
/* Store updated mt_state */
|
|
|
|
priv->mt_state = agm->mt_state = mt_state;
|
|
|
|
priv->agm_pending = false;
|
Input: synaptics - add image sensor support
Synaptics makes (at least) two kinds of touchpad sensors:
* Older pads use a profile sensor that could only infer the location
of individual fingers based on the projection of their profiles
onto row and column sensors.
* Newer pads use an image sensor that can track true finger position
using a two-dimensional sensor grid.
Both sensor types support an "Advanced Gesture Mode":
When multiple fingers are detected, the touchpad sends alternating
"Advanced Gesture Mode" (AGM) and "Simple Gesture Mode" (SGM)
packets.
The AGM packets have w=2, and contain reduced resolution finger data
The SGM packets have w={0,1} and contain full resolution finger data
Profile sensors try to report the "upper" (larger y value) finger in
the SGM packet, and the lower (smaller y value) in the AGM packet.
However, due to the nature of the profile sensor, they easily get
confused when fingers cross, and can start reporting the x-coordinate
of one with the y-coordinate of the other. Thus, for profile
sensors, "semi-mt" was created, which reports a "bounding box"
created by pairing min and max coordinates of the two pairs of
reported fingers.
Image sensors can report the actual coordinates of two of the fingers
present. This patch detects if the touchpad is an image sensor and
reports finger data using the MT-B protocol.
NOTE: This patch only adds partial support for 2-finger gestures.
The proper interpretation of the slot contents when more than
two fingers are present is left to later patches. Also,
handling of 'number of fingers' transitions is incomplete.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:25 +00:00
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* called for each full received packet from the touchpad
|
|
|
|
*/
|
|
|
|
static void synaptics_process_packet(struct psmouse *psmouse)
|
|
|
|
{
|
2005-09-15 07:01:44 +00:00
|
|
|
struct input_dev *dev = psmouse->dev;
|
2005-04-16 22:20:36 +00:00
|
|
|
struct synaptics_data *priv = psmouse->private;
|
|
|
|
struct synaptics_hw_state hw;
|
|
|
|
int num_fingers;
|
|
|
|
int finger_width;
|
|
|
|
|
2010-12-21 17:11:25 +00:00
|
|
|
if (synaptics_parse_hw_state(psmouse->packet, priv, &hw))
|
|
|
|
return;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
Input: synaptics - add image sensor support
Synaptics makes (at least) two kinds of touchpad sensors:
* Older pads use a profile sensor that could only infer the location
of individual fingers based on the projection of their profiles
onto row and column sensors.
* Newer pads use an image sensor that can track true finger position
using a two-dimensional sensor grid.
Both sensor types support an "Advanced Gesture Mode":
When multiple fingers are detected, the touchpad sends alternating
"Advanced Gesture Mode" (AGM) and "Simple Gesture Mode" (SGM)
packets.
The AGM packets have w=2, and contain reduced resolution finger data
The SGM packets have w={0,1} and contain full resolution finger data
Profile sensors try to report the "upper" (larger y value) finger in
the SGM packet, and the lower (smaller y value) in the AGM packet.
However, due to the nature of the profile sensor, they easily get
confused when fingers cross, and can start reporting the x-coordinate
of one with the y-coordinate of the other. Thus, for profile
sensors, "semi-mt" was created, which reports a "bounding box"
created by pairing min and max coordinates of the two pairs of
reported fingers.
Image sensors can report the actual coordinates of two of the fingers
present. This patch detects if the touchpad is an image sensor and
reports finger data using the MT-B protocol.
NOTE: This patch only adds partial support for 2-finger gestures.
The proper interpretation of the slot contents when more than
two fingers are present is left to later patches. Also,
handling of 'number of fingers' transitions is incomplete.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:25 +00:00
|
|
|
if (SYN_CAP_IMAGE_SENSOR(priv->ext_cap_0c)) {
|
|
|
|
synaptics_image_sensor_process(psmouse, &hw);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
if (hw.scroll) {
|
|
|
|
priv->scroll += hw.scroll;
|
|
|
|
|
|
|
|
while (priv->scroll >= 4) {
|
|
|
|
input_report_key(dev, BTN_BACK, !hw.down);
|
|
|
|
input_sync(dev);
|
|
|
|
input_report_key(dev, BTN_BACK, hw.down);
|
|
|
|
input_sync(dev);
|
|
|
|
priv->scroll -= 4;
|
|
|
|
}
|
|
|
|
while (priv->scroll <= -4) {
|
|
|
|
input_report_key(dev, BTN_FORWARD, !hw.up);
|
|
|
|
input_sync(dev);
|
|
|
|
input_report_key(dev, BTN_FORWARD, hw.up);
|
|
|
|
input_sync(dev);
|
|
|
|
priv->scroll += 4;
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2010-12-18 14:42:30 +00:00
|
|
|
if (hw.z > 0 && hw.x > 1) {
|
2005-04-16 22:20:36 +00:00
|
|
|
num_fingers = 1;
|
|
|
|
finger_width = 5;
|
|
|
|
if (SYN_CAP_EXTENDED(priv->capabilities)) {
|
|
|
|
switch (hw.w) {
|
|
|
|
case 0 ... 1:
|
|
|
|
if (SYN_CAP_MULTIFINGER(priv->capabilities))
|
|
|
|
num_fingers = hw.w + 2;
|
|
|
|
break;
|
|
|
|
case 2:
|
|
|
|
if (SYN_MODEL_PEN(priv->model_id))
|
|
|
|
; /* Nothing, treat a pen as a single finger */
|
|
|
|
break;
|
|
|
|
case 4 ... 15:
|
|
|
|
if (SYN_CAP_PALMDETECT(priv->capabilities))
|
|
|
|
finger_width = hw.w;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
num_fingers = 0;
|
|
|
|
finger_width = 0;
|
|
|
|
}
|
|
|
|
|
2010-12-21 17:11:25 +00:00
|
|
|
if (SYN_CAP_ADV_GESTURE(priv->ext_cap_0c))
|
2011-08-24 06:00:33 +00:00
|
|
|
synaptics_report_semi_mt_data(dev, &hw, &priv->agm,
|
|
|
|
num_fingers);
|
2010-12-21 17:11:25 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/* Post events
|
|
|
|
* BTN_TOUCH has to be first as mousedev relies on it when doing
|
|
|
|
* absolute -> relative conversion
|
|
|
|
*/
|
|
|
|
if (hw.z > 30) input_report_key(dev, BTN_TOUCH, 1);
|
|
|
|
if (hw.z < 25) input_report_key(dev, BTN_TOUCH, 0);
|
|
|
|
|
2010-12-18 14:42:30 +00:00
|
|
|
if (num_fingers > 0) {
|
2005-04-16 22:20:36 +00:00
|
|
|
input_report_abs(dev, ABS_X, hw.x);
|
2011-08-24 06:00:24 +00:00
|
|
|
input_report_abs(dev, ABS_Y, synaptics_invert_y(hw.y));
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
input_report_abs(dev, ABS_PRESSURE, hw.z);
|
|
|
|
|
2010-07-19 16:06:15 +00:00
|
|
|
if (SYN_CAP_PALMDETECT(priv->capabilities))
|
|
|
|
input_report_abs(dev, ABS_TOOL_WIDTH, finger_width);
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
input_report_key(dev, BTN_TOOL_FINGER, num_fingers == 1);
|
2008-11-20 20:24:42 +00:00
|
|
|
if (SYN_CAP_MULTIFINGER(priv->capabilities)) {
|
|
|
|
input_report_key(dev, BTN_TOOL_DOUBLETAP, num_fingers == 2);
|
|
|
|
input_report_key(dev, BTN_TOOL_TRIPLETAP, num_fingers == 3);
|
|
|
|
}
|
|
|
|
|
Input: synaptics - add image sensor support
Synaptics makes (at least) two kinds of touchpad sensors:
* Older pads use a profile sensor that could only infer the location
of individual fingers based on the projection of their profiles
onto row and column sensors.
* Newer pads use an image sensor that can track true finger position
using a two-dimensional sensor grid.
Both sensor types support an "Advanced Gesture Mode":
When multiple fingers are detected, the touchpad sends alternating
"Advanced Gesture Mode" (AGM) and "Simple Gesture Mode" (SGM)
packets.
The AGM packets have w=2, and contain reduced resolution finger data
The SGM packets have w={0,1} and contain full resolution finger data
Profile sensors try to report the "upper" (larger y value) finger in
the SGM packet, and the lower (smaller y value) in the AGM packet.
However, due to the nature of the profile sensor, they easily get
confused when fingers cross, and can start reporting the x-coordinate
of one with the y-coordinate of the other. Thus, for profile
sensors, "semi-mt" was created, which reports a "bounding box"
created by pairing min and max coordinates of the two pairs of
reported fingers.
Image sensors can report the actual coordinates of two of the fingers
present. This patch detects if the touchpad is an image sensor and
reports finger data using the MT-B protocol.
NOTE: This patch only adds partial support for 2-finger gestures.
The proper interpretation of the slot contents when more than
two fingers are present is left to later patches. Also,
handling of 'number of fingers' transitions is incomplete.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:25 +00:00
|
|
|
synaptics_report_buttons(psmouse, &hw);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
input_sync(dev);
|
|
|
|
}
|
|
|
|
|
2011-10-11 01:27:03 +00:00
|
|
|
static int synaptics_validate_byte(struct psmouse *psmouse,
|
|
|
|
int idx, unsigned char pkt_type)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2006-09-11 01:54:39 +00:00
|
|
|
static const unsigned char newabs_mask[] = { 0xC8, 0x00, 0x00, 0xC8, 0x00 };
|
|
|
|
static const unsigned char newabs_rel_mask[] = { 0xC0, 0x00, 0x00, 0xC0, 0x00 };
|
|
|
|
static const unsigned char newabs_rslt[] = { 0x80, 0x00, 0x00, 0xC0, 0x00 };
|
|
|
|
static const unsigned char oldabs_mask[] = { 0xC0, 0x60, 0x00, 0xC0, 0x60 };
|
|
|
|
static const unsigned char oldabs_rslt[] = { 0xC0, 0x00, 0x00, 0x80, 0x00 };
|
2011-10-11 01:27:03 +00:00
|
|
|
const char *packet = psmouse->packet;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
if (idx < 0 || idx > 4)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
switch (pkt_type) {
|
|
|
|
|
2010-05-19 17:39:17 +00:00
|
|
|
case SYN_NEWABS:
|
|
|
|
case SYN_NEWABS_RELAXED:
|
|
|
|
return (packet[idx] & newabs_rel_mask[idx]) == newabs_rslt[idx];
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2010-05-19 17:39:17 +00:00
|
|
|
case SYN_NEWABS_STRICT:
|
|
|
|
return (packet[idx] & newabs_mask[idx]) == newabs_rslt[idx];
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2010-05-19 17:39:17 +00:00
|
|
|
case SYN_OLDABS:
|
|
|
|
return (packet[idx] & oldabs_mask[idx]) == oldabs_rslt[idx];
|
|
|
|
|
|
|
|
default:
|
2011-10-11 01:27:03 +00:00
|
|
|
psmouse_err(psmouse, "unknown packet type %d\n", pkt_type);
|
2010-05-19 17:39:17 +00:00
|
|
|
return 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned char synaptics_detect_pkt_type(struct psmouse *psmouse)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < 5; i++)
|
2011-10-11 01:27:03 +00:00
|
|
|
if (!synaptics_validate_byte(psmouse, i, SYN_NEWABS_STRICT)) {
|
|
|
|
psmouse_info(psmouse, "using relaxed packet validation\n");
|
2005-04-16 22:20:36 +00:00
|
|
|
return SYN_NEWABS_RELAXED;
|
|
|
|
}
|
|
|
|
|
|
|
|
return SYN_NEWABS_STRICT;
|
|
|
|
}
|
|
|
|
|
IRQ: Maintain regs pointer globally rather than passing to IRQ handlers
Maintain a per-CPU global "struct pt_regs *" variable which can be used instead
of passing regs around manually through all ~1800 interrupt handlers in the
Linux kernel.
The regs pointer is used in few places, but it potentially costs both stack
space and code to pass it around. On the FRV arch, removing the regs parameter
from all the genirq function results in a 20% speed up of the IRQ exit path
(ie: from leaving timer_interrupt() to leaving do_IRQ()).
Where appropriate, an arch may override the generic storage facility and do
something different with the variable. On FRV, for instance, the address is
maintained in GR28 at all times inside the kernel as part of general exception
handling.
Having looked over the code, it appears that the parameter may be handed down
through up to twenty or so layers of functions. Consider a USB character
device attached to a USB hub, attached to a USB controller that posts its
interrupts through a cascaded auxiliary interrupt controller. A character
device driver may want to pass regs to the sysrq handler through the input
layer which adds another few layers of parameter passing.
I've build this code with allyesconfig for x86_64 and i386. I've runtested the
main part of the code on FRV and i386, though I can't test most of the drivers.
I've also done partial conversion for powerpc and MIPS - these at least compile
with minimal configurations.
This will affect all archs. Mostly the changes should be relatively easy.
Take do_IRQ(), store the regs pointer at the beginning, saving the old one:
struct pt_regs *old_regs = set_irq_regs(regs);
And put the old one back at the end:
set_irq_regs(old_regs);
Don't pass regs through to generic_handle_irq() or __do_IRQ().
In timer_interrupt(), this sort of change will be necessary:
- update_process_times(user_mode(regs));
- profile_tick(CPU_PROFILING, regs);
+ update_process_times(user_mode(get_irq_regs()));
+ profile_tick(CPU_PROFILING);
I'd like to move update_process_times()'s use of get_irq_regs() into itself,
except that i386, alone of the archs, uses something other than user_mode().
Some notes on the interrupt handling in the drivers:
(*) input_dev() is now gone entirely. The regs pointer is no longer stored in
the input_dev struct.
(*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking. It does
something different depending on whether it's been supplied with a regs
pointer or not.
(*) Various IRQ handler function pointers have been moved to type
irq_handler_t.
Signed-Off-By: David Howells <dhowells@redhat.com>
(cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)
2006-10-05 13:55:46 +00:00
|
|
|
static psmouse_ret_t synaptics_process_byte(struct psmouse *psmouse)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
struct synaptics_data *priv = psmouse->private;
|
|
|
|
|
|
|
|
if (psmouse->pktcnt >= 6) { /* Full packet received */
|
|
|
|
if (unlikely(priv->pkt_type == SYN_NEWABS))
|
|
|
|
priv->pkt_type = synaptics_detect_pkt_type(psmouse);
|
|
|
|
|
2010-10-05 04:46:10 +00:00
|
|
|
if (SYN_CAP_PASS_THROUGH(priv->capabilities) &&
|
|
|
|
synaptics_is_pt_packet(psmouse->packet)) {
|
|
|
|
if (priv->pt_port)
|
|
|
|
synaptics_pass_pt_packet(priv->pt_port, psmouse->packet);
|
2005-04-16 22:20:36 +00:00
|
|
|
} else
|
|
|
|
synaptics_process_packet(psmouse);
|
|
|
|
|
|
|
|
return PSMOUSE_FULL_PACKET;
|
|
|
|
}
|
|
|
|
|
2011-10-11 01:27:03 +00:00
|
|
|
return synaptics_validate_byte(psmouse, psmouse->pktcnt - 1, priv->pkt_type) ?
|
2005-04-16 22:20:36 +00:00
|
|
|
PSMOUSE_GOOD_DATA : PSMOUSE_BAD_DATA;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
* Driver initialization/cleanup functions
|
|
|
|
****************************************************************************/
|
2011-08-24 06:00:41 +00:00
|
|
|
static void set_abs_position_params(struct input_dev *dev,
|
|
|
|
struct synaptics_data *priv, int x_code,
|
|
|
|
int y_code)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2011-08-24 06:00:41 +00:00
|
|
|
int x_min = priv->x_min ?: XMIN_NOMINAL;
|
|
|
|
int x_max = priv->x_max ?: XMAX_NOMINAL;
|
|
|
|
int y_min = priv->y_min ?: YMIN_NOMINAL;
|
|
|
|
int y_max = priv->y_max ?: YMAX_NOMINAL;
|
2011-07-07 05:39:14 +00:00
|
|
|
int fuzz = SYN_CAP_REDUCED_FILTERING(priv->ext_cap_0c) ?
|
|
|
|
SYN_REDUCED_FILTER_FUZZ : 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2011-08-24 06:00:41 +00:00
|
|
|
input_set_abs_params(dev, x_code, x_min, x_max, fuzz, 0);
|
|
|
|
input_set_abs_params(dev, y_code, y_min, y_max, fuzz, 0);
|
|
|
|
input_abs_set_res(dev, x_code, priv->x_res);
|
|
|
|
input_abs_set_res(dev, y_code, priv->y_res);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void set_input_params(struct input_dev *dev, struct synaptics_data *priv)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
Input: synaptics - add support for Relative mode
Currently, the synaptics driver puts the device into Absolute mode.
As explained in the synaptics documentation section 3.2, in this mode,
the device sends a continuous stream of packets at the maximum rate
to the host when the user's fingers are near or on the pad or
pressing buttons, and continues streaming for 1 second afterwards.
These packets are even sent when there is no new information to report,
even when they are duplicates of the previous packet.
For embedded systems this is a bit much - it results in a huge
and uninterrupted stream of interrupts at high rate.
This patch adds support for Relative mode, which can be selected as
a new psmouse protocol. In this mode, the device does not send duplicate
packets and acts like a standard PS/2 mouse. However, synaptics-specific
functionality is still available, such as the ability to set the packet
rate, and rather than disabling gestures and taps at the hardware level
unconditionally, a 'synaptics_disable_gesture' sysfs attribute has
been added to allow control of this functionality.
This solves a long standing OLPC issue: synaptics hardware enables
tap to click by default (even in the default relative mode), but we
have found this to be inappropriate for young children and first
time computer users. Enabling the synaptics driver disables tap-to-click,
but we have previously been unable to use this because it also enables
Absolute mode, which is too "spammy" for our desires and actually
overloads our EC with its continuous stream of packets. Now we can enable
the synaptics driver, disabling tap to click while retaining the less
noisy Relative mode.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-11-08 08:00:35 +00:00
|
|
|
/* Things that apply to both modes */
|
2010-12-16 08:52:23 +00:00
|
|
|
__set_bit(INPUT_PROP_POINTER, dev->propbit);
|
Input: synaptics - add support for Relative mode
Currently, the synaptics driver puts the device into Absolute mode.
As explained in the synaptics documentation section 3.2, in this mode,
the device sends a continuous stream of packets at the maximum rate
to the host when the user's fingers are near or on the pad or
pressing buttons, and continues streaming for 1 second afterwards.
These packets are even sent when there is no new information to report,
even when they are duplicates of the previous packet.
For embedded systems this is a bit much - it results in a huge
and uninterrupted stream of interrupts at high rate.
This patch adds support for Relative mode, which can be selected as
a new psmouse protocol. In this mode, the device does not send duplicate
packets and acts like a standard PS/2 mouse. However, synaptics-specific
functionality is still available, such as the ability to set the packet
rate, and rather than disabling gestures and taps at the hardware level
unconditionally, a 'synaptics_disable_gesture' sysfs attribute has
been added to allow control of this functionality.
This solves a long standing OLPC issue: synaptics hardware enables
tap to click by default (even in the default relative mode), but we
have found this to be inappropriate for young children and first
time computer users. Enabling the synaptics driver disables tap-to-click,
but we have previously been unable to use this because it also enables
Absolute mode, which is too "spammy" for our desires and actually
overloads our EC with its continuous stream of packets. Now we can enable
the synaptics driver, disabling tap to click while retaining the less
noisy Relative mode.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-11-08 08:00:35 +00:00
|
|
|
__set_bit(EV_KEY, dev->evbit);
|
|
|
|
__set_bit(BTN_LEFT, dev->keybit);
|
|
|
|
__set_bit(BTN_RIGHT, dev->keybit);
|
2010-12-16 08:52:23 +00:00
|
|
|
|
Input: synaptics - add support for Relative mode
Currently, the synaptics driver puts the device into Absolute mode.
As explained in the synaptics documentation section 3.2, in this mode,
the device sends a continuous stream of packets at the maximum rate
to the host when the user's fingers are near or on the pad or
pressing buttons, and continues streaming for 1 second afterwards.
These packets are even sent when there is no new information to report,
even when they are duplicates of the previous packet.
For embedded systems this is a bit much - it results in a huge
and uninterrupted stream of interrupts at high rate.
This patch adds support for Relative mode, which can be selected as
a new psmouse protocol. In this mode, the device does not send duplicate
packets and acts like a standard PS/2 mouse. However, synaptics-specific
functionality is still available, such as the ability to set the packet
rate, and rather than disabling gestures and taps at the hardware level
unconditionally, a 'synaptics_disable_gesture' sysfs attribute has
been added to allow control of this functionality.
This solves a long standing OLPC issue: synaptics hardware enables
tap to click by default (even in the default relative mode), but we
have found this to be inappropriate for young children and first
time computer users. Enabling the synaptics driver disables tap-to-click,
but we have previously been unable to use this because it also enables
Absolute mode, which is too "spammy" for our desires and actually
overloads our EC with its continuous stream of packets. Now we can enable
the synaptics driver, disabling tap to click while retaining the less
noisy Relative mode.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-11-08 08:00:35 +00:00
|
|
|
if (SYN_CAP_MIDDLE_BUTTON(priv->capabilities))
|
|
|
|
__set_bit(BTN_MIDDLE, dev->keybit);
|
|
|
|
|
|
|
|
if (!priv->absolute_mode) {
|
|
|
|
/* Relative mode */
|
|
|
|
__set_bit(EV_REL, dev->evbit);
|
|
|
|
__set_bit(REL_X, dev->relbit);
|
|
|
|
__set_bit(REL_Y, dev->relbit);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Absolute mode */
|
2009-09-10 02:13:20 +00:00
|
|
|
__set_bit(EV_ABS, dev->evbit);
|
2011-08-24 06:00:41 +00:00
|
|
|
set_abs_position_params(dev, priv, ABS_X, ABS_Y);
|
2005-04-16 22:20:36 +00:00
|
|
|
input_set_abs_params(dev, ABS_PRESSURE, 0, 255, 0, 0);
|
2010-07-19 16:06:15 +00:00
|
|
|
|
Input: synaptics - add image sensor support
Synaptics makes (at least) two kinds of touchpad sensors:
* Older pads use a profile sensor that could only infer the location
of individual fingers based on the projection of their profiles
onto row and column sensors.
* Newer pads use an image sensor that can track true finger position
using a two-dimensional sensor grid.
Both sensor types support an "Advanced Gesture Mode":
When multiple fingers are detected, the touchpad sends alternating
"Advanced Gesture Mode" (AGM) and "Simple Gesture Mode" (SGM)
packets.
The AGM packets have w=2, and contain reduced resolution finger data
The SGM packets have w={0,1} and contain full resolution finger data
Profile sensors try to report the "upper" (larger y value) finger in
the SGM packet, and the lower (smaller y value) in the AGM packet.
However, due to the nature of the profile sensor, they easily get
confused when fingers cross, and can start reporting the x-coordinate
of one with the y-coordinate of the other. Thus, for profile
sensors, "semi-mt" was created, which reports a "bounding box"
created by pairing min and max coordinates of the two pairs of
reported fingers.
Image sensors can report the actual coordinates of two of the fingers
present. This patch detects if the touchpad is an image sensor and
reports finger data using the MT-B protocol.
NOTE: This patch only adds partial support for 2-finger gestures.
The proper interpretation of the slot contents when more than
two fingers are present is left to later patches. Also,
handling of 'number of fingers' transitions is incomplete.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:25 +00:00
|
|
|
if (SYN_CAP_IMAGE_SENSOR(priv->ext_cap_0c)) {
|
|
|
|
set_abs_position_params(dev, priv, ABS_MT_POSITION_X,
|
|
|
|
ABS_MT_POSITION_Y);
|
|
|
|
/* Image sensors can report per-contact pressure */
|
|
|
|
input_set_abs_params(dev, ABS_MT_PRESSURE, 0, 255, 0, 0);
|
2013-02-16 01:04:03 +00:00
|
|
|
input_mt_init_slots(dev, 2, INPUT_MT_POINTER);
|
2011-08-24 06:02:56 +00:00
|
|
|
|
|
|
|
/* Image sensors can signal 4 and 5 finger clicks */
|
|
|
|
__set_bit(BTN_TOOL_QUADTAP, dev->keybit);
|
|
|
|
__set_bit(BTN_TOOL_QUINTTAP, dev->keybit);
|
Input: synaptics - add image sensor support
Synaptics makes (at least) two kinds of touchpad sensors:
* Older pads use a profile sensor that could only infer the location
of individual fingers based on the projection of their profiles
onto row and column sensors.
* Newer pads use an image sensor that can track true finger position
using a two-dimensional sensor grid.
Both sensor types support an "Advanced Gesture Mode":
When multiple fingers are detected, the touchpad sends alternating
"Advanced Gesture Mode" (AGM) and "Simple Gesture Mode" (SGM)
packets.
The AGM packets have w=2, and contain reduced resolution finger data
The SGM packets have w={0,1} and contain full resolution finger data
Profile sensors try to report the "upper" (larger y value) finger in
the SGM packet, and the lower (smaller y value) in the AGM packet.
However, due to the nature of the profile sensor, they easily get
confused when fingers cross, and can start reporting the x-coordinate
of one with the y-coordinate of the other. Thus, for profile
sensors, "semi-mt" was created, which reports a "bounding box"
created by pairing min and max coordinates of the two pairs of
reported fingers.
Image sensors can report the actual coordinates of two of the fingers
present. This patch detects if the touchpad is an image sensor and
reports finger data using the MT-B protocol.
NOTE: This patch only adds partial support for 2-finger gestures.
The proper interpretation of the slot contents when more than
two fingers are present is left to later patches. Also,
handling of 'number of fingers' transitions is incomplete.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-08-24 06:02:25 +00:00
|
|
|
} else if (SYN_CAP_ADV_GESTURE(priv->ext_cap_0c)) {
|
|
|
|
/* Non-image sensors with AGM use semi-mt */
|
2010-12-21 17:11:25 +00:00
|
|
|
__set_bit(INPUT_PROP_SEMI_MT, dev->propbit);
|
2012-08-11 20:07:55 +00:00
|
|
|
input_mt_init_slots(dev, 2, 0);
|
2011-08-24 06:00:41 +00:00
|
|
|
set_abs_position_params(dev, priv, ABS_MT_POSITION_X,
|
|
|
|
ABS_MT_POSITION_Y);
|
2010-12-21 17:11:25 +00:00
|
|
|
}
|
|
|
|
|
2010-07-19 16:06:15 +00:00
|
|
|
if (SYN_CAP_PALMDETECT(priv->capabilities))
|
2010-07-19 16:06:15 +00:00
|
|
|
input_set_abs_params(dev, ABS_TOOL_WIDTH, 0, 15, 0, 0);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2009-09-10 02:13:20 +00:00
|
|
|
__set_bit(BTN_TOUCH, dev->keybit);
|
|
|
|
__set_bit(BTN_TOOL_FINGER, dev->keybit);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2008-11-20 20:24:42 +00:00
|
|
|
if (SYN_CAP_MULTIFINGER(priv->capabilities)) {
|
2009-09-10 02:13:20 +00:00
|
|
|
__set_bit(BTN_TOOL_DOUBLETAP, dev->keybit);
|
|
|
|
__set_bit(BTN_TOOL_TRIPLETAP, dev->keybit);
|
2008-11-20 20:24:42 +00:00
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
if (SYN_CAP_FOUR_BUTTON(priv->capabilities) ||
|
|
|
|
SYN_CAP_MIDDLE_BUTTON(priv->capabilities)) {
|
2009-09-10 02:13:20 +00:00
|
|
|
__set_bit(BTN_FORWARD, dev->keybit);
|
|
|
|
__set_bit(BTN_BACK, dev->keybit);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap); i++)
|
2009-09-10 02:13:20 +00:00
|
|
|
__set_bit(BTN_0 + i, dev->keybit);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2009-09-10 02:13:20 +00:00
|
|
|
__clear_bit(EV_REL, dev->evbit);
|
|
|
|
__clear_bit(REL_X, dev->relbit);
|
|
|
|
__clear_bit(REL_Y, dev->relbit);
|
2009-06-11 06:27:24 +00:00
|
|
|
|
2010-04-19 17:37:21 +00:00
|
|
|
if (SYN_CAP_CLICKPAD(priv->ext_cap_0c)) {
|
2010-12-16 08:52:23 +00:00
|
|
|
__set_bit(INPUT_PROP_BUTTONPAD, dev->propbit);
|
2010-04-19 17:37:21 +00:00
|
|
|
/* Clickpads report only left button */
|
|
|
|
__clear_bit(BTN_RIGHT, dev->keybit);
|
|
|
|
__clear_bit(BTN_MIDDLE, dev->keybit);
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
Input: synaptics - add support for Relative mode
Currently, the synaptics driver puts the device into Absolute mode.
As explained in the synaptics documentation section 3.2, in this mode,
the device sends a continuous stream of packets at the maximum rate
to the host when the user's fingers are near or on the pad or
pressing buttons, and continues streaming for 1 second afterwards.
These packets are even sent when there is no new information to report,
even when they are duplicates of the previous packet.
For embedded systems this is a bit much - it results in a huge
and uninterrupted stream of interrupts at high rate.
This patch adds support for Relative mode, which can be selected as
a new psmouse protocol. In this mode, the device does not send duplicate
packets and acts like a standard PS/2 mouse. However, synaptics-specific
functionality is still available, such as the ability to set the packet
rate, and rather than disabling gestures and taps at the hardware level
unconditionally, a 'synaptics_disable_gesture' sysfs attribute has
been added to allow control of this functionality.
This solves a long standing OLPC issue: synaptics hardware enables
tap to click by default (even in the default relative mode), but we
have found this to be inappropriate for young children and first
time computer users. Enabling the synaptics driver disables tap-to-click,
but we have previously been unable to use this because it also enables
Absolute mode, which is too "spammy" for our desires and actually
overloads our EC with its continuous stream of packets. Now we can enable
the synaptics driver, disabling tap to click while retaining the less
noisy Relative mode.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-11-08 08:00:35 +00:00
|
|
|
static ssize_t synaptics_show_disable_gesture(struct psmouse *psmouse,
|
|
|
|
void *data, char *buf)
|
|
|
|
{
|
|
|
|
struct synaptics_data *priv = psmouse->private;
|
|
|
|
|
|
|
|
return sprintf(buf, "%c\n", priv->disable_gesture ? '1' : '0');
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t synaptics_set_disable_gesture(struct psmouse *psmouse,
|
|
|
|
void *data, const char *buf,
|
|
|
|
size_t len)
|
|
|
|
{
|
|
|
|
struct synaptics_data *priv = psmouse->private;
|
|
|
|
unsigned int value;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
err = kstrtouint(buf, 10, &value);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
if (value > 1)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (value == priv->disable_gesture)
|
|
|
|
return len;
|
|
|
|
|
|
|
|
priv->disable_gesture = value;
|
|
|
|
if (value)
|
|
|
|
priv->mode |= SYN_BIT_DISABLE_GESTURE;
|
|
|
|
else
|
|
|
|
priv->mode &= ~SYN_BIT_DISABLE_GESTURE;
|
|
|
|
|
|
|
|
if (synaptics_mode_cmd(psmouse, priv->mode))
|
|
|
|
return -EIO;
|
|
|
|
|
|
|
|
return len;
|
|
|
|
}
|
|
|
|
|
|
|
|
PSMOUSE_DEFINE_ATTR(disable_gesture, S_IWUSR | S_IRUGO, NULL,
|
|
|
|
synaptics_show_disable_gesture,
|
|
|
|
synaptics_set_disable_gesture);
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
static void synaptics_disconnect(struct psmouse *psmouse)
|
|
|
|
{
|
Input: synaptics - add support for Relative mode
Currently, the synaptics driver puts the device into Absolute mode.
As explained in the synaptics documentation section 3.2, in this mode,
the device sends a continuous stream of packets at the maximum rate
to the host when the user's fingers are near or on the pad or
pressing buttons, and continues streaming for 1 second afterwards.
These packets are even sent when there is no new information to report,
even when they are duplicates of the previous packet.
For embedded systems this is a bit much - it results in a huge
and uninterrupted stream of interrupts at high rate.
This patch adds support for Relative mode, which can be selected as
a new psmouse protocol. In this mode, the device does not send duplicate
packets and acts like a standard PS/2 mouse. However, synaptics-specific
functionality is still available, such as the ability to set the packet
rate, and rather than disabling gestures and taps at the hardware level
unconditionally, a 'synaptics_disable_gesture' sysfs attribute has
been added to allow control of this functionality.
This solves a long standing OLPC issue: synaptics hardware enables
tap to click by default (even in the default relative mode), but we
have found this to be inappropriate for young children and first
time computer users. Enabling the synaptics driver disables tap-to-click,
but we have previously been unable to use this because it also enables
Absolute mode, which is too "spammy" for our desires and actually
overloads our EC with its continuous stream of packets. Now we can enable
the synaptics driver, disabling tap to click while retaining the less
noisy Relative mode.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-11-08 08:00:35 +00:00
|
|
|
struct synaptics_data *priv = psmouse->private;
|
|
|
|
|
|
|
|
if (!priv->absolute_mode && SYN_ID_DISGEST_SUPPORTED(priv->identity))
|
|
|
|
device_remove_file(&psmouse->ps2dev.serio->dev,
|
|
|
|
&psmouse_attr_disable_gesture.dattr);
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
synaptics_reset(psmouse);
|
Input: synaptics - add support for Relative mode
Currently, the synaptics driver puts the device into Absolute mode.
As explained in the synaptics documentation section 3.2, in this mode,
the device sends a continuous stream of packets at the maximum rate
to the host when the user's fingers are near or on the pad or
pressing buttons, and continues streaming for 1 second afterwards.
These packets are even sent when there is no new information to report,
even when they are duplicates of the previous packet.
For embedded systems this is a bit much - it results in a huge
and uninterrupted stream of interrupts at high rate.
This patch adds support for Relative mode, which can be selected as
a new psmouse protocol. In this mode, the device does not send duplicate
packets and acts like a standard PS/2 mouse. However, synaptics-specific
functionality is still available, such as the ability to set the packet
rate, and rather than disabling gestures and taps at the hardware level
unconditionally, a 'synaptics_disable_gesture' sysfs attribute has
been added to allow control of this functionality.
This solves a long standing OLPC issue: synaptics hardware enables
tap to click by default (even in the default relative mode), but we
have found this to be inappropriate for young children and first
time computer users. Enabling the synaptics driver disables tap-to-click,
but we have previously been unable to use this because it also enables
Absolute mode, which is too "spammy" for our desires and actually
overloads our EC with its continuous stream of packets. Now we can enable
the synaptics driver, disabling tap to click while retaining the less
noisy Relative mode.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-11-08 08:00:35 +00:00
|
|
|
kfree(priv);
|
2005-04-16 22:20:36 +00:00
|
|
|
psmouse->private = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int synaptics_reconnect(struct psmouse *psmouse)
|
|
|
|
{
|
|
|
|
struct synaptics_data *priv = psmouse->private;
|
|
|
|
struct synaptics_data old_priv = *priv;
|
2013-06-04 16:30:55 +00:00
|
|
|
unsigned char param[2];
|
2011-01-29 06:05:14 +00:00
|
|
|
int retry = 0;
|
|
|
|
int error;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2011-01-29 06:05:14 +00:00
|
|
|
do {
|
|
|
|
psmouse_reset(psmouse);
|
2011-12-12 08:05:53 +00:00
|
|
|
if (retry) {
|
|
|
|
/*
|
|
|
|
* On some boxes, right after resuming, the touchpad
|
|
|
|
* needs some time to finish initializing (I assume
|
|
|
|
* it needs time to calibrate) and start responding
|
|
|
|
* to Synaptics-specific queries, so let's wait a
|
|
|
|
* bit.
|
|
|
|
*/
|
|
|
|
ssleep(1);
|
|
|
|
}
|
2013-06-04 16:30:55 +00:00
|
|
|
ps2_command(&psmouse->ps2dev, param, PSMOUSE_CMD_GETID);
|
2011-01-29 06:05:14 +00:00
|
|
|
error = synaptics_detect(psmouse, 0);
|
|
|
|
} while (error && ++retry < 3);
|
2009-02-28 20:51:01 +00:00
|
|
|
|
2011-01-29 06:05:14 +00:00
|
|
|
if (error)
|
2005-04-16 22:20:36 +00:00
|
|
|
return -1;
|
|
|
|
|
2011-01-29 06:05:14 +00:00
|
|
|
if (retry > 1)
|
2011-10-11 01:27:03 +00:00
|
|
|
psmouse_dbg(psmouse, "reconnected after %d tries\n", retry);
|
2011-01-29 06:05:14 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
if (synaptics_query_hardware(psmouse)) {
|
2011-10-11 01:27:03 +00:00
|
|
|
psmouse_err(psmouse, "Unable to query device.\n");
|
2005-04-16 22:20:36 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
Input: synaptics - add support for Relative mode
Currently, the synaptics driver puts the device into Absolute mode.
As explained in the synaptics documentation section 3.2, in this mode,
the device sends a continuous stream of packets at the maximum rate
to the host when the user's fingers are near or on the pad or
pressing buttons, and continues streaming for 1 second afterwards.
These packets are even sent when there is no new information to report,
even when they are duplicates of the previous packet.
For embedded systems this is a bit much - it results in a huge
and uninterrupted stream of interrupts at high rate.
This patch adds support for Relative mode, which can be selected as
a new psmouse protocol. In this mode, the device does not send duplicate
packets and acts like a standard PS/2 mouse. However, synaptics-specific
functionality is still available, such as the ability to set the packet
rate, and rather than disabling gestures and taps at the hardware level
unconditionally, a 'synaptics_disable_gesture' sysfs attribute has
been added to allow control of this functionality.
This solves a long standing OLPC issue: synaptics hardware enables
tap to click by default (even in the default relative mode), but we
have found this to be inappropriate for young children and first
time computer users. Enabling the synaptics driver disables tap-to-click,
but we have previously been unable to use this because it also enables
Absolute mode, which is too "spammy" for our desires and actually
overloads our EC with its continuous stream of packets. Now we can enable
the synaptics driver, disabling tap to click while retaining the less
noisy Relative mode.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-11-08 08:00:35 +00:00
|
|
|
if (synaptics_set_mode(psmouse)) {
|
2011-10-11 01:27:03 +00:00
|
|
|
psmouse_err(psmouse, "Unable to initialize device.\n");
|
2005-04-16 22:20:36 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2011-01-29 06:05:14 +00:00
|
|
|
if (old_priv.identity != priv->identity ||
|
|
|
|
old_priv.model_id != priv->model_id ||
|
|
|
|
old_priv.capabilities != priv->capabilities ||
|
|
|
|
old_priv.ext_cap != priv->ext_cap) {
|
2011-10-11 01:27:03 +00:00
|
|
|
psmouse_err(psmouse,
|
|
|
|
"hardware appears to be different: id(%ld-%ld), model(%ld-%ld), caps(%lx-%lx), ext(%lx-%lx).\n",
|
|
|
|
old_priv.identity, priv->identity,
|
|
|
|
old_priv.model_id, priv->model_id,
|
|
|
|
old_priv.capabilities, priv->capabilities,
|
|
|
|
old_priv.ext_cap, priv->ext_cap);
|
2011-01-29 06:05:14 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-12-04 07:21:14 +00:00
|
|
|
static bool impaired_toshiba_kbc;
|
|
|
|
|
2013-08-12 18:05:58 +00:00
|
|
|
static const struct dmi_system_id toshiba_dmi_table[] __initconst = {
|
2009-12-04 07:21:14 +00:00
|
|
|
#if defined(CONFIG_DMI) && defined(CONFIG_X86)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2009-12-04 18:24:20 +00:00
|
|
|
/* Toshiba Satellite */
|
2005-04-16 22:20:36 +00:00
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
|
2006-04-02 05:10:18 +00:00
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "Satellite"),
|
2005-04-16 22:20:36 +00:00
|
|
|
},
|
|
|
|
},
|
2005-07-11 06:07:20 +00:00
|
|
|
{
|
2009-12-04 18:24:20 +00:00
|
|
|
/* Toshiba Dynabook */
|
2005-07-11 06:07:20 +00:00
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
|
2006-04-02 05:10:18 +00:00
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "dynabook"),
|
|
|
|
},
|
|
|
|
},
|
|
|
|
{
|
2009-12-04 18:24:20 +00:00
|
|
|
/* Toshiba Portege M300 */
|
2006-04-02 05:10:18 +00:00
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "PORTEGE M300"),
|
2005-07-11 06:07:20 +00:00
|
|
|
},
|
2009-10-13 04:35:00 +00:00
|
|
|
|
|
|
|
},
|
|
|
|
{
|
2009-12-04 18:24:20 +00:00
|
|
|
/* Toshiba Portege M300 */
|
2009-10-13 04:35:00 +00:00
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "Portable PC"),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_VERSION, "Version 1.0"),
|
|
|
|
},
|
|
|
|
|
2005-07-11 06:07:20 +00:00
|
|
|
},
|
2005-04-16 22:20:36 +00:00
|
|
|
#endif
|
2011-03-31 07:01:58 +00:00
|
|
|
{ }
|
2009-12-04 07:21:14 +00:00
|
|
|
};
|
|
|
|
|
2010-12-23 09:19:38 +00:00
|
|
|
static bool broken_olpc_ec;
|
|
|
|
|
2013-08-12 18:05:58 +00:00
|
|
|
static const struct dmi_system_id olpc_dmi_table[] __initconst = {
|
2010-12-23 09:19:38 +00:00
|
|
|
#if defined(CONFIG_DMI) && defined(CONFIG_OLPC)
|
|
|
|
{
|
|
|
|
/* OLPC XO-1 or XO-1.5 */
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "OLPC"),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "XO"),
|
|
|
|
},
|
|
|
|
},
|
|
|
|
#endif
|
2011-03-31 07:01:58 +00:00
|
|
|
{ }
|
2010-12-23 09:19:38 +00:00
|
|
|
};
|
|
|
|
|
2014-03-28 07:43:00 +00:00
|
|
|
static const struct dmi_system_id min_max_dmi_table[] __initconst = {
|
|
|
|
#if defined(CONFIG_DMI)
|
|
|
|
{
|
|
|
|
/* Lenovo ThinkPad Helix */
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad Helix"),
|
|
|
|
},
|
|
|
|
.driver_data = (int []){1024, 5052, 2258, 4832},
|
|
|
|
},
|
2014-03-28 08:01:38 +00:00
|
|
|
{
|
|
|
|
/* Lenovo ThinkPad X240 */
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X240"),
|
|
|
|
},
|
|
|
|
.driver_data = (int []){1232, 5710, 1156, 4696},
|
|
|
|
},
|
2014-03-28 07:43:00 +00:00
|
|
|
{
|
|
|
|
/* Lenovo ThinkPad T440s */
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T440"),
|
|
|
|
},
|
|
|
|
.driver_data = (int []){1024, 5112, 2024, 4832},
|
|
|
|
},
|
|
|
|
{
|
|
|
|
/* Lenovo ThinkPad T540p */
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T540"),
|
|
|
|
},
|
|
|
|
.driver_data = (int []){1024, 5056, 2058, 4832},
|
|
|
|
},
|
|
|
|
#endif
|
|
|
|
{ }
|
|
|
|
};
|
|
|
|
|
2009-12-04 07:21:14 +00:00
|
|
|
void __init synaptics_module_init(void)
|
|
|
|
{
|
2014-03-28 07:43:00 +00:00
|
|
|
const struct dmi_system_id *min_max_dmi;
|
|
|
|
|
2009-12-04 07:21:14 +00:00
|
|
|
impaired_toshiba_kbc = dmi_check_system(toshiba_dmi_table);
|
2010-12-23 09:19:38 +00:00
|
|
|
broken_olpc_ec = dmi_check_system(olpc_dmi_table);
|
2014-03-28 07:43:00 +00:00
|
|
|
|
|
|
|
min_max_dmi = dmi_first_match(min_max_dmi_table);
|
|
|
|
if (min_max_dmi)
|
|
|
|
quirk_min_max = min_max_dmi->driver_data;
|
2009-12-04 07:21:14 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
Input: synaptics - add support for Relative mode
Currently, the synaptics driver puts the device into Absolute mode.
As explained in the synaptics documentation section 3.2, in this mode,
the device sends a continuous stream of packets at the maximum rate
to the host when the user's fingers are near or on the pad or
pressing buttons, and continues streaming for 1 second afterwards.
These packets are even sent when there is no new information to report,
even when they are duplicates of the previous packet.
For embedded systems this is a bit much - it results in a huge
and uninterrupted stream of interrupts at high rate.
This patch adds support for Relative mode, which can be selected as
a new psmouse protocol. In this mode, the device does not send duplicate
packets and acts like a standard PS/2 mouse. However, synaptics-specific
functionality is still available, such as the ability to set the packet
rate, and rather than disabling gestures and taps at the hardware level
unconditionally, a 'synaptics_disable_gesture' sysfs attribute has
been added to allow control of this functionality.
This solves a long standing OLPC issue: synaptics hardware enables
tap to click by default (even in the default relative mode), but we
have found this to be inappropriate for young children and first
time computer users. Enabling the synaptics driver disables tap-to-click,
but we have previously been unable to use this because it also enables
Absolute mode, which is too "spammy" for our desires and actually
overloads our EC with its continuous stream of packets. Now we can enable
the synaptics driver, disabling tap to click while retaining the less
noisy Relative mode.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-11-08 08:00:35 +00:00
|
|
|
static int __synaptics_init(struct psmouse *psmouse, bool absolute_mode)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
struct synaptics_data *priv;
|
Input: synaptics - add support for Relative mode
Currently, the synaptics driver puts the device into Absolute mode.
As explained in the synaptics documentation section 3.2, in this mode,
the device sends a continuous stream of packets at the maximum rate
to the host when the user's fingers are near or on the pad or
pressing buttons, and continues streaming for 1 second afterwards.
These packets are even sent when there is no new information to report,
even when they are duplicates of the previous packet.
For embedded systems this is a bit much - it results in a huge
and uninterrupted stream of interrupts at high rate.
This patch adds support for Relative mode, which can be selected as
a new psmouse protocol. In this mode, the device does not send duplicate
packets and acts like a standard PS/2 mouse. However, synaptics-specific
functionality is still available, such as the ability to set the packet
rate, and rather than disabling gestures and taps at the hardware level
unconditionally, a 'synaptics_disable_gesture' sysfs attribute has
been added to allow control of this functionality.
This solves a long standing OLPC issue: synaptics hardware enables
tap to click by default (even in the default relative mode), but we
have found this to be inappropriate for young children and first
time computer users. Enabling the synaptics driver disables tap-to-click,
but we have previously been unable to use this because it also enables
Absolute mode, which is too "spammy" for our desires and actually
overloads our EC with its continuous stream of packets. Now we can enable
the synaptics driver, disabling tap to click while retaining the less
noisy Relative mode.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-11-08 08:00:35 +00:00
|
|
|
int err = -1;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2010-12-23 09:19:38 +00:00
|
|
|
/*
|
2011-11-12 00:05:04 +00:00
|
|
|
* The OLPC XO has issues with Synaptics' absolute mode; the constant
|
|
|
|
* packet spew overloads the EC such that key presses on the keyboard
|
|
|
|
* are missed. Given that, don't even attempt to use Absolute mode.
|
|
|
|
* Relative mode seems to work just fine.
|
2010-12-23 09:19:38 +00:00
|
|
|
*/
|
2011-11-12 00:05:04 +00:00
|
|
|
if (absolute_mode && broken_olpc_ec) {
|
2011-10-11 01:27:03 +00:00
|
|
|
psmouse_info(psmouse,
|
|
|
|
"OLPC XO detected, not enabling Synaptics protocol.\n");
|
2010-12-23 09:19:38 +00:00
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
2006-03-14 05:09:16 +00:00
|
|
|
psmouse->private = priv = kzalloc(sizeof(struct synaptics_data), GFP_KERNEL);
|
2005-04-16 22:20:36 +00:00
|
|
|
if (!priv)
|
2010-09-30 01:53:35 +00:00
|
|
|
return -ENOMEM;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2009-02-28 20:51:01 +00:00
|
|
|
psmouse_reset(psmouse);
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
if (synaptics_query_hardware(psmouse)) {
|
2011-10-11 01:27:03 +00:00
|
|
|
psmouse_err(psmouse, "Unable to query device.\n");
|
2005-04-16 22:20:36 +00:00
|
|
|
goto init_fail;
|
|
|
|
}
|
|
|
|
|
Input: synaptics - add support for Relative mode
Currently, the synaptics driver puts the device into Absolute mode.
As explained in the synaptics documentation section 3.2, in this mode,
the device sends a continuous stream of packets at the maximum rate
to the host when the user's fingers are near or on the pad or
pressing buttons, and continues streaming for 1 second afterwards.
These packets are even sent when there is no new information to report,
even when they are duplicates of the previous packet.
For embedded systems this is a bit much - it results in a huge
and uninterrupted stream of interrupts at high rate.
This patch adds support for Relative mode, which can be selected as
a new psmouse protocol. In this mode, the device does not send duplicate
packets and acts like a standard PS/2 mouse. However, synaptics-specific
functionality is still available, such as the ability to set the packet
rate, and rather than disabling gestures and taps at the hardware level
unconditionally, a 'synaptics_disable_gesture' sysfs attribute has
been added to allow control of this functionality.
This solves a long standing OLPC issue: synaptics hardware enables
tap to click by default (even in the default relative mode), but we
have found this to be inappropriate for young children and first
time computer users. Enabling the synaptics driver disables tap-to-click,
but we have previously been unable to use this because it also enables
Absolute mode, which is too "spammy" for our desires and actually
overloads our EC with its continuous stream of packets. Now we can enable
the synaptics driver, disabling tap to click while retaining the less
noisy Relative mode.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-11-08 08:00:35 +00:00
|
|
|
priv->absolute_mode = absolute_mode;
|
|
|
|
if (SYN_ID_DISGEST_SUPPORTED(priv->identity))
|
|
|
|
priv->disable_gesture = true;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
Input: synaptics - add support for Relative mode
Currently, the synaptics driver puts the device into Absolute mode.
As explained in the synaptics documentation section 3.2, in this mode,
the device sends a continuous stream of packets at the maximum rate
to the host when the user's fingers are near or on the pad or
pressing buttons, and continues streaming for 1 second afterwards.
These packets are even sent when there is no new information to report,
even when they are duplicates of the previous packet.
For embedded systems this is a bit much - it results in a huge
and uninterrupted stream of interrupts at high rate.
This patch adds support for Relative mode, which can be selected as
a new psmouse protocol. In this mode, the device does not send duplicate
packets and acts like a standard PS/2 mouse. However, synaptics-specific
functionality is still available, such as the ability to set the packet
rate, and rather than disabling gestures and taps at the hardware level
unconditionally, a 'synaptics_disable_gesture' sysfs attribute has
been added to allow control of this functionality.
This solves a long standing OLPC issue: synaptics hardware enables
tap to click by default (even in the default relative mode), but we
have found this to be inappropriate for young children and first
time computer users. Enabling the synaptics driver disables tap-to-click,
but we have previously been unable to use this because it also enables
Absolute mode, which is too "spammy" for our desires and actually
overloads our EC with its continuous stream of packets. Now we can enable
the synaptics driver, disabling tap to click while retaining the less
noisy Relative mode.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-11-08 08:00:35 +00:00
|
|
|
if (synaptics_set_mode(psmouse)) {
|
|
|
|
psmouse_err(psmouse, "Unable to initialize device.\n");
|
2010-12-21 17:11:25 +00:00
|
|
|
goto init_fail;
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
priv->pkt_type = SYN_MODEL_NEWABS(priv->model_id) ? SYN_NEWABS : SYN_OLDABS;
|
|
|
|
|
2011-10-11 01:27:03 +00:00
|
|
|
psmouse_info(psmouse,
|
2012-07-08 01:08:51 +00:00
|
|
|
"Touchpad model: %ld, fw: %ld.%ld, id: %#lx, caps: %#lx/%#lx/%#lx, board id: %lu, fw id: %lu\n",
|
2011-10-11 01:27:03 +00:00
|
|
|
SYN_ID_MODEL(priv->identity),
|
|
|
|
SYN_ID_MAJOR(priv->identity), SYN_ID_MINOR(priv->identity),
|
|
|
|
priv->model_id,
|
2012-07-08 01:08:51 +00:00
|
|
|
priv->capabilities, priv->ext_cap, priv->ext_cap_0c,
|
|
|
|
priv->board_id, priv->firmware_id);
|
2005-05-28 07:12:18 +00:00
|
|
|
|
2005-09-15 07:01:44 +00:00
|
|
|
set_input_params(psmouse->dev, priv);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2007-04-12 05:30:41 +00:00
|
|
|
/*
|
|
|
|
* Encode touchpad model so that it can be used to set
|
|
|
|
* input device->id.version and be visible to userspace.
|
|
|
|
* Because version is __u16 we have to drop something.
|
|
|
|
* Hardware info bits seem to be good candidates as they
|
|
|
|
* are documented to be for Synaptics corp. internal use.
|
|
|
|
*/
|
|
|
|
psmouse->model = ((priv->model_id & 0x00ff0000) >> 8) |
|
|
|
|
(priv->model_id & 0x000000ff);
|
|
|
|
|
Input: synaptics - add support for Relative mode
Currently, the synaptics driver puts the device into Absolute mode.
As explained in the synaptics documentation section 3.2, in this mode,
the device sends a continuous stream of packets at the maximum rate
to the host when the user's fingers are near or on the pad or
pressing buttons, and continues streaming for 1 second afterwards.
These packets are even sent when there is no new information to report,
even when they are duplicates of the previous packet.
For embedded systems this is a bit much - it results in a huge
and uninterrupted stream of interrupts at high rate.
This patch adds support for Relative mode, which can be selected as
a new psmouse protocol. In this mode, the device does not send duplicate
packets and acts like a standard PS/2 mouse. However, synaptics-specific
functionality is still available, such as the ability to set the packet
rate, and rather than disabling gestures and taps at the hardware level
unconditionally, a 'synaptics_disable_gesture' sysfs attribute has
been added to allow control of this functionality.
This solves a long standing OLPC issue: synaptics hardware enables
tap to click by default (even in the default relative mode), but we
have found this to be inappropriate for young children and first
time computer users. Enabling the synaptics driver disables tap-to-click,
but we have previously been unable to use this because it also enables
Absolute mode, which is too "spammy" for our desires and actually
overloads our EC with its continuous stream of packets. Now we can enable
the synaptics driver, disabling tap to click while retaining the less
noisy Relative mode.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-11-08 08:00:35 +00:00
|
|
|
if (absolute_mode) {
|
|
|
|
psmouse->protocol_handler = synaptics_process_byte;
|
|
|
|
psmouse->pktsize = 6;
|
|
|
|
} else {
|
|
|
|
/* Relative mode follows standard PS/2 mouse protocol */
|
|
|
|
psmouse->protocol_handler = psmouse_process_byte;
|
|
|
|
psmouse->pktsize = 3;
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
psmouse->set_rate = synaptics_set_rate;
|
|
|
|
psmouse->disconnect = synaptics_disconnect;
|
|
|
|
psmouse->reconnect = synaptics_reconnect;
|
2007-02-18 06:40:24 +00:00
|
|
|
psmouse->cleanup = synaptics_reset;
|
2006-01-14 05:27:37 +00:00
|
|
|
/* Synaptics can usually stay in sync without extra help */
|
|
|
|
psmouse->resync_time = 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
if (SYN_CAP_PASS_THROUGH(priv->capabilities))
|
|
|
|
synaptics_pt_create(psmouse);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Toshiba's KBC seems to have trouble handling data from
|
2010-12-23 09:18:28 +00:00
|
|
|
* Synaptics at full rate. Switch to a lower rate (roughly
|
|
|
|
* the same rate as a standard PS/2 mouse).
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2009-12-04 07:21:14 +00:00
|
|
|
if (psmouse->rate >= 80 && impaired_toshiba_kbc) {
|
2011-10-11 01:27:03 +00:00
|
|
|
psmouse_info(psmouse,
|
|
|
|
"Toshiba %s detected, limiting rate to 40pps.\n",
|
|
|
|
dmi_get_system_info(DMI_PRODUCT_NAME));
|
2005-04-16 22:20:36 +00:00
|
|
|
psmouse->rate = 40;
|
|
|
|
}
|
|
|
|
|
Input: synaptics - add support for Relative mode
Currently, the synaptics driver puts the device into Absolute mode.
As explained in the synaptics documentation section 3.2, in this mode,
the device sends a continuous stream of packets at the maximum rate
to the host when the user's fingers are near or on the pad or
pressing buttons, and continues streaming for 1 second afterwards.
These packets are even sent when there is no new information to report,
even when they are duplicates of the previous packet.
For embedded systems this is a bit much - it results in a huge
and uninterrupted stream of interrupts at high rate.
This patch adds support for Relative mode, which can be selected as
a new psmouse protocol. In this mode, the device does not send duplicate
packets and acts like a standard PS/2 mouse. However, synaptics-specific
functionality is still available, such as the ability to set the packet
rate, and rather than disabling gestures and taps at the hardware level
unconditionally, a 'synaptics_disable_gesture' sysfs attribute has
been added to allow control of this functionality.
This solves a long standing OLPC issue: synaptics hardware enables
tap to click by default (even in the default relative mode), but we
have found this to be inappropriate for young children and first
time computer users. Enabling the synaptics driver disables tap-to-click,
but we have previously been unable to use this because it also enables
Absolute mode, which is too "spammy" for our desires and actually
overloads our EC with its continuous stream of packets. Now we can enable
the synaptics driver, disabling tap to click while retaining the less
noisy Relative mode.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-11-08 08:00:35 +00:00
|
|
|
if (!priv->absolute_mode && SYN_ID_DISGEST_SUPPORTED(priv->identity)) {
|
|
|
|
err = device_create_file(&psmouse->ps2dev.serio->dev,
|
|
|
|
&psmouse_attr_disable_gesture.dattr);
|
|
|
|
if (err) {
|
|
|
|
psmouse_err(psmouse,
|
|
|
|
"Failed to create disable_gesture attribute (%d)",
|
|
|
|
err);
|
|
|
|
goto init_fail;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
init_fail:
|
|
|
|
kfree(priv);
|
Input: synaptics - add support for Relative mode
Currently, the synaptics driver puts the device into Absolute mode.
As explained in the synaptics documentation section 3.2, in this mode,
the device sends a continuous stream of packets at the maximum rate
to the host when the user's fingers are near or on the pad or
pressing buttons, and continues streaming for 1 second afterwards.
These packets are even sent when there is no new information to report,
even when they are duplicates of the previous packet.
For embedded systems this is a bit much - it results in a huge
and uninterrupted stream of interrupts at high rate.
This patch adds support for Relative mode, which can be selected as
a new psmouse protocol. In this mode, the device does not send duplicate
packets and acts like a standard PS/2 mouse. However, synaptics-specific
functionality is still available, such as the ability to set the packet
rate, and rather than disabling gestures and taps at the hardware level
unconditionally, a 'synaptics_disable_gesture' sysfs attribute has
been added to allow control of this functionality.
This solves a long standing OLPC issue: synaptics hardware enables
tap to click by default (even in the default relative mode), but we
have found this to be inappropriate for young children and first
time computer users. Enabling the synaptics driver disables tap-to-click,
but we have previously been unable to use this because it also enables
Absolute mode, which is too "spammy" for our desires and actually
overloads our EC with its continuous stream of packets. Now we can enable
the synaptics driver, disabling tap to click while retaining the less
noisy Relative mode.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-11-08 08:00:35 +00:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
int synaptics_init(struct psmouse *psmouse)
|
|
|
|
{
|
|
|
|
return __synaptics_init(psmouse, true);
|
|
|
|
}
|
|
|
|
|
|
|
|
int synaptics_init_relative(struct psmouse *psmouse)
|
|
|
|
{
|
|
|
|
return __synaptics_init(psmouse, false);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2010-01-07 09:52:39 +00:00
|
|
|
bool synaptics_supported(void)
|
|
|
|
{
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2007-03-10 06:39:54 +00:00
|
|
|
#else /* CONFIG_MOUSE_PS2_SYNAPTICS */
|
|
|
|
|
2009-12-04 07:21:14 +00:00
|
|
|
void __init synaptics_module_init(void)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2007-03-10 06:39:54 +00:00
|
|
|
int synaptics_init(struct psmouse *psmouse)
|
|
|
|
{
|
|
|
|
return -ENOSYS;
|
|
|
|
}
|
|
|
|
|
2010-01-07 09:52:39 +00:00
|
|
|
bool synaptics_supported(void)
|
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2007-03-10 06:39:54 +00:00
|
|
|
#endif /* CONFIG_MOUSE_PS2_SYNAPTICS */
|