Subject: Re: port-i386/13118: pc keyboard does not work when console is on the serial port
To: NetBSD GNATS submissions and followups <gnats-bugs@gnats.netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: netbsd-bugs
Date: 05/06/2003 16:45:50
This PR should not be closed as the problem still remains.

When a keyboard is not actually attached to the system at the time it
boots with a serial console there's no way to configure it after the
fact:

	com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
	com0: console
	[[...]]
	pckbc0 at isa0 port 0x60-0x64

Note there's no pckbd0 configured and attached, which means:

	# wsconscfg -k
	wsconscfg: WSMUX_ADD_DEVICE: Device not configured
	# wsconsctl -ak
	wsconsctl: /dev/wskbd0: Device not configured

If a keyboard is attached at boot the messages are:

	com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
	com0: console
	[[...]]
	pckbc0 at isa0 port 0x60-0x64
	pckbd0 at pckbc0 (kbd slot)
	pckbc0: using irq 1 for kbd slot
	wskbd0 at pckbd0 mux 1
	wskbd0: connecting to wsdisplay0

and then everything works as suggested.

Obviously though this situation is far from ideal.

If there's no other type of keyboard on the system (i.e. no wskbd
configured), then I think the driver should auto-attach pckbd0 at
pckbc0, and wskbd0 at pckbd0 so that when a keyboard is plugged in (or
the KVM switch is flipped over to select this system), then it'll all
just work automatically.

Note that anything which requires some command to be run after the
physical connection is made in order to configure the keyboard device is
broken by design.  The attachment _MUST_ be automatic.

I don't know yet if this can be done by wiring down the attachments in
the kernel config or not, but such an option is not ideal.  It really
should be just automatic, just as the use of a serial console in the
first place is "just automatic" once the right boot blocks are installed.


As for documenting how this should work, well one way would be to
properly mention all the necessary details in /etc/wscons.conf, as well
as maybe discussing the issue in wscons.conf(5).

Ideally though there should be a "wscons_flag" setting for rc.conf which
would force this for systems which are intended to have serial consoles,
i.e. without having to modify /etc/wscons.conf.  Indeed I'm still not
sure I see any benefit to having all the wsconscfg commands be table
driven through /etc/wscons.conf -- why not just a plain and simple
script containing all the commands?  Then it would be so much simpler to
write optional execution paths to handle special cases such as when
serial consoles are used, etc.

Here are some suggested changes for the first part:

Index: wscons.conf
===================================================================
RCS file: /cvs/master/m-NetBSD/main/src/etc/wscons.conf,v
retrieving revision 1.10
diff -c -r1.10 wscons.conf
*** wscons.conf 19 Dec 2001 09:36:36 -0000      1.10
--- wscons.conf 6 May 2003 20:25:33 -0000
***************
*** 21,32 ****
--- 21,41 ----
  screen        2       -       vt100
  screen        3       -       vt100
  screen        4       -       -
+ # Note: You must uncomment the 'font  pcvt' lines above to get a useful
+ #     font for any *bf screen types.
  #screen       4       80x25bf vt100
  # Note: You must uncomment the 'font  ibm' line above to get a useful
  #     font for any 50 line screens.
  #screen       5       80x50   vt100
+ screen        5       80x50   vt100
+ screen        6       80x50   vt100
+ # Uncomment the next line if X11 is not being used.
+ #screen       7       80x50   vt100
  
+ # Keyboard and mux are automatically configured if they are the console.
+ #  Uncomment the next two lines if a serial console is used.
  #keyboard     auto
+ #mux
  
  # Select a kernel builtin keyboard map by uncommenting the following line and
  # altering the country code to your requirements


(BTW, I think there should also be support for "/etc/rc.d/wscons stop",
and it should not depend on /etc/wscons.conf either.)

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>