>Number:         10086
>Category:       port-mac68k
>Synopsis:       Mouse Systems A3 mouse causes wscons failure
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-mac68k-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue May 09 16:06:00 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     Charlie Root
>Release:        NetBSD-current as of 04/26/2000
>Organization:
Yoyodyne
>Environment:
System: NetBSD alchemy.miskatonic.edu 1.4X NetBSD 1.4X (marchhare) #0: Wed Apr 26 19:00:52 PDT 2000     root@alchemy.miskatonic.edu:/usr/src/sys/arch/mac68k/compile/marchhare mac68k

Note that my configuration differs from the GENERIC only in the color
settings for "wscons".  So, this is effectively a GENERIC kernel.

>Description:
	The Mouse Systems A3 mouse(mechanical, not optical) attached
	to my Quadra 610 system seems to cause a duplicate, fictitious
	keyboard to be seen during boot:

adb0 (direct, II series): 3 targets
aed0 at adb0 addr 0: ADB Event device
akbd0 at adb0 addr 2: mapped device (128)
wskbd0 at akbd0
ams0 at adb0 addr 3: Mouse Systems A3 mouse, 3-button, 300 dpi
wsmouse0 at ams0
akbd1 at adb0 addr 2: extended keyboard
wskbd1 at akbd1

	If I boot with a regular one-button mouse, everything works.
	Because of the secondary keyboard, the boot sequence panics
	on line 405 of /usr/src/sys/dev/wscons/wskbd.c, which reads
	as follows:

    KASSERT(wskbd_console_device == NULL);

	It loooks to me like it is trying to attach the second real
	keyboard, but already had the first, fictional keyboard 
	configured as the console keyboard.  

	I tried this both with and without the accompanying mouse
	extension.  The mouse extension usually sets the middle and
	right keys to "Option-left arrow" and "Option-right arrow".
	This is how the documentation on the web page says to set
	those buttons and this has been working until just recently.

>How-To-Repeat:
	Boot NetBSD-current with an A3 mouse systems mechanical mouse
	attached as well as a regular keyboard.
>Fix:
	One workaround for now is to use the serial console, because
	then the console does not detect multiple keyboards, etc.
	But, I do not consider this a long term solution as I lose the
	text of the boot sequence or have to dedicate a system to 
	hook up to the serial port.
	
	If it came up with some handler id other than "128", I'd say
	just program "akbd.c" to ignore it the same way the pseudo-
	keyboards for the Mouseman and Trackman are ignored.  It 
	seems that it should not come up with this handler id, though.
	I'm wondering if maybe the "GetIndADB()" call is failing or
	returning bogus data.  I do compile my own kernel and can
	try patches to "akbd.c".  
>Release-Note:
>Audit-Trail:
>Unformatted: