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 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 42A3E290B4 for ; Sun, 26 May 2024 03:55:00 +0200 (CEST) Received: from gaff.inri.net ([168.235.71.243]) by 9front; Sat May 25 21:50:51 -0400 2024 Message-ID: Date: Sat, 25 May 2024 21:50:51 -0400 From: sl@stanleylieber.com To: 9front@9front.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: open XMPP lifecycle metadata Subject: [9front] Wacom WACF008 glitching on ThinkPad X60/X61 Tablets Reply-To: 9front@9front.org Precedence: bulk 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 +}