From: nowhere@never.at   
      
   [mouse keyboard issues and lots of confusion]   
      
   I've seen many published code examples, but they all seem to be partly copied   
   from each other. So even some of them may work (more or less), none of them   
   are optimal nor reliable at all.   
      
   * polling PS/2 mouse and keyboard is the worst:   
   because of the shared port 060 and due to the devices sent different sized   
   packets byte by byte (3,4 or 8 from mice and variable 1..6 from keyboard),   
   it always needs to enable/disable one while polling the other.   
   So it's not even practical for code tests, just because you can't tell   
   where the data from port 060 belong to. It's easy to loose control on both.   
      
   * setup routines often show keyboard and mouse init in one piece:   
   this is really wrong. While setup or modify one it's required to disable the   
   other. This also mean that the keyboard and its handler has to be reset after   
   a mouse setup. The mouse may send an incomplete packet when reenabled, but   
   this can be covered by a sync check.   
      
   Setup commands usually make the device respond with one or more bytes.   
   Poll for every byte it is not the best method. IRQ-routines should be aware of   
   this special inputs and sould set global system flags accordingly.   
      
   *delays (often seen just machine dependent CX-loops):   
   they are required after/between some setup and LED control commands to be   
   2mSec or 5mSec.   
      
   * lots of redundant wait loops can be seen in published IRQ code.   
   if both IRQ_1 and IRQ_12 are enabled and handlers were proper installed then   
   this two routines can both start like mine:   
      
   IRQ_n:        ;1 or 12   
   push ...      ;only what's needed   
   IN AL,[0x60]   
   STI           ;reenable   
   ...   
   this way port 060 will always hold correct data for either mouse or keyboard   
   even if they occure in mixed order.   
      
   * missing mouse sync check   
   PS/2 mice may be configured in three (perhaps more non standard) modes:   
   1. old standard three button w/o wheel   
   2. three button wheel mouse   
   3. five button dual wheel mouse   
      
   All three share: The first byte of a packet is indicated by a set bit 3.   
   This bit may be set on other bytes as well, but if it's not set then it isn't   
   a first byte.   
   So there is a good chance to get a lost mouse in sync again.   
      
   I found only one document which seem to show some truth:   
   "The PS/2 Mouse Interface" Adam Chapweske (c 2001).   
      
   hope I added enough confusion yet :)   
      
   __   
   wolfgang   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)