Re: [PATCH 1/2] Input: synaptics: Use in-kernel tracking for reporting mt data

From: Benjamin Tissoires
Date: Mon Dec 08 2014 - 13:01:33 EST


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?

Cheers,
Benjamin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/