Re: keyboard reset (was: Re: FreeBSD's aggressive keyboard probe/attach)

2001-09-03 Thread Toshihiko ARAI

+ Kazutaka YOKOTA wrote:

> We can improve our current behavior of syscons and keyboard drivers
> in the following approaches.

> a) Remove the FAIL_IF_NO_KBD flag from /boot/device.hints.
>Leave the AUTO_DETECT_KBD as it is now for syscons, so that
>syscons searches for a keyboard periodically while it isn't using
>one. Add a script to /etc/usbd.conf to switch to the USB keyboard.

I use the following scripts.  This /etc/usb_kbd was an improvement
version and became a topic with "-tech-jp ML" in Japan before a
little.  When you use it, please do "chmod +x".  And you can use
below four variables with rc.conf.

 keymap_
 keyrate_
 keybell_
 keychange_

 is device name of an USB keyboard.

For example, when you use a "jp.106x" keymap with ukbd0, you add
keymap_ukbd0="jp.106x" line to /etc/rc.conf.  And other variable are
similar, too.

However, a case to use several USB keyboards is a testing shortage.
And keyboard device will not accord with variable name of rc.conf by
order to connect an USB keyboard to.

> I always liked the idea b), but haven't designed it yet.

I like b) plan, too.

--
Toshihiko ARAI


-/etc/usbd.conf-
# This entry changes a console keyboard to an USB keyboard when connected it.
# And switch back to keyboard just before that when disconnected.
#
device "USB keyboard"
devname "ukbd[0-9]+"
attach  "/etc/usb_kbd ${DEVNAME} start"
detach  "/etc/usb_kbd ${DEVNAME} stop"

-/etc/usb_kbd-
#!/bin/sh -
#
# $FreeBSD$
#
# usb_kbd devname [start|stop]
#
# example: usb_kbd ukbd0 start
#

# Suck in the configuration variables
#
if [ -r /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
source_rc_confs
elif [ -r /etc/rc.conf ]; then
. /etc/rc.conf
fi

kbdhist=/var/run/usb_kbd.hist
kbddev=
ttydev=/dev/ttyv0
devname=$1
shift
startstop=$1
shift

case ${startstop} in
[Ss][Tt][Aa][Rr][Tt] | '')
# To change system console by insertion of USB keyboard.
#
# Acquire a keyboard device name from a message of
# "kbd1 at ukbd0" of dmesg command.
#
kbddev=`dmesg | sed -n -e "/at ${devname}\\$/h" \
   -e '${ g
  s///p
}'`
[ -z ${kbddev} ] && kbddev=kbd1 # XXX
kbdcontrol -k /dev/${kbddev} < ${ttydev} || exit

# Append pair of device name into history file.
echo "${kbddev} ${devname}" >> ${kbdhist}

# You can use following four variables.
# For example,
#   keymap_ukbd0="jp.106x"
# and rc.conf(5) may be helpful for you.
#
eval keymap=\$keymap_${devname}
eval keyrate=\$keyrate_${devname}
eval keybell=\$keybell_${devname}
eval keychange=\$keychange_${devname}

# Reference from src/etc/rc.syscons
# keymap
#
case ${keymap} in
[Nn][Oo] | '')
;;
*)
kbdcontrol < ${ttydev} -l ${keymap}
;;
esac

# keyrate
#
case ${keyrate} in
[Nn][Oo] | '')
;;
*)
kbdcontrol < ${ttydev} -r ${keyrate}
;;
esac

# keybell
#
case ${keybell} in
[Nn][Oo] | '')
;;
*)
kbdcontrol < ${ttydev} -b ${keybell}
;;
esac

# change function keys
#
case ${keychange} in
[Nn][Oo] | '')
;;
*)
set - ${keychange}
while [ $# -gt 0 ]; do
kbdcontrol <${ttydev} -f "$1" "$2"
shift; shift
done
;;
esac
;;
*)
# To switch back to keyboard before one by removal of
# USB keyboard.
#
if [ -s ${kbdhist} ]; then
#
# Delete a current keyboard from history file
# and get a last keyboard device name.
#
kbddev=`sed -e "/ ${devname}\\$/d" -e "w ${kbdhist}.tmp" \
${kbdhist} | sed -n '$s/ .*$//p'`
mv ${kbdhist}.tmp ${kbdhist}
fi
[ -z ${kbddev} ] && kbddev=kbd0
kbdcontrol -k /dev/${kbddev} < ${ttydev}
;;
esac

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



keyboard reset (was: Re: FreeBSD's aggressive keyboard probe/attach)

2001-08-16 Thread Kazutaka YOKOTA

I am entering a tricky part now :-)

--- Keyboard reset

Because there are so many complicated issues here, I will start with
describing something I know about what BIOS and FreeBSD keyboard
driver do. (Beware, this is a long message.)


1. What BIOS does

During AT BIOS POST, things happen as follows.

Step 1. It sends the reset command to the keyboard.
Step 2. It waits for the result code.  During this reset operation
the embedded controller inside the keyboard will flash LEDs(*1).
Step 3. If it doesn't receive the result code, it assumes
there is no keyboard. Depending on your BIOS (and BIOS setup),
you will get the error message "keyboard not present."
Step 4. If it has received the result code, but it signifies an error,
you will get an error message too.
Step 5. If it has received the result code, and there was no error,
the BIOS sends the send-ID command to the keyboard.
Step 6. If the keyboard is 101/102 enhanced keyboard (or newer), it will
respond with a 2 byte ID code(*2). The original AT 84 keyboard
(and some old notebook computers too) doesn't support this
command and will report error.
Step 7. If the BIOS recognizes this ID code(*2), it will set the bit 4
in the keyboard status byte in the BIOS data area (0x496).
Step 8. The BIOS then send the set-LED command. This is typically done
to turn the NumLock LED on.
Step 9. The BIOS optionally send set-repeat-rate command to set repeat
delay and rate which you have specified in the BIOS setup menu.
(The original IBM AT didn't have such menu, thus, didn't send
this command.)

Note *1: we can certainly see the LEDs flash. But, this is not caused
 by the set-LED command from the host computer. It is by
 the keyboard's internal routine. In addition, LED flash is 
 not detectable from outside, in an electrical way by 
 the host computer or KVM.  There is no signal line in 
 the keyboard cable associated with the LEDs!
 We should also remember there are some keyboard which doesn't
 have LEDs.
Note *2: a typical ID code is 0x41ab for the US 101 keyboard. But
 other keyboards may send a different code. If the ID code
 is not one of those the BIOS knows about, the bit 4 at 0x496
 won't be set.

If the machine is in warm-boot sequence, the entire above keyboard probe
may be skipped. 

It is also important to note that there is no BIOS service or status
byte (or bit) in BIOS data area which tells us the presence or absence
of the keyboard.  As already pointed out in this mailing list by many
people, we cannot rely on the bit 4 at the BIOS data area 0x496 for
this purpose; this bit is set only when the keyboard identifies it
self as one of enhanced type (12 function keys and separate cursor pad
keys) AND the BIOS recognizes its ID code.


2. What FreeBSD atkbd driver does

Step 1. the probe routine sends the echo command to the keyboard port.
If a keyboard is present behind the keyboard port, it will respond.
Step 2. If there was no response, the driver assumes that there is no
keyboard and note as such. The driver will fail to install
ONLY IF you set bit 0 (FAIL_IF_NO_KBD) in the flags for atkbd.
Step 3. If the keyboard is present, then the attach routine first try
to retrieve the ID code from the keyboard by issuing 
the send-ID command. (The returned ID code will be saved.)
Step 4. Then the reset command is sent(*1), in order to put the keyboard
in known state(*1). (If the keyboard returns error and the
FAIL_IF_NO_KBD bit is set in the device flags, the atkbd will 
fail to install.)
Step 5. The set-LED command is sent. It typically set the NumLock LED
which was turned off reset in the step 4.
Step 6. The set-repeat-rate command is sent.

Note *1: if you really don't want to reset the keyboard, you may set
 the NO_RESET flags to skip it.
Note *2: if you warm boot the machine after you used it under another
 OS, we need to reset the keyboard to put it in known state,
 in case the BIOS doesn't do so for us.  It is true that there is
 not much room for the other OSes to configure the keyboard 
 in arcane state/mode, but I have seen in some Linux mailing 
 list that someone suggested that they should use the scan
 code set 3. The atkbd driver uses the scan code set 2 
 (this is the default after reset), or the set 1 for old
 ThinkPad keyboards (you need to set the ALT_SCANCODESET in 
 the atkbd device flags for this).

Note: all these FAIL_IF_NO_KBD, NO_RESET, and ALT_ACANCODESET flags are
  documented in the man page for atkbd(4).


3. Difference between the BIOS POST and atkbd

Except that the atkbd driver uses the echo command first and that the
order of the send-ID and reset commands is different, both do
essentiall