Hi Ulf,
Thanks for replying.
> that is indeed an odd phenomenon - and an odd workaround which I
> wouldn't like to see in pms without being sure that there is a
> firmware bug. If you don't mind to make more tests, I'll send
> you some patches for debugging (please be patient, it may take a
> while).
Sure, no problem, and no need to hurry.
On another thought, the way pms handles desynchronisation is to discard
all currently read packet bytes at the moment desynchronisation is
detected, and then try to continue operation assuming the next received
byte starts a new packet - this strategy may lead to a cascade of
desynchronisation events spanning multiple packets.
Perhaps a better strategy is to discard the first byte by shifting the
packet array and try resume operation; this way the desynchronisation
cascade is more likely limited to only the invalid packet; something
along the following lines - this may affect other protocols however.
Regards,
Alexander
Index: sys/dev/pckbc/pms.c
===================================================================
RCS file: /cvs/src/sys/dev/pckbc/pms.c,v
retrieving revision 1.90
diff -u -p -r1.90 pms.c
--- sys/dev/pckbc/pms.c 20 Sep 2019 21:21:47 -0000 1.90
+++ sys/dev/pckbc/pms.c 24 Jan 2020 14:05:14 -0000
@@ -937,6 +937,7 @@ void
pmsinput(void *vsc, int data)
{
struct pms_softc *sc = vsc;
+ int i;
if (sc->sc_state != PMS_STATE_ENABLED) {
/* Interrupts are not expected. Discard the byte. */
@@ -954,7 +955,8 @@ pmsinput(void *vsc, int data)
printf(")\n");
#endif
- sc->inputstate = 0;
+ for (i = 0; i < sc->protocol->packetsize; i++)
+ sc->packet[i] = sc->packet[i+1];
return;
}
@@ -2386,6 +2388,9 @@ pms_sync_elantech_v4(struct pms_softc *s
return ((data & 0x08) == 0 ? 0 : -1);
if (sc->inputstate == 3) {
+ if ((sc->packet[0] & 0x08) != 0)
+ return -1;
+
switch (elantech_packet_type(sc->elantech, data)) {
case ELANTECH_V4_PKT_STATUS:
case ELANTECH_V4_PKT_HEAD:
