Re: [PATCH 2/5] Input: zinitix - do not ignore non-moving fingers

["Kaustabh Chakraborty" <kauschluss@disroot.org>]

On 2026-07-29 21:13 +05:30, Kaustabh Chakraborty wrote:
> On 2026-07-24 12:24 -07:00, Dmitry Torokhov wrote:
>> Hi Kaustabh,
>>
>> On Fri, Jul 24, 2026 at 12:54:04AM +0530, Kaustabh Chakraborty wrote:
>>> With the ZT7548 touchscreen present in the Galaxy J6, multitouch does not
>>> work reliably. This is due to the fact that the driver reports fingers
>>> only when their state is changed, so it's either placed against the
>>> scren, moved, or drawn away from the screen.
>>> 
>>> The function which is responsible for this is zinitix_report_finger().
>>> This function is called from the IRQ handler, under the following
>>> condition:
>>> 
>>> 		if (p->sub_status & SUB_BIT_EXIST)
>>> 			zinitix_report_finger(bt541, i, p);
>>> 
>>> This implies and ensures that every valid finger must have the
>>> SUB_BIT_EXIST flag.
>>> 
>>> However, at the beginning of the function, it refuses to recognize any
>>> finger if it has none of SUB_BIT_UP | SUB_BIT_DOWN | SUB_BIT_MOVE. This
>>> excludes fingers in reports which do not move from the position since
>>> the previous interrupt. Add SUB_BIT_EXIST to the list of valid bits.
>>
>> This makes the check basically a no-op as SUB_BIT_EXIST would always be
>> set when we reach this function. It may very well be that we want to
>> delete this check altogether, or maybe we need to add SUB_BIT_UPDATE and
>> SUB_BIT_WAIT. I am curious what status bits you see when this condition
>> (original) triggers for you...
>
> I see 0x03 [EXIST | DOWN] when the finger touches the screen, and 0x05
> [EXIST | MOVE] when it moves. When it stays in the same place (this is
> triggered in multitouch where one finger moves generating an event but
> the other is stagnant) it reports 0x01 [EXIST]. When it's lifted up it
> reports 0x08 [UP].
>
> It looks like report_finger() is meant to be called when the finger is
> up but it isn't because EXIST is not set during the UP event. So I guess
> the solution is to remove the guard in the IRQ func and call
> report_finger() unconditionally.

Actually no, interrupts are also called with 0x00 which should not be
used for reporting instead. So:

		if (p->sub_status)
			zinitix_report_finger(bt541, i, p);

>>> 
>>> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
>>> ---
>>>  drivers/input/touchscreen/zinitix.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>> 
>>> diff --git a/drivers/input/touchscreen/zinitix.c b/drivers/input/touchscreen/zinitix.c
>>> index 3421b8ffb19b..fdcb80f52c91 100644
>>> --- a/drivers/input/touchscreen/zinitix.c
>>> +++ b/drivers/input/touchscreen/zinitix.c
>>> @@ -406,7 +406,7 @@ static void zinitix_report_finger(struct bt541_ts_data *bt541, int slot,
>>>  	u16 x, y;
>>>  
>>>  	if (unlikely(!(p->sub_status &
>>> -		       (SUB_BIT_UP | SUB_BIT_DOWN | SUB_BIT_MOVE)))) {
>>> +		       (SUB_BIT_EXIST | SUB_BIT_UP | SUB_BIT_DOWN | SUB_BIT_MOVE)))) {
>>>  		dev_dbg(&bt541->client->dev, "unknown finger event %#02x\n",
>>>  			p->sub_status);
>>>  		return;
>>> 
>>
>> Thanks.