user/sven/linux.git/drivers/input/mouse/alps.c, branch v4.2.5

Input: alps - only Dell laptops have separate button bits for v2 dualpoint sticks

2015-08-03T21:11:47Z

It turns out that only Dell laptops have the separate button bits for v2 dualpoint sticks and that commit 92bac83dd79e ("Input: alps - non interleaved V2 dualpoint has separate stick button bits") causes regressions on Toshiba laptops. This commit adds a check for Dell laptops to the code for handling these extra button bits, fixing this regression. This patch has been tested on a Dell Latitude D620 to make sure that it does not reintroduce the original problem. Reported-and-tested-by: Douglas Christman Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov

Merge branch 'next' into for-linus

2015-06-22T16:26:29Z

Prepare first round of input updates for 4.2 merge window.

Input: alps - do not reduce trackpoint speed by half

2015-06-05T05:34:40Z

On some v7 devices (e.g. Lenovo-E550) the deltas reported are typically only in the 0-1 range dividing this by 2 results in a range of 0-0. And even for v7 devices where this does not lead to making the trackstick entirely unusable, it makes it twice as slow as before we added v7 support and were using the ps/2 mouse emulation of the dual point setup. If some kind of generic slowdown is actually necessary for some devices, then that belongs in userspace, not in the kernel. Cc: stable@vger.kernel.org Reported-and-tested-by: Rico Moorman Signed-off-by: Hans de Goede Reviewed-by: Benjamin Tissoires Signed-off-by: Dmitry Torokhov

Input: alps - fix finger jumps on lifting 2 fingers on v7 touchpad

2015-05-20T21:46:02Z

On v7 touchpads sometimes when 2 fingers are moved down on the touchpad until they "fall of" the touchpad, the second touch will report 0 for y (max y really since the y axis is inverted) and max x as coordinates, rather then reporting 0, 0 as is expected for a non touching finger. This commit detects this and treats these touches as non touching. See the evemu-recording here: https://bugzilla.redhat.com/attachment.cgi?id=1025058 BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1221200 Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov

Input: alps - use the generic process_bitmap function for v5 touchpads

2015-05-20T21:45:45Z

Now that the generic process_bitmap function has been improved to offer accurate coordinates for the first touch we can use it for v5 (dolphin) touchpads too. Besides being a nice code cleanup this also fixes the saw tooth pattern in the coordinates for the second touch the dolphin specific version had. Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov

Input: alps - rename alps_set_abs_params_mt to alps_set_abs_params_semi_mt

2015-05-20T21:45:45Z

Rename alps_set_abs_params_mt to alps_set_abs_params_semi_mt, to make it clear that it is only (to be) used for semi-mt devices. Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov

Input: alps - do not use input-mt finger tracking for semi-mt devices

2015-05-20T21:45:44Z

With the recent process_bitmap() changes all semi-mt devices always report the first finger down in slot 0, so stop using input-mt finger tracking for these. Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov

Input: alps - use more accurate coordinates for first touch in semi-mt mode

2015-05-20T21:45:44Z

All alps semi-mt touchpads give us the following data when 2 (or more) fingers are touching: 1 more or less accurate touch for the first finger down, and a bitmap with columns and rows in which 1 or more fingers are seen resulting in a crude (low res) bounding box. So far for v3, rushmore and v4 touchpads we've been reporting the coordinates of 2 opposite corners of the box when 2 fingers are touching. Ignoring the much better resolution data given in the normal position packet. This commit actually uses this data for the first touch, figures out which corner of the bounding box is closest to the first touch, and reports the coordinates of the opposite corner for the second touch, resulting in much better data for the first touch and for the single touch pointer-emulation events. This approach is similar to the one in alps_process_bitmap_dolphin, that function takes the single accurate touch info, calculates the distance to the center of the bounding box, and then puts the 2nd touch mirrored to the center. The downside of that approach is that if both touches move slowly in the same direction, the bounding box will stay the same for a while (as it is low res) and the second touch will thus been seen moving in the opposite direction until the bounding box actually changes, and then the second touch snaps to its new position resulting in a saw tooth pattern in the coordinates for the second touch, hence this new approach. This commit fixes 2 finger scrolling being choppy / jumpy on these touchpads. Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov

Input: alps - decode the position packet first

2015-05-20T21:45:43Z

We should decode the position packet before the packet with the bitmap data. This way we can use the more accurate position info in process_bitmap() to get better results. Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov

Input: alps - only set fields that are actually present

2015-05-20T21:45:43Z

Pinnacle / Rushmore packets contain either position info, or bitmap info, never both. So far we've in essence been storing garbage in the position / bitmap fields of the fields struct when decoding a bitmap / pos packet. We've been relying on the following sequence to get away with this: 1) Decode bitmap packet 2) Process bitmap packet 3) Decode position packet 4) Use position / button info This patch allows us to change this sequence, which will allow using the position info when processing the bitmap for more accurate results. Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov