Re: pms(4): fix "pointer skipping" for certain v1 elantech touchpads

[sxvghd]

Bump. Anyone?

Also sorry for the malformed message, I always default to 80 characters
and forgot that this won't do it here. Here's a more readable version:

On 2020-09-02 17:43, sxv...@firemail.cc wrote:

So, continuing with fixing my netbook, I have another patch which
fixes "pointer skipping". This is a bug in 2 particular (0x20022 and
0x20600) elantech v1 firmwares which causes at least the first packet
(in my tests, only one packet was mangled, but Linux says two and I
don't have a way to test it with 0x20600 FW, so I'm just dropping two
packets, since it doesn't change anything for my FW) to state the
last position and not the current one, thus jumping the cursor
somewhere else.

I'm not really sure about the counter variable, can it be like this
or should it get moved to the softc struct or even somewhere else?


Index: pms.c
===
RCS file: /cvs/src/sys/dev/pckbc/pms.c,v
retrieving revision 1.94
diff -u -p -u -p -r1.94 pms.c
--- pms.c   10 Aug 2020 21:55:59 -  1.94
+++ pms.c   8 Sep 2020 14:32:10 -
@@ -2425,8 +2425,27 @@ void
 pms_proc_elantech_v1(struct pms_softc *sc)
 {
struct elantech_softc *elantech = sc->elantech;
+   static int single_touch_pkt = 0;
int x, y, w, z;
u_int buttons;
+
+   /*
+* Firmwares 0x20022 and 0x20600 have a bug, which makes the first 2
+* position reports mangled, which in turns causes cursor skipping.
+*/
+
+   if (elantech->fw_version == 0x20022 ||
+   elantech->fw_version == 0x20600) {
+   if((sc->packet[0] & 0xc0) >> 6)
+   {
+   if(single_touch_pkt < 2)
+   {
+   single_touch_pkt++;
+   return;
+   }
+   } else
+   single_touch_pkt = 0;
+   }

buttons = butmap[sc->packet[0] & 3];

pms(4): fix "pointer skipping" for certain v1 elantech touchpads

[sxvghd]

So, continuing with fixing my netbook, I have another patch which fixes
"pointer skipping". This is a bug in 2 particular (0x20022 and 0x20600) 
elantech
v1 firmwares which causes at least the first packet (in my tests, only 
one
packet was mangled, but Linux says two and I don't have a way to test it 
with
0x20600 FW, so I'm just dropping two packets, since it doesn't change 
anything
for my FW) to state the last position and not the current one, thus 
jumping the

cursor somewhere else.

I'm not really sure about the counter variable, can it be like this or 
should it

get moved to the softc struct or even somewhere else?


Index: pms.c
===
RCS file: /cvs/src/sys/dev/pckbc/pms.c,v
retrieving revision 1.94
diff -u -p -u -p -r1.94 pms.c
--- pms.c   10 Aug 2020 21:55:59 -  1.94
+++ pms.c   2 Sep 2020 14:54:48 -
@@ -2425,8 +2425,26 @@ void
 pms_proc_elantech_v1(struct pms_softc *sc)
 {
struct elantech_softc *elantech = sc->elantech;
+   static int single_touch_pkt = 0;
int x, y, w, z;
u_int buttons;
+
+   /*
+* Firmwares 0x20022 and 0x20600 have a bug, which makes the first 2
+* position reports mangled, which in turns causes cursor skipping.
+*/
+
+	if (elantech->fw_version == 0x20022 || elantech->fw_version == 
0x20600) {

+   if((sc->packet[0] & 0xc0) >> 6)
+   {
+   if(single_touch_pkt < 2)
+   {
+   single_touch_pkt++;
+   return;
+   }
+   } else
+   single_touch_pkt = 0;
+   }

buttons = butmap[sc->packet[0] & 3];

Re: pms(4): disable parity checking for specific elantech fw

[sxvghd]

On 2020-08-08 22:47, Marcus Glocker wrote:

Can we maybe add a small comment explaining the inverted parity bits
behaviour on cold boot for this firmware version?


Sure thing.

Index: pms.c
===
RCS file: /cvs/src/sys/dev/pckbc/pms.c,v
retrieving revision 1.93
diff -u -p -u -r1.93 pms.c
--- pms.c   4 Jul 2020 10:39:25 -   1.93
+++ pms.c   10 Aug 2020 12:58:01 -
@@ -2292,7 +2292,12 @@ pms_sync_elantech_v1(struct pms_softc *s
}

if (data < 0 || data >= nitems(elantech->parity) ||
-   elantech->parity[data] != p)
+   /*
+* FW 0x20022 sends inverted parity bits on cold boot, returning
+* to normal after suspend & resume, so the parity check is
+* disabled for this one.
+*/
+   (elantech->fw_version != 0x20022 && elantech->parity[data] != p))
return (-1);

return (0);

pms(4): disable parity checking for specific elantech fw

[sxvghd]

So I recently installed OpenBSD on an EeePC 900HD with an Elantech v1
touchpad (fw_version 0x20022).
This specific fw version for some reason sends inverted parity bits on a
cold boot, returning to normal after suspend & resume. That leads to a
failed parity check, dropped packets and ultimately a broken driver.

Index: pms.c
===
RCS file: /cvs/src/sys/dev/pckbc/pms.c,v
retrieving revision 1.93
diff -u -p -u -p -r1.93 pms.c
--- pms.c   4 Jul 2020 10:39:25 -   1.93
+++ pms.c   8 Aug 2020 14:45:14 -
@@ -2292,7 +2292,7 @@ pms_sync_elantech_v1(struct pms_softc *s
}

if (data < 0 || data >= nitems(elantech->parity) ||
-   elantech->parity[data] != p)
+   (elantech->fw_version != 0x20022 && elantech->parity[data] != p))
return (-1);

return (0);