Date: Sun, 1 Dec 1996 11:05:56 -0800 (PST) From: Soren Schmidt <sos> To: CVS-committers, cvs-all, cvs-sys Subject: cvs commit: src/sys/i386/isa kbdio.c kbdio.h syscons.c psm.c src/sys/i386/include mouse.h Message-ID: <199612011905.LAA26206@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
sos 96/12/01 11:05:54
Modified: sys/i386/include mouse.h
sys/i386/isa kbdio.c kbdio.h syscons.c psm.c
Log:
Alot of fixes from kazu:
1. All the suggestions earlier made by Bruce: renaming some symbols,
stricter error checking, removing redundant code, etc.
2. The `psm' driver preserves the default counter resolution and
report rate, whatever they are after reset. (Based on reports and
suggestion from Nate and Rob Bolin).
3. The `psm' driver now does not check the so-called sync. bit in the
first byte of the data packet by default, so that the tapping feature
of ALPUS GlidePoint works (based on reports from Louis Mamakos). I
tested the code with ALPUS Desktop GlidePoint (M/N GP101) and found
no problem; tapping worked. It appears ALPUS produces several models
of GlidePoint. I hope the other models are OK too.
The check code can still be activated by defining the PSM_CHECKSYNC
option in the config file. (The bit checking slightly reduces, if not
completely eliminates, weird mouse behavior cased by unsynchronized
mouse data packets. It also helps us to detect if the mouse interrupt
can ever be lost. But, well, if there are devices which cannot be
supported this way...)
4. The `psm' driver does not include the protocol emulation code by
default. The code can still be compiled in if the PSM_EMULATION option
is specified in the config file. Louis Mamakos suggests the emulation
code is putting too much in the kernel, and `moused' works well.
I will think about this later and decide if the entire emulation
code should be removed.
5. And, of course, the fix in `scprobe()' from Bruce to cure the
UserConfig problem. My code in `kbdio.c' is slightly different from
his patch, but has the same effect. There still is a possibility that
`scprobe()' gets confused, if, for whatever reasons, the user holds
down a key for very long time during the boot process. But we cannot
cope with everything, can we?
Submitted by: Kazutaka YOKOTA (yokota@zodiac.mech.utsunomiya-u.ac.jp)
Revision Changes Path
1.4 +48 -14 src/sys/i386/include/mouse.h
1.2 +151 -104 src/sys/i386/isa/kbdio.c
1.2 +13 -11 src/sys/i386/isa/kbdio.h
1.190 +53 -18 src/sys/i386/isa/syscons.c
1.32 +464 -174 src/sys/i386/isa/psm.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612011905.LAA26206>