From owner-freebsd-current  Sat Nov 30 05:24:57 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id FAA14654
          for current-outgoing; Sat, 30 Nov 1996 05:24:57 -0800 (PST)
Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA14649;
          Sat, 30 Nov 1996 05:24:55 -0800 (PST)
Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.8.3/8.7.3) with SMTP id IAA23225; Sat, 30 Nov 1996 08:24:46 -0500 (EST)
Message-Id: <199611301324.IAA23225@whizzo.transsys.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp>
cc: sos@freebsd.org, nate@mt.sri.com, current@freebsd.org
From: "Louis A. Mamakos" <louie@TransSys.COM>
Subject: Re: FreeBSD-3.0-current PS/2 mouse driver change 
References: <199611270804.JAA00372@ravenock.cybercity.dk> 
 <199611271331.IAA01084@whizzo.transsys.com> <199611272318.IAA09541@zodiac.mech.utsunomiya-u.ac.jp> <199611280420.XAA08667@whizzo.transsys.com> <199611290823.RAA23794@zodiac.mech.utsunomiya-u.ac.jp>
In-reply-to: Your message of "Fri, 29 Nov 1996 17:23:09 +0900."
             <199611290823.RAA23794@zodiac.mech.utsunomiya-u.ac.jp> 
Mime-Version: 1.0
Content-Type: text/plain
Date: Sat, 30 Nov 1996 08:24:46 -0500
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> 
> I intended to put a code, for debugging purpose, to log the
> synchronization problem when it is detected by checking that bit, so
> that we can know the mouse interrupt may or may not be lost under
> certain conditions. 

Sounds good to me.

> As I have written, I will turn off the bit checking by default in the
> next set of patches to the `psm' driver.  But, I may leave the bit
> checking and out-of-sync logging code in the driver as a
> configuration/debugging option. Will this be reasonable?

This sounds like a good idea, though it only fixes half of the problem
for me with the Alps Glidepoint.  

The problem is that the new driver seems to parse the serial data from
the mouse using a little state machine in psmintr(), and when a
complete sequence is recevied, queues a mouse event with a virtualized
state of the mouse buttons as translated from the butmap[] array.

Then, later, in psmread(), a mouse event is dequeued and then it's
de-virtualized back to a PS/2 mouse format by mkps2() before being
returned to the user via the uiomove().

Since there is no virtual representation for the "tap" gesture of the
glidepoint, it gets lost in the virtualization/de-virtualization step.
On the Glidepoint pointing device, the tap gesture is indicated by
having the normally always "1" bit in the first byte of the mouse
message be set to 0.  This is the same bit (MOUSE_PS2_SYNC) which is
used as the synchronization marker.

The kludge that I came up with was this code:

            if ((sc->ipacket[0] & MOUSE_PS2_SYNC) == 0) {
                sc->button |= BUT1STAT;
                ms->button |= BUT1STAT;
            }

near the end of psmintr() to set assert button 1 depressed when the
tap gesture is indicated.  This is essentially the change that I made
to /usr/sbin/moused (and before that, in the X server).

This would seem to encode too much "policy" into the kernel driver.
The new XFree86 release claim support of the glidepoint and causes the
"tap" gesture to be noted as logical 4th button.  It's then an
excercise for the student to figure out how to do something useful
with it :-)

It feels like the changes in psm.c are to support some future
architecture where there is a generic mouse interface to applications,
with the kernel drivers handling the decoding of the mouse data
stream.  Personally, I think that's putting too much code in a kernel
device driver, given that the moused based solution works really well
and is easier to change with less dangerous consequences.

Anyway, that's my two cents.

louie