[9front] Wacom WACF008 glitching on ThinkPad X60/X61 Tablets

[9front] Wacom WACF008 glitching on ThinkPad X60/X61 Tablets

[sl]

Years ago I sent aiju my ThinkPad X41 Tablet (WACF004) and she made
the tablet function work in 9front.  I had retained a number of X60
and X61 Tablets (both WACF008) to test with, and they all seemed to
work with the new software.  Great!

The tablet function is enabled by setting the port and IRQ in
plan9.ini:

	uart2=type=isa port=0x200 irq=5

and then running a pair of programs:

	; aux/wacom
	; aux/tablet &

The first one interfaces the Wacom hardware directly.  The second one
interacts with the first, and causes the Wacom to be treated as a
mouse device.

This all works very well, except that on X60/X61 Tablets we observe
occasional bogus x and y data from aux/wacom.  This manifests as x
and/or y suddenly jumping hundreds of points away and then immediately
back again.  I've never noticed this causing the hardware cursor to
move, but when drawing with the pen in paint(1) or uxn's oekaki,
multiple users of these machines (not just me) have observed weird
behavior where giant straight lines will suddenly appear on screen,
seemingly as the drawing program struggles to join together the
rumors of clicks at distant x/y coordinates.

Example:

http://plan9.stanleylieber.com/uxn/img/20240325-glitch_commentary.png

I do not understand the bitwise magic taking place at
/sys/src/cmd/aux/wacom.c:/readpacket, and I'm not sure if the bogus
data is coming from the hardware, or if something is borked with how
we're massaging it in preparation for handing it over to aux/tablet,
but I've created an extremely naive patch for tablet.c that simply
ignores the bogus x/y coordinates if aux/wacom reports a jump of >100
points at a time when the pen is touching the screen.  for me, this
completely eliminates the problem, and is completely transparent to
the user in the sense that ignoring the bogus reads does not cause
stutter while manipulating the pen.

ACTHUNG!

I am not a programmer.

sl


diff 8a2efea90ce8ced888e0138b9f33e7f6179ae949 uncommitted
--- a/sys/src/cmd/aux/tablet.c
+++ b/sys/src/cmd/aux/tablet.c
@@ -14,7 +14,7 @@
 	if(tablet == nil) sysfatal("%r");
 	while(1) {
 		char *line, *p;
-		int x, y, b;
+		int x, y, b, ox, oy;
 		
 		line = Brdline(tablet, 10);
 		if(!line) sysfatal("%r");
@@ -27,6 +27,15 @@
 		if(*p++ != ' ') continue;
 		b = strtol(p, &p, 10);
 		if(*p++ != ' ') continue;
+		if(b==1){
+			if(!ox) ox = x;
+			if(!oy) oy = y;
+			if(ox-x >= 100 || x-ox >=100) continue;
+			if(oy-y >= 100 || y-oy >=100) continue;
+		}
+		ox = x;
+		oy = y;
 		fprint(mouseout, "A %d %d %d\n", x, y, b);
 	}
-}
\ No newline at end of file
+}

Re: [9front] Wacom WACF008 glitching on ThinkPad X60/X61 Tablets

[Stanley Lieber]

https://www.youtube.com/watch?v=lygAVpUwCz8

Re: [9front] Wacom WACF008 glitching on ThinkPad X60/X61 Tablets

[cinap_lenrek]

i said before, you need to capture the bytes going thru the serial here,
to see what is going on and if we have a chance working around it.

instrument the driver and log the bytes in hex into a logfile,
with a timestamp.

--
cinap

Re: [9front] Wacom WACF008 glitching on ThinkPad X60/X61 Tablets

[Stanley Lieber]

On May 29, 2024 5:24:04 AM EDT, cinap_lenrek@felloff.net wrote:
>i said before, you need to capture the bytes going thru the serial here,
>to see what is going on and if we have a chance working around it.
>
>instrument the driver and log the bytes in hex into a logfile,
>with a timestamp.
>
>--
>cinap
>

the reason i didn't do this already is because i don't know how. i triangulated the undesirable behavior and worked around it. badly, yes, which is why i posted here for comments. but what i did do does allow me to draw without glitches, so as a start, at least, i wanted to share this to benefit others struggling with the same behavior. i realize i didn't address the underlying problem.

the bitwise stuff happening in query() and readpacket() looks like gibberish to me. i'm sure it's all quite compact and sensible, but when i look at it, i'm just hearing the teacher from charlie brown. in order to log raw bytes, should i just be dumping the entirety of buf (in readpacket()) to disk? and then how do i interpret it?

i did not have any luck searching for documentation on the protocol this device uses. i did try looking at the linux driver, but again, it's miss othmar all the way down.

thanks,

sl