The "ws_read_indev error length %d" error

[Guy Harris]

>Recently some one added the following to his .login and caused a week and
>a half of mystery and frustration (you need X11R[34]:
>
>alias   xinit xinit; kbd_mode -a
>
>Okay it resets the keyboard on the console.

Yes, it does, but that's a side-effect of what it's intended to do...

>This means every key typed causes an error message to appear in the
>console of the form "ws_read_indev error length %d".

...which is to take the keyboard out of "encoded events" mode and put it
into "ASCII" mode.  The SunView kernel code expects the keyboard to be in
either encoded or unencoded events mode; i.e., it expects all the stuff
coming up from the keyboard to be in "Firm_event" format, i.e. an event
structure with time stamps and other stuff in it.  In ASCII mode, it sends
up ASCII characters, which are smaller than Firm_events and therefore
confuse the living hell out of the SunView kernel code.

>A suntools/X11 hacker may know a way to return the keyboard back to
>a sensible state (I would appreciate hearing about it if you do know). 

	kbd_mode -e

To quote from the KBD_MODE(1) manual page:

 SYNOPSIS
      kbd_mode [ -a -e -n -u ]

 DESCRIPTION
      Kbd_mode resets the  Sun  console  keyboard  to  a  rational
      state.

 OPTIONS
      The following options are supported, see kb(4S) for details:

      -a      Causes ASCII to be reported.

      -e      Causes Firm_events to be reported.

      -n      Causes up/down key codes to be reported.

      -u      Causes undecoded keyboard values to be reported.

Actually, the manual page is a *bit* misleading, since it implies (to me,
at least) that the "-whatever" options are actually optional.  In fact, it
does "require" that one be there, in that it prints a usage message if you
leave one out.  However, part of the usage message is a report on the
current state of the keyboard, so "kbd_mode" by itself tells you which
mode the keyboard is in.