9front - general discussion about 9front
 help / color / mirror / Atom feed
From: sl@stanleylieber.com
To: 9front@9front.org
Subject: [9front] Wacom WACF008 glitching on ThinkPad X60/X61 Tablets
Date: Sat, 25 May 2024 21:50:51 -0400	[thread overview]
Message-ID: <B046A8CAEF83B4B0B8F724B643A623CA@gaff.inri.net> (raw)

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
+}

             reply	other threads:[~2024-05-26  1:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-26  1:50 sl [this message]
2024-05-28  2:26 ` Stanley Lieber
2024-05-29  9:24   ` cinap_lenrek
2024-05-29 14:19     ` Stanley Lieber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=B046A8CAEF83B4B0B8F724B643A623CA@gaff.inri.net \
    --to=sl@stanleylieber.com \
    --cc=9front@9front.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).