[9front] recent kernel changes break built-in wacom serial tablet on

[9front] recent kernel changes break built-in wacom serial tablet on

[sl]

thinkpad x60t/x61t

the serial wacom on this machine has always worked since aiju first
implemented support for the x41t:

	uart2=type=isa port=0x200 irq=5 # plan9.ini
	aux/wacom && aux/tablet & # riostart

today i updated my system and now when using the pen the pointer
immediately warps to the bottom of the screen and stays there no
matter what i do.  i can still cause the pointer to move horizontally
with the pen, it just won't get up off the floor no matter how i threaten.

when i rebooted off my old kernel (maybe a couple of months old) the
tablet once again works as normal.

sl

[0] http://plan9.stanleylieber.com/hardware/thinkpad/x60t/6366-l6u/sysinfo

Re: [9front] recent kernel changes break built-in wacom serial tablet on

[sl]

update:

immediately after writing the previous message i rebuilt the kernel
again and rebooted and now the tablet works as normal again.

your guess is as good as mine.

sl

Re: [9front] recent kernel changes break built-in wacom serial tablet on

[cinap_lenrek]

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

Re: [9front] recent kernel changes break built-in wacom serial tablet on

[cinap_lenrek]

i forgot...

you have to set the baudrate like aux/wacom:

	if(fprint(serctl, "b19200\n") < 0) {

so:

echo b19200 >/dev/eia2ctl

--
cinap

Re: [9front] recent kernel changes break built-in wacom serial tablet on

[cinap_lenrek]

another possibility:

at startup, it aux/wacom asks the device for the
resolution that it will later use for scaling:

int
query(Tablet* t)
{
	uchar buf[11];

	if(write(t->ser, "&0*", 3) < 3) return -1;
	do {
		if(read(t->ser, buf, 1) < 1) return -1;
	} while(buf[0] != 0xC0);
	if(readn(t->ser, buf+1, 10) < 10) return -1;
	t->xmax = (buf[1] << 9) | (buf[2] << 2) | ((buf[6] >> 5) & 3);
	t->ymax = (buf[3] << 9) | (buf[4] << 2) | ((buf[6] >> 3) & 3);
	t->pmax = buf[5] | (buf[6] & 7);
	t->version = (buf[9] << 7) | buf[10];
	if(write(t->ser, "1", 1) < 1) return -1;
	return 0;
}

if this procress goes wrong for some reason
(because theres maybe garbage in the fifo?),
we might end up with a out-of-range t->ymax,
causing the y-corrdinate to become stuck at
eigther extreme?

adding a debug print here would be helpfull,
and maybe just calling query() multiple times
to see if the values stay consistent:

fprint(2, "query: xmax=%d ymax=%d pmax=%d version=%d\n",
	t->xmax, t->ymax, t->pmax, t->version);

...

	if(query(t) < 0) sysfatal("%r");
+	if(query(t) < 0) sysfatal("%r");
+	if(query(t) < 0) sysfatal("%r");

and finally, we should add a debug print in
readpacket() *BEFORE* the scaling:

	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];

fprint(2, "readpacket: b=%x x=%d y=%d p=%d\n", m->b, m->x, m->y, m->p);

...

in any case, lets make sure we understand
what is actually happening because i dont
know of any way how our recent changes could
have screwed up your tablet :(

--
cinap

[9front] Re: [9front] recent kernel changes break built-in wacom serial tablet on

[Stanley Lieber]

On January 14, 2024 4:28:01 PM EST, cinap_lenrek@felloff.net wrote:
>another possibility:
>
>at startup, it aux/wacom asks the device for the
>resolution that it will later use for scaling:
>
>int
>query(Tablet* t)
>{
>	uchar buf[11];
>
>	if(write(t->ser, "&0*", 3) < 3) return -1;
>	do {
>		if(read(t->ser, buf, 1) < 1) return -1;
>	} while(buf[0] != 0xC0);
>	if(readn(t->ser, buf+1, 10) < 10) return -1;
>	t->xmax = (buf[1] << 9) | (buf[2] << 2) | ((buf[6] >> 5) & 3);
>	t->ymax = (buf[3] << 9) | (buf[4] << 2) | ((buf[6] >> 3) & 3);
>	t->pmax = buf[5] | (buf[6] & 7);
>	t->version = (buf[9] << 7) | buf[10];
>	if(write(t->ser, "1", 1) < 1) return -1;
>	return 0;
>}
>
>if this procress goes wrong for some reason
>(because theres maybe garbage in the fifo?),
>we might end up with a out-of-range t->ymax,
>causing the y-corrdinate to become stuck at
>eigther extreme?
>
>adding a debug print here would be helpfull,
>and maybe just calling query() multiple times
>to see if the values stay consistent:
>
>fprint(2, "query: xmax=%d ymax=%d pmax=%d version=%d\n",
>	t->xmax, t->ymax, t->pmax, t->version);
>
>...
>
>	if(query(t) < 0) sysfatal("%r");
>+	if(query(t) < 0) sysfatal("%r");
>+	if(query(t) < 0) sysfatal("%r");
>
>and finally, we should add a debug print in
>readpacket() *BEFORE* the scaling:
>
>	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];
>
>fprint(2, "readpacket: b=%x x=%d y=%d p=%d\n", m->b, m->x, m->y, m->p);
>
>...
>
>in any case, lets make sure we understand
>what is actually happening because i dont
>know of any way how our recent changes could
>have screwed up your tablet :(
>
>--
>cinap
>

thank you for investigating this. in case you didn't see my other message,  i was only able to trigger this weird behavior once. i rolled back to my older kernel and it worked again as normal. i installed the new kernel again and now it still works as normal. maybe the initialization just got screwed up somehow that one time? i can no longer trigger the weird behavior.

sl