From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <9front-bounces@9front.inri.net>
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham
	autolearn_force=no version=3.4.4
Received: from 9front.inri.net (9front.inri.net [168.235.81.73])
	by inbox.vuxu.org (Postfix) with ESMTP id 5B20E298F0
	for <ml@inbox.vuxu.org>; Sun, 14 Jan 2024 21:26:04 +0100 (CET)
Received: from duke.felloff.net ([216.126.196.34]) by 9front; Sun Jan 14 15:24:28 -0500 2024
Message-ID: <81135DE0B2F485EDD907E472B2C493A4@felloff.net>
Date: Sun, 14 Jan 2024 21:24:17 +0100
From: cinap_lenrek@felloff.net
To: 9front@9front.org
In-Reply-To: <147EB4543ABBB0841A8F54F2B9AB766B@gaff.inri.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: lossless property interface 
Subject: Re: [9front] recent kernel changes break built-in wacom serial tablet on
Reply-To: 9front@9front.org
Precedence: bulk

interesting.

there was some changes in how the console uarts get initialized,
however, given that you can still change the cursor horizontally
means we'r receiving bytes from the tablet fine. maybe it
was caused by scheduler changes...

it seems that the code that tries to re-synchronize with the
packet stream is somehow desynchronized.

the code basically looks for a start byte "head" that has bit 7 (0x80)
set and then assume 9 more bytes for the full packet afterwards:

int
findheader(Tablet* t)
{
	uchar c;
	
	do {
		if(read(t->ser, &c, 1) < 1) return -1;
	} while((c & 0x80) == 0);
	return c;
}

Message*
readpacket(Tablet* t)
{
	uchar buf[9];
	int head;
	Message *m;

	head = findheader(t);
	if(head < 0) return 0;
	if(readn(t->ser, buf, 9) < 9) return 0;
	
	m = calloc(sizeof(Message), 1);
	incref(m);
	
	m->b = head & 7;
	m->x = (buf[0] << 9) | (buf[1] << 2) | ((buf[5] >> 5) & 3);
	m->y = (buf[2] << 9) | (buf[3] << 2) | ((buf[5] >> 3) & 3);
	m->p = ((buf[5] & 7) << 7) | buf[4];
	
	m->p *= MAX;
	m->p /= t->pmax;
	m->x *= t->sx;
	m->x /= t->xmax;
	m->y *= t->sy;
	m->y /= t->ymax;
	
	m->msg = smprint("m %d %d %d %d\n", m->x, m->y, m->b, m->p);
	return m;
}

i'd start debugging here. it is possible there is some crap in
the uart fifo when we switch the baud-rate and the re-synchronizatoin
code fails to recover from that.

also the serial mode might be different? maybe it is trying todo
software flow-control or something? can you cat:

cat /dev/eia2status

maybe one test you could do is using dd with a block size of 10 bytes:

</dev/eia2data {while(){dd -bs 10 -count 1 | xd -x1}}

--
cinap