Re: pms(4): disable parity checking for specific elantech fw
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);
Re: pms(4): disable parity checking for specific elantech fw
On Sat, 08 Aug 2020 17:08:01 +0200 sxv...@firemail.cc wrote: > 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. Can we maybe add a small comment explaining the inverted parity bits behaviour on cold boot for this firmware version? > 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); >
pms(4): disable parity checking for specific elantech fw
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);
