Ok, I am back.
There are so many issues to be explained and discussed. I will tackle
them one by one....
- Flags 0x8000 for psm and "out-of-sync" error
As many people want to make it default, and my initial intent to make
it an option didn't work out well as a hindsight, we had better make
it the standard, default feature.
However, I would point out that THERE ARE CASES WHERE IT DOESN'T
The "out-of-sync" problem occurs in three situations.
Case 1: there was communication error between the keyboard and the
motherboard and data bytes from the mouse were somehow dropped. (I
expect this is to be very rare these days.)
Case 2: when you switch between more than two host computers connected
to a KVM, there may be a loss of data bytes from the mouse to the
FreeBSD box, if you try to switch computers during a packet is being
sent from the mouse. This can be avoided if the KVM is intelligent
enough to know the boundary of mouse data packets, but I suspect many
KVMs on the market are not that smart; there are so many different
mouse data format and packet length that I seriously doubt that KVMs
know all of them and are able to ensure all data packets are sent to
the host computers without splitting a data packet.
Case 3: when you use a KVM, the mouse is initialized to one operating
mode by a host computer, and then another computer tries to set up
another operating mode of the mouse. Modern PS/2 mice have more than
one operating mode to support wheels, additional buttons, and other
extra features. These advanced modes most certainly use different
packet data format and packet length than the original IBM PS/2 mouse
(2 buttons, three-byte packet). If two computers try to put the mouse
in different modes, they may be expecting different packet length, and
will be confused when you switch between them. Even if the two
computers are expecting the same packet length, you may witness wiered
mouse pointer movement (instead of the "out of sync" message) because
of the data format difference. If the KVM understands all the mouse
operating modes from all venders and is able to set up the correct
operaring mode for each computer when switching between them,
we will have no problem. But, the KVMs we have today are not that
capable for the same reason as I stated in the case 2 above.
The flags 0x8000 can correct the first two situations and should get
the mouse and the FreeBSD box back in sync. In case 3 above, this flag
won't help; you will get a series of "out of sync" and "re-enable the
mouse" messages. (I initially didn't like the idea that there would be
a lot of traffic from the host computer to the mouse to disable/enable
the mouse and we would still never get out of the error if we fell
into this trap. That was another reason why I made the flag optional.)
To get out of this error, we need to reset the mouse and reinitialize
it the way we want.
The trouble is that it is impossible for the psm driver to distinguish
the above three situations. Reset and re-initialization is also
effective for the case 1 and 2, but considered overkill and it will
take a long time to do it.
Another note on the "out-of-sync" error: we cannot guarantee that we
can always detect it. Because there is no reliable way to find the
start of the mouse data packet, the psm driver may operate without
noticing the error and the mouse pointer goes berserk on your
Anyway, I am now considering the following experiment.
- We make the psm driver count the number of the "out-of-sync" errors.
- When the error is detected for the first time, the psm driver will
throw few data bytes (up to entire packet size) and see if it can
get back to sync.
- If the error still persists, the psm driver disable/enable the mouse
and see if it works.
- If the error still persists and the count goes up to N (10 or 20?),
the psm driver reset and reinitialize the mouse. The counter
is reset to zero.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message