Date: Wed, 15 Aug 2001 18:24:39 +0900 From: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp> To: freebsd-current@freebsd.org Cc: yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach) Message-ID: <200108150924.SAA06230@zodiac.mech.utsunomiya-u.ac.jp>
next in thread | raw e-mail | index | archive | help
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 CORRECT "out-of-sync". 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 screen... 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. Too complicated? Kazu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200108150924.SAA06230>