Hi Benjamin, On Mon, Dec 08, 2014 at 01:01:28PM -0500, Benjamin Tissoires wrote: > On Thu, Nov 20, 2014 at 2:42 PM, Benjamin Tissoires > <benjamin.tissoires@xxxxxxxxx> wrote: > > On Fri, Oct 31, 2014 at 12:51 PM, Dmitry Torokhov > > <dmitry.torokhov@xxxxxxxxx> wrote: > >> On Thu, Oct 30, 2014 at 02:33:06PM -0400, Benjamin Tissoires wrote: > >>> The current code tries to consider all states and transitions to properly > >>> detect which finger is attached to which slot. The code is quite huge > >>> and difficult to read. > >>> If the sensor manages to group the touch points but is not reliable in > >>> giving tracking ids, we can simply use the kernel tracking method. Note > >>> that it is already used by Cr-48 Chromebooks. > >>> > >>> Incidentaly, this fixes a bug reported by Peter Hutterer: > >>> """ > >>> on the Lenovo T440, run: > >>> evemu-record /dev/input/event4 | grep BTN_ > >>> > >>> then put one, two, three, two fingers down > >>> when you go from 3 to 2 fingers the driver sends a spurious BTN_TOUCH 0 > >>> event: > >>> > >>> E: 0.000000 0001 014a 0001 # EV_KEY / BTN_TOUCH 1 > >>> E: 0.000000 0001 0145 0001 # EV_KEY / BTN_TOOL_FINGER 1 > >>> E: 0.770008 0001 0145 0000 # EV_KEY / BTN_TOOL_FINGER 0 > >>> E: 0.770008 0001 014d 0001 # EV_KEY / BTN_TOOL_DOUBLETAP 1 > >>> E: 1.924716 0001 014d 0000 # EV_KEY / BTN_TOOL_DOUBLETAP 0 > >>> E: 1.924716 0001 014e 0001 # EV_KEY / BTN_TOOL_TRIPLETAP 1 > >>> > >>> .. changing from 3 to 2 fingers now > >>> > >>> E: 3.152641 0001 014a 0000 # EV_KEY / BTN_TOUCH 0 > >>> E: 3.152641 0001 014d 0001 # EV_KEY / BTN_TOOL_DOUBLETAP 1 > >>> E: 3.152641 0001 014e 0000 # EV_KEY / BTN_TOOL_TRIPLETAP 0 > >>> E: 3.176948 0001 014a 0001 # EV_KEY / BTN_TOUCH 1 > >>> > >>> quick look in the kernel shows it's caused by hw.z going to 0 for a packet, > >>> so probably a firmware bug. either way, it makes it hard to track BTN_TOUCH > >>> as signal that at least one finger is down. > >>> """ > >>> > >>> The in-kernel tracking is enough to remove this spurious BTN_TOUCH 0. > >>> > >>> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@xxxxxxxxxx> > >>> --- > >>> > >>> Hi Dmitry, > >>> > >>> I started working on that for 2 other bug reports > >>> https://bugs.freedesktop.org/show_bug.cgi?id=81278 > >>> and > >>> https://bugs.freedesktop.org/show_bug.cgi?id=76722 > >>> > >>> I thought the cursor jumps could be fixed by the in-kernel tracking, but the > >>> tracking needs a little bit more work to filter them out (patches to follow soon). > >>> > >>> From a user perspective, this patch does not change anything to what the user > >>> previously had. It also fixes Peter's bug that's why I decide to send this out > >>> by itself (removing ~350 lines of code and fixing bugs is always nice). > >>> > >>> I think the cursor jump fixes will need more bikeshedding in input-mt.c (I am > >>> *really* bad at designing APIs), so I'll send it later as an RFC. > >> > >> Daniel and Chung-yih were working on the driver so let's see if they > >> have a moment... > >> > > > > Any news from the chrome team? This is a requirement for fixing the > > cursor jumps, and I'd rather have this series in shape before > > introducing the changes in input-mt.c. > > > > ping? Looks like a very nice fix and clean up. I queued it for 3.20, sorry for the delay. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
