Date: Fri, 29 Nov 1996 17:23:09 +0900 From: Kazutaka YOKOTA <yokota@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 Message-ID: <199611290823.RAA23794@zodiac.mech.utsunomiya-u.ac.jp> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
>> >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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611290823.RAA23794>