Re: [PATCH 2/5] Input: zinitix - do not ignore non-moving fingers
"Kaustabh Chakraborty" <[email protected]> Wed, 29 Jul 2026 21:32:00 +0530
| Newsgroups | org.kernel.vger.linux-samsung-soc,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-input,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
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 n= ot >>> 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. >>>=20 >>> The function which is responsible for this is zinitix_report_finger(). >>> This function is called from the IRQ handler, under the following >>> condition: >>>=20 >>> if (p->sub_status & SUB_BIT_EXIST) >>> zinitix_report_finger(bt541, i, p); >>>=20 >>> This implies and ensures that every valid finger must have the >>> SUB_BIT_EXIST flag. >>>=20 >>> 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); >>>=20 >>> Signed-off-by: Kaustabh Chakraborty <[email protected]> >>> --- >>> drivers/input/touchscreen/zinitix.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>=20 >>> diff --git a/drivers/input/touchscreen/zinitix.c b/drivers/input/touchs= creen/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_d= ata *bt541, int slot, >>> u16 x, y; >>> =20 >>> 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; >>>=20 >> >> Thanks.