From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Thu, 29 Jun 2006 07:55:31 -0400
From: Dan Cross <cross@math.psu.edu>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] usb keyboard and mouse?
Message-ID: <20060629115531.GB5893@augusta.math.psu.edu>
References: <200606290531.k5T5VQ1W000476@ducky.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200606290531.k5T5VQ1W000476@ducky.net>
User-Agent: Mutt/1.4.1i
Topicbox-Message-UUID: 703cedf4-ead1-11e9-9d60-3106f5b1d025

On Wed, Jun 28, 2006 at 10:31:26PM -0700, Mike Haertel wrote:
> The implementation is chipset dependent.  Often what happens is
> that the chipset recognizes an I/O request to port 0x60 or 0x64 and
> aborts the request with an SMI (system management interrupt).  This
> is a *very* non-maskable interrupt (more non-maskable than NMI...)
> that causes the processor to save pretty much all its register state
> in a special memory area, and jump to a handler in the system BIOS.
> The BIOS SMI handler examines the saved register state, figures out
> what the OS was trying to do, runs a software model of the PS/2
> keyboard controller's state, chats with the USB keyboard, formulates
> an appropriate response, emulates the I/O instruction the OS was
> trying to do, and resumes execution of the OS at the instruction
> following the I/O instruction.
> 
> Some chipsets might do it directly in hardware rather than using
> the SMI+BIOS strategy.

Dear Lord!  At what point is a chicken sacrificed in this process?

	- Dan C.