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...

I just tried the 4/8 MRG kernel and it hangs trying to probe the ADB.  
Whatever is going on here has to be in a module common to both the MRG 
and HWDIRECT kernels.  Earlier versions of NetBSD with the wscons code 
worked fine on my system, so it must be a fairly recent change.

-bob