on 4/26/00 12:22 AM, Michael L. Hitch at mhitch@lightning.msu.montana.edu
wrote something like:

> The replacement of timeout/untimeout to callout was done incorrectly.
> The callout structure was added as a union member and overlays the
> keyboard state data.  This results in the keyboard code stomping on the
> callout data, and the callout processing stomping on the keyboard state
> data.
> 
> I have just committed a fix for this problem.

Great, thanks Michael!

    While that dtop.c code is still fresh in your head, I have another
question :)
    We (you) have access to the prom "device tree" of sorts correct? Since
the prom deals with a.b. devices directly, can we not grab the string we get
from t 3/ab/caps and do an sscanf for locator or keyboard (or tablet?) and
then map those addresses to locator and keyboard in dtop.c at least at boot
time?
    Also, does the PROM monitor work like a TSR where it stays resident? I
wonder if the above scenario would also work for hot-swapping devices. i.e.
on a device attach/disconnect the hardware automagically interogates the bus
correct? If the PROM monitor updates those addresses, you might be able to
support hot swapping devices.


    Just trying to make your life more difficult :)   J/K



    Chris


P.S. I've got the Phillips I2C bus specification (about 1200 pages in two
books) here, I'll have to see if I can figure any of this stuff out.

-- 

Murphy was an optimist.