Hi Colin,

Thanks for the response.  My comments and results are below.

> Stephen Brown wrote:
> > 
> > Hi,
> > 
> > I just tried a hardware direct ADB kernel for the first time
> > in months yesterday and wound up with a non-functional
> > keyboard.  Everything works fine under the MRG kernels.
> > The keyboard in question is an Adesso ergonomic keyboard
> > (I think they called it a "NuForm" model).  The relevant
> > excerpts from dmesg are as follows;
> > 
> > under MRG:
> > 
> > adb0 (mrg) \^H \^H \^H \^H: 3 targets
> > aed0 at adb0 addr 0: ADB Event device
> > kbd0 at adb0 addr 2: extended keyboard
> > ms0 at adb0 addr 3: Mouse Systems A3 mouse, 3-button, 300 dpi
> > kbd1 at adb0 addr 2: mapped device (128)
>
> hmmm...it actually has it's own keyboard device driver.  that handler id
> looks a little bogus, but apple might have up to 127 reserved, so maybe
> not.  i assume this thing comes with some kind of extension?

The keyboard did not come with any software.  The Mouse Systems mouse
came with a control panel, but nothing for the keyboard...

>  
> > under hwdirect:
> > 
> > adb0 (direct, II series): 2 targets
> > aed0 at adb0 addr 0: ADB Event device
> > adb0 addr 218: unknown type device, (handler 115) unsupported
> > ms0 at adb0 addr 3: Mouse Systems A3 mouse, 3-button, 300 dpi
> > 
> > Is there anything I can do to provide more information?  I do 
> > compile my own kernels and can try any patches provided...
>
> the above is horribly wrong.  it's saying it has a default adb address of
> 0xDA when there are only 16 slots (0x0-0xF) to begin with, and there are
> only 7 assigned device types (1-7).  even assuming that there is junk in
> the upper part of the register, that's still a default address of 0xA,
> which isn't a meaningful device type.  oh, masking off all but the lower 3
> bits does give a device type of 0x2, which is a mapped device (keyboard),
> so maybe we need to change our checks to do this.  the patch i've included
> below _should_ fix this, i think...let me know if it doesn't.  don't worry
> about the revision number mismatches as this patch is off of the wscons
> branch, but the relevant section of the file should still be the same.  of
> course, the keyboard will still only be a "mapped device" for now.  of
> course, the fact that the hwdirect driver gives a handler id of 115 and
> the mrg driver one of 128 is a little strange, too...

I applied the patch below(I wound up masking "adbaddr" as well as 
"origaddr", but I'm not sure if that is necessary).  I am able to 
boot and get the keyboard recognized now, but not consistently.  I'm
not entirely sure why my results are inconsistent yet, but I'll do 
some more experimentation tomorrow.  I did note that putting some 
debug printfs in there show that sometimes the return from GetIndADB()
is '-1'.  But, I'm not sure why.  The last boot I tried yesterday
(after a full power cycle) was successful and gave the following
dmesg entries:

adb0 (direct, II series): 3 targets
aed0 at adb0 addr 0: ADB Event device
kbd0 at adb0 addr 2: mapped device (128)
ms0 at adb0 addr 3: Mouse Systems A3 mouse, 3-button, 300 dpi
kbd1 at adb0 addr 2: extended keyboard

After that boot, everything seems to be working fine.
I'll let you know if I find out anything further tomorrow.

Steve

>
> later.
>
> colin
>
>
>
> Index: adb.c
> ===================================================================
> RCS file: /cvsroot/syssrc/sys/arch/mac68k/dev/adb.c,v
> retrieving revision 1.27.2.2
> diff -u -r1.27.2.2 adb.c
> --- adb.c	1999/11/09 01:44:07	1.27.2.2
> +++ adb.c	1999/11/17 22:08:47
> @@ -185,7 +185,7 @@
>  		/* Get the ADB information */
>  		adbaddr = GetIndADB(&adbdata, adbindex);
>  
> -		aa_args.origaddr = (int)(adbdata.origADBAddr);
> +		aa_args.origaddr = (int)((adbdata.origADBAddr) & 0x7);
>  		aa_args.adbaddr = adbaddr;
>  		aa_args.handler_id = (int)(adbdata.devType);
>  
>