Re: UTF-8 keyboard mode

[Frank da Cruz <fdc@watsun.cc.columbia.edu>]

> From: Frank da Cruz <fdc@watsun.cc.columbia.edu>
> 
> : So then if I put the keyboard in (say) keycode mode so I can see which keys
> : are pressed, I can't also get the Unicode values?  Shouldn't there be a way
> : to get both?  Otherwise an application that needs to see keycodes must also
> : duplicate all of the Unicode conversions that are in the keyboard driver,
> : and then of course the application becomes needlessly bulky and also is in
> : danger of getting out of sync with the keyboard driver.
> 
> A well-known desire. It is possible but impractical for applications
> to ask the kernel for the current keymap and do the mapping themselves.
> 
> Long ago I wrote a /dev/kbd but never did much with it,
> I forget what it did. But some device like this could produce
> a stream of packets, somewhat like /dev/mouse, having scancodes
> and keycodes and ASCII/UTF8 value.
> 
> Would you be happy with such a construction?
> 
I think so.  And I think Markus was alluding to something like this
in a previous message:

  I would prefer if the keymaps loaded into the keyboard driver would all
  have three columns: A key code, an 8-bit character, and a Unicode
  character. ...

But we still need (at least) need two "submodes" that say under what
conditions the driver returns from a read() or select():

 . Any key (including Shift, Alt, etc) is pressed or released (scancode mode).

 . Any key or key combination is entered (keycode mode).

Also I think an application needs to be able to find out the keyboard mode
(so it can save and restore it) and also needs to be able to find out if
it actually does have access to the PC's keyboard.  The latter is something
that has always been lacking (at least in any consistent way) from all
UNIXes, although I'm not sure how I would design it if it were up to me.

But many applications need to know if the user is:

 . On the machine's physical keyboard and screen (presumably error-free
   and I can look for keycodes).

 . Coming in via a "traditional" (not PPP) serial-port connection (and
   so does not have an error-free, reliable connection, and I can't look
   for keycodes).

 . Coming in via a network connection (error-free but maybe slow, etc,
   and I can't look for keycodes).

It doesn't help to look at the controlling terminal's name because names
are only names.

I am by no means an expert in Unix keyboard handling and recognize that
there are difficult issues here, for example in supporting different
keyboard models (German, Swiss, Russian, ...) not to mention totally
different kinds of keyboards (e.g. the DEC LK450 VT-style keyboard for PCs,
the native keyboards of non-PC platforms like Sparcstations, etc).

So at minimum there must be some rather careful research into other
operating systems that support multiple hardware platforms and large numbers
of keyboards to see what they have done about allocating keycodes to attain
greatest possible compatibility and reusability.

Before leaving the topic of keyboards, I must say that if I have learned one
thing in my many years of making communications software, it's that the
keyboard is even more important to the user than any of us think, no matter
how important we think it is.  Simple things like making arrow keys behave
as a "naive" use would expect have been neglected in Unix for decades, and
this has driven hordes of potential users away.  This is in part because of
the lack of APIs to let applications find out "do I have access to the
keyboard?" and if so "which key was pressed?".  If all this stuff "just
works" in Windows it must also "just work" in any other desktop environment
that wants to be taken seriously as an alternative to Windows.

Ironically, in many ways the ideal platform for terminal emulators was DOS.
Here, you really can go straight to the keyboard, the video adapter, the
communications hardware, and have total control -- no overhead, no bulky OS
getting in the way, no excuses! :-)

- Frank
-
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/lists/