From owner-freebsd-current  Fri Nov 29 00:21:39 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id AAA07542
          for current-outgoing; Fri, 29 Nov 1996 00:21:39 -0800 (PST)
Received: from nasu.utsunomiya-u.ac.jp (nasu.utsunomiya-u.ac.jp [160.12.128.3])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id AAA07527;
          Fri, 29 Nov 1996 00:21:32 -0800 (PST)
Received: by nasu.utsunomiya-u.ac.jp (5.57/ULTRIX-940302)
	id AA09724; Fri, 29 Nov 96 17:20:24 +0900
Received: by outmail.utsunomiya-u.ac.jp (5.57/ULTRIX-940909)
	id AA13091; Fri, 29 Nov 96 17:20:22 +0900
Received: from zodiac.mech.utsunomiya-u.ac.jp (zenith.mech.utsunomiya-u.ac.jp [160.12.33.60]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP
	id RAA23794; Fri, 29 Nov 1996 17:23:10 +0900 (JST)
Message-Id: <199611290823.RAA23794@zodiac.mech.utsunomiya-u.ac.jp>
To: "Louis A. Mamakos" <louie@transsys.com>
Cc: sos@freebsd.org, nate@mt.sri.com, current@freebsd.org,
        yokota@zodiac.mech.utsunomiya-u.ac.jp
Subject: Re: FreeBSD-3.0-current PS/2 mouse driver change 
In-Reply-To: Your message of "Wed, 27 Nov 1996 23:20:38 EST."
             <199611280420.XAA08667@whizzo.transsys.com> 
References: <199611270804.JAA00372@ravenock.cybercity.dk> <199611271331.IAA01084@whizzo.transsys.com>
	 <199611272318.IAA09541@zodiac.mech.utsunomiya-u.ac.jp>  <199611280420.XAA08667@whizzo.transsys.com> 
Date: Fri, 29 Nov 1996 17:23:09 +0900
From: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp>
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


>> >Please note that
>> >right now, the new psm.c driver in the kernel renders this pointing device
>> >helpless to do it's nifty bits.  The additional "smarts" in the kernel 
>> >driver seems to mask off the bit which indicates a "tap" gesture on the
>> >pad.  I've just upgraded to 3.0-current last night, and have only begun
>> >to look at the driver.
>> 
>> Hello. I understand what is the problem with the `psm' driver when used
>> with ALPUS GlidePoint. I will turn off the bit checking by default.
>> 
>> BTW, that bit is said to be always 1, according to some docs. Now that
>> I know the bit is not set in that way, there will be no way to re-sync
>> with the data packet from the PS/2 mouse once we have become out of
>> sync (due to lost interrupt or something) ;-<
>
>I've really never experienced a situation where the mouse driver got 
>unsynchronized.. at least with the old version of the driver.  All of the
>parsing of the mouse data stream seemed to have taken place either in
>the X server or moused rather than in the kernel.  Is this a significant
>problem which other users have experienced?
>
>louie

I personally have not had my mouse `out-of-sync'. However, I wasn't so
sure if this possibility can be categorically discounted.  Because
there was the report that XAccel servers make `syscons' lose
interrupts, and locks up the keyboard.

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. 

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?

Kazu