From: Quinn <quinn@cs.uwa.edu.au>
Subject: Re: How does KeyCaps know which keyboard was used?  [also: Dvorak]
X-Xxdate: Thu, 17 Dec 92 01: 10:29 GMT
Organization: The University of Western Australia
X-Useragent: Nuntius v1.1.1d13
Date: Thu, 17 Dec 1992 01:47:31 GMT

In article <tuc.724405827@cs.wisc.edu> Brian A. Cole,
tuc@calico.cs.wisc.edu writes:
>Try this:  Attach two different models of ADB keyboard to an ADB mac (or
>attach an external ADB keyboard to a PowerBook, like I did) and go into
>KeyCaps.  Press a key.  Now press a key on the _other_ keyboard.
>Presto-Zamboni, the key layout displayed changes to that of the new
>keyboard.  Pretty neat, huh?
>
>Now, I'm not complaining.  In fact, I think that this is just how I'd
>like it to work.  My question is _how_ does it work?  How did it know
>that I'd attached an "Apple Keyboard II" and not an "Apple Extended
>Keyboard II" (or, for that matter, some relatively unknown third-party
>gizmo)?

Simple.  Check out Inside Macintosh V-367....

"The ADB address of the keyboard on which the last-typed character
was entered is now stored in the global variable KbdLast.  The type
of the keyboard on which the last-typed character was entered is stored
in the global variable KbdType.  The value of the KbdType is the Device
Handler ID value in register 3 of the device; values below $20 are
reserved by Apple."

The device handler ID mentioned is discussed in IM V-365.  It's basically
a number ranging from $00..$FF with numbers below $20 reserved.

"Warning:  You must register new device handler ID values with Apple, so
they do not conflict with the values of other devices that may be
connected
to the ADB at the same time."

But if you're just building a keyboard or mouse you can use the handler
ID of Apple's keyboard or mouse.  ADB supports multiple devices on the
same bus with the same handler ID (it gives them different "addresses"
at startup time).

>I'd always thought that all a keyboard did was broadcast an ASCII (or
>otherwise) code whenever a key is hit, but it seems to me that it must
>also be sending some self-identification of some sort.  Or I guess that
>the few applications that care (like KeyCaps) could ask the keyboard to
>identify itself after every keystroke or something.

The situation is quite complicated.  ADB devices do not broadcast
anything.
The bus master (the Mac) polls each device regularly asking if it has
any data by sending it a Talk command.  The Talk command has a field
that specifies which register the bus master wants returned (registers
are numbered 0..3).  Register 0 traditionally contains the keyboard data
(the key codes pressed) while register 3 must contain (among other things)
the device handler ID.

>Either way, it seems like the System must have some list of possible
>keyboards somewhere.  If this is the case, how the heck do third-party
>manufacturers make Mac keyboards -- do they require a system extension
>or something before the keyboard can be recognized?  Will someone in
>the know _please_ fill me in?

Third party keyboard manufacturers traditionally use the same device
handler ID as Apple hardware and send compatible keycodes down the line.
That saves them from having to write an ADB device driver, which although
not hard, keeps them out of the software business.

Anyone building a radical keyboard (like a chord keyboard perhaps) would
most probably have to write an ADB driver.

>Why do I care so much?  Because I'm looking for true-Dvorak-hardware
>keyboard that I can use _in_parallel_ with a normal (qwerty) one.
>[note:  a Dvorak keyboard layout thingie doesn't help me here.  I want
>to be able to type on one keyboard in Dvorak and the other in qwerty
>simultaneously (or in quick succession) without having to use a Control
>Panel or macro.]

You might be able to do this using a KMAP resource.  This resource
is used by Apple's keyboard to handle physical to virtual key code
translation.  Perhaps I should explain...

ADB keyboards generate physical keycodes.  These are mapped using a KMAP
resource (the one where the ID field matches the device handler ID (I
think)) to virtual keycodes.  Virtual keycodes are then translated into
ASCII using the current KMAP resource.

Normally to install Dvorak on a Mac you want it on all keyboards so you
install a new KCHR.  However in your case you might be able to bash
a KMAP to do the job.  You'll need to make sure that the two keyboards
you attach have different device handler IDs.  IM V-193 raises the
possibility of being able to change the device handler ID of an
attached keyboard which would be useful for you.

Apple ship different keyboards with different device handler IDs
because some of their keyboards generate strange keycodes (for an
example see the discussion of the Apple Extended Keyboard in IM V-191).

Consult IM VI.14-23 for a more lucid discussion of keyboards.  That
points to the MPW file "SysTypes.r" which describes the format of
a KMAP.  [The same file ships with both Think C and Pascal.]

btw, Why do you want different layouts on different keyboards?
Using Dvorak is *much* easier if you have it on all your keyboards.
It also forces you to touce type real quick!  But I assume you have
a good reason.

Gads, I hope you've got a set of IM and you're handy with ResEdit (-:

Good luck.

Share and Enjoy.

Quinn "The Eskimo!"      <quinn@cs.uwa.edu.au>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia
  -- Well you said you were desperate!