Date: Sat, 26 Jul 1997 03:06:30 -0500 From: Tony Overfield <tony@dell.com> To: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp> Cc: freebsd-hackers@freebsd.org Subject: Re: psm and kbdio driver (was Re: Stuck! 2.2 Gamma won't go.) Message-ID: <3.0.2.32.19970726030630.00770428@bugs.us.dell.com> In-Reply-To: <199702150856.RAA23399@zodiac.mech.utsunomiya-u.ac.jp> References: <Your message of "Tue, 11 Feb 1997 00:15:23 CST." <3.0.1.32.19970211001523.006a17b8@bugs.us.dell.com> <3.0.1.32.19970210051554.006a2350@bugs.us.dell.com> <3.0.1.32.19970210022848.00691d20@bugs.us.dell.com> <3.0.1.32.19970210051554.006a2350@bugs.us.dell.com> <3.0.1.32.19970211001523.006a17b8@bugs.us.dell.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[Long ago, Tony once volunteered to answer some questions. I had lost this message and only recently rediscovered it while cleaning up the entrails of a hard disk crash I recently suffered.] At 05:56 PM 2/15/97 +0900, Kazutaka YOKOTA wrote: >Thank you. Let's move to the freebsd-hackers list, as we are not quite >discussing a bug anymore. Sorry about quoting so much of the prior message, but I thought the context would be helpful. >Here are first bunch of questions. > >Before I beg you answers to my questions, I had better tell you my >source of information first, so that you can know how I learned the >basics of the keyboard, the PS/2 mouse and the keyboard controller. > >[1] Van Gilluwe, F.: "The Undocumented PC", Addison Wesley, 1994. >[2] Hogan, T.: "The Programmer's PC Sourcebook, 2nd Ed.", Microsoft > Press, 1991. >[3] Brown, R.: "Interrupt List". >[4] Phoenix Technologies Ltd.: "System BIOS for IBM PC/XT/AT Computers > and Compatibles", Addison Wesley, 1987. >[5] Logitech Inc.: "Logitech Mouse Technical Reference and Programmer's > Guide", 1992. > >I also use various magazine articles, English or Japanese. I don't have most of these references, so let me know if something I say doesn't agree with them, since one or both of us might be wrong. >No, I don't have a copy of "Technical Reference - Personal Computer AT" >from IBM. I know I should have one. It's a good reference for some things, but it's poor for this topic, since it doesn't cover the PS/2 mouse (auxiliary device) support. >But, is it still available? Good question. I don't know. >1. Internal buffer size >I understand that the AT keyboard (84/101) has an internal 16 byte >buffer. Yes, it is 16 bytes, though it's probably possible for this to vary. If the buffer is full and more data bytes need to be placed in the buffer, an overrun code (0x00) will be placed in the buffer instead (in the 17th byte position, if necessary) and it will be sent to the system after all the bytes already in the buffer are sent. >Does the PS/2 mouse have an internal buffer too? If so, how >large is it? I doubt it has one. But the mouse is not allowed to send partial packets, so you can be sure that you won't lose anything important. The mouse will accumulate X/Y data and button events even if it can't send data. This data will come out in the next packet as soon as the mouse can send again, though it's possible that repetitive mouse clicks might be lost if the mouse interface is disabled while you're clicking on the buttons. The last (current) state of the buttons will always be sent, so this doesn't really cause any problems. >Also, does the keyboard controller buffer data from the >keyboard and the mouse (I guess this is unlikely though)? It normally buffers exactly one byte. Some systems may buffer more, but you shouldn't be able to tell that. It should act like there is only a one-byte buffer. That byte can be either from the keyboard, from the mouse, or from the keyboard controller itself. >2. Response to the command >For most keyboard commands, the keyboard responds with ACK (0xfa). >When exactly is it sent back? Suppose a data byte is waiting in the >keyboard internal buffer to be transmitted to the system, then a >command arrives. Will ACK be sent back before or after the data byte? The ACK will come out first, followed later by the data byte(s). >The keyboard often sends two or more bytes for a single key make/break >event. What if a command arrives after the first byte has been sent >but before the second byte. Will ACK be sent before the second byte? Yes, the ACK will be sent first, but there is a race condition such that it's possible for the second byte to arrive just as you place the command into the keyboard controller. It will look like you got a quick response from the keyboard, but it's just a data byte. You have to accept this data byte (or let the interrupt handler take it). The ACK will then be the next byte. However, this confusion should never happen, since the the normal way to issue commands to the keyboard is to first send a disable keyboard command (0xAD), and then send the command. The command/response will automatically reenable the interface and the ACK (or the response) will arrive first. Then the keyboard data will start arriving again. Some systems may require the (0xAE) command to start receiving data from the keyboard again. This method eliminates the possibility of confusing the command response data bytes with ordinary key press data bytes. >What should I do to the first byte already received? Should I discard >it (because the first byte will be sent again?), or save it so that I >can use it together with the second byte which will be later received? You must save it since it won't be sent again. You should discard the ACK bytes instead. The typical interrupt handler just swallows ACK bytes after setting a global status bit. The status bit can be checked by code that wishes to know if an ACK byte has come back. >The system can interrupt data transmission from the keyboard in the >midst of a byte, by bringing the CLOCK line down. In such case, will >the keyboard try to re-send the interrupted byte later? Yes, but only if you catch it in time. It will either appear in the output buffer (which means you didn't turn it off soon enough), or it will appear later, after you've enabled the interface again. You can't lose a byte, though. >As for the PS/2 mouse, the Logitech Mouse Technical Reference is >explicit about such circumstances; ACK will be sent immediately. If a >command from the system interrupt a data packet from the mouse in the >middle, the transmission of the data packet is aborted, and the system >should discard data already received. The mouse will send the complete >data packet again after the ACK. Yes, the ACK is always sent immediately. I don't know if the whole packet is discarded (it sounds wrong to me), but it is strange to send commands in the middle of a packet anyway, so I haven't seen this situation occur. >3. Reset >For the reset command (0xff), the keyboard responds with ACK and a >result code (0xaa). The mouse responds with ACK, a result code and an >device ID. I learned that the reset action takes a long, long time, >and the keyboard/mouse driver has to exercise a long delay before >attempting to read response from the device. The duration of necessary >delay varies from one system to another (though, I have the impression >the keyboard reset takes longer than the mouse reset...). So, we need >go give sufficient margin to the delay. Is there standard or >semi-standard or practical value for this duration? The ACK is sent quickly (about 20 ms) but the reset itself is specified to take between 300 ms and 500 ms for the 101 key keyboard, and up to 900 ms for the 84 key keyboard. I'd extend the wait up to about two or three seconds just to be sure. There's probably no need to wait for this; a simple state machine will work. In fact, there's normally no need to send a reset command at all. >And when exactly should I wait? I have found many keyboard and mice >return ACK immediately and takes their own sweet time to reset itself, That's because the device responds to the reset command with an ACK before it starts the reset operation. The ACK means it accepted the command, not that it finished it. >so I do "send RESET - receive ACK - wait (up to a few hundred msec) - >receive a result code". But, I recently learned that I need to wait >before ACK for the built-in mouse device in some laptops. Well, it *should* return the ACK quickly. You should probably just poll for (or wait for interrupts from) the data bytes as they come in, and time out in a couple seconds if you don't get them all. This way, it doesn't matter where the delay is in relation to the individual return bytes. >I would be grateful if you could shed some light on these questions. > >Kazu Let me know if you want more detailed information. Tony
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.2.32.19970726030630.00770428>