Chris Dillon wrote:
> Occasionally I'll have mouse sync problems when I switch between
> FreeBSD and NT when the NT box has had difference mice (wheel vs.
> non-wheel MS mice, apparently) used on it via the dual-user KVM
> switch. NT seems to handle that case fairly well by resetting the
> PS/2 port and/or the mouse (not sure which) and redetecting the mouse
There is actually a Cybex-specific "Microsoft Knowledge Base"
article which discusses the registry setting you need to pound
on to make NT not attempt to detect the mouse wheel (FWIW).
> FreeBSD doesn't like when NT has done that to the mouse,
> though, and spews sync errors when I switch back. Usually I can kill
> moused and restart it to fix the problem.
The 0x8000 flag fixes exactly this problem!
> > and the local wiring (non-ethernet version) of the Belkin OmniView
> > switches work if the FreeBSD mouse/keyboard is selected at boot
> > time, so that the aggressive probe/attach can satisfy itself.
> That is the KVM switch's fault, not FreeBSD's. On all but the most
> expensive KVM switches which offer true "keyboard and mouse emulation"
> on all ports, even NT (or actually the BIOS, I assume) can fail to
> enable keyboard and mouse support in that case. The dual-user Belkin
> OmniView seems to handle this correctly. I can't recall any problem
> booting FreeBSD on it even when its console isn't active.
Yes, it has to to support the dual use case; we have one of
those in the lab, as well...
> > Belkin went out of its way to support FreeBSD specifically,
> > actually: their firmware version 1.9 fixes the local wiring
> > switches, so that they can pass FreeBSD's aggressive probe, even
> > if the FreeBSD mouse/keyboard is _not_ selected.
> Hmm... I'll have to check, maybe thats why mine works. :-)
Little square sticker with rounded corners on the bottom, about
1/2" by 1/4", with just the version, e.g. "1.9"...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message