I think I have the "wscons" part ironed out, but have identified another
problem which kind of explains why sometimes I get no keyboard
attached at all.

It seems that the "fake" pseudo-keyboard from the A3 mouse
specifies a device handler ID of "zero"(Looking at a talk register
3 from the MacOS side of things).  After having looked at the IM
Devices book, this seems contrary and bogus, but it is what I
seem to be stuck with.

In the adb_direct.c code the initial probe of ADB devices discards
anything with a device handler id of "zero".  It also skips up to
the next device address register.  So, if the pseudo-keyboard
is the first thing to respond to the probe of device address 2, then
NetBSD skips it, in effect configuring NO keyboards.  If the
real extended keyboard is speedier in responding to the talk register
3 probe of device address 2, then it is discovered and the conflict
resolution happens and everything progresses.

Hmm, I'm wondering if it is best to try several times and hope that
the "real" keyboard responds sooner, or just take a handler id of
"zero" as valid instead of chunking it out.  Would there be bad
repercussions of accepting a handler id of "zero" as valid(at least
for the conflict resolution section)?

Later...
Steve

Colin Wood wrote:

> Stephen Brown wrote:
> >
> > After further debugging, it seems the problems that I earlier attributed
> >
> > to my ergonomic keyboard are instead caused by my Mouse Systems
> > A3 mouse(mechanical).  During boot, it seems to create a fictional
> > keyboard entry:
> >
> > comes from line 405 of /usr/src/sys/dev/wscons/wskbd.c, which reads as
> > follows:
> >
> >     KASSERT(wskbd_console_device == NULL);
>
> chances are that our kernel doesn't have the proper specifiers for the
> console so we're trying multiple console keyboard attachments.  with the
> proper kernel config, you could probably avoid this little problem.  of
> course, ADB resets can leave the device id's in a somewhat non-deterministic
> state, so this can be a problem.
>
> > I do notice from looking at the "akbd.c" file(around line 173) that
> > several
> > other mice list fictional keyboards(Logitech Mouseman, et al), but they
> > return valid handler ids, instead of the "128" value I am getting in my
> > case.
>
> since i kinda doubt that any legitimate device is using 128 as a device
> ID, we can probably detect that and then not attempt to attach wskbd
> devices to it just like the older mouseman's fake keyboard device.
>
> > I'm guessing there might be something strange going on with the values
> > returned from the "GetIndADB()" call for this device.  If someone who
> > has
> > mucked around with the ADB code before has some clues as to what I
> > should try, please let me know.
>
> i'd go for my suggestion above.  i doubt that GetIndADB() is returning a
> bad value, but you might try compiling an MRGADB kernel and see if things
> get better...
>
> -colin