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