Re: UTF-8 keyboard mode

[kaih@khms.westfalen.de (Kai Henningsen)]

Andries.Brouwer@cwi.nl  wrote on 17.09.99 in <UTC199909171600.SAA16666.aeb@papegaai.cwi.nl>:

> > it seems there was some sort of undocumented "half cooked" mode
> > in the Linux keyboard driver
>
> Hmm. I think I wrote quite a lot of docs in the good old days.
>
> But yes, the keyboard driver has raw mode, where you get the
> keyboard scancodes (many X servers use this, and then have problems
> with unusual keyboards), then there is mediumraw mode, where you
> get the keycodes (some X servers use that), and then there are Latin
> and UTF8 modes, where the keycodes are found in the keymap and the
> bytes bound to it are returned.
>
> For a trivial example of the use of mediumraw, see showkey.c
> in the kbd package.

I think what's missing is something similar to MacOS keyboard events.

Here's an extract from the relevant header file (Event.h):

+++ begin various snippets +++

 	Copyright:	+ 1985-1998 by Apple Computer, Inc., all rights reserved

	keyDown						= 3,
	keyUp						= 4,
	autoKey						= 5,

	keyDownMask					= 1 << keyDown,					/* key pressed*/
	keyUpMask					= 1 << keyUp,					/* key released*/
	autoKeyMask					= 1 << autoKey,					/* key repeatedly held down*/

enum {
	charCodeMask				= 0x000000FF,
	keyCodeMask					= 0x0000FF00,
	adbAddrMask					= 0x00FF0000,
	osEvtMessageMask			= (long)0xFF000000
};

typedef UInt16 							EventModifiers;

enum {
																/* modifiers */
	activeFlagBit				= 0,							/* activate? (activateEvt and mouseDown)*/
	btnStateBit					= 7,							/* state of button?*/
	cmdKeyBit					= 8,							/* command key down?*/
	shiftKeyBit					= 9,							/* shift key down?*/
	alphaLockBit				= 10,							/* alpha lock down?*/
	optionKeyBit				= 11,							/* option key down?*/
	controlKeyBit				= 12,							/* control key down?*/
	rightShiftKeyBit			= 13,							/* right shift key down?*/
	rightOptionKeyBit			= 14,							/* right Option key down?*/
	rightControlKeyBit			= 15							/* right Control key down?*/
};


enum {
	activeFlag					= 1 << activeFlagBit,
	btnState					= 1 << btnStateBit,
	cmdKey						= 1 << cmdKeyBit,
	shiftKey					= 1 << shiftKeyBit,
	alphaLock					= 1 << alphaLockBit,
	optionKey					= 1 << optionKeyBit,
	controlKey					= 1 << controlKeyBit,
	rightShiftKey				= 1 << rightShiftKeyBit,
	rightOptionKey				= 1 << rightOptionKeyBit,
	rightControlKey				= 1 << rightControlKeyBit
};


enum {
	kNullCharCode				= 0,
	kHomeCharCode				= 1,
	kEnterCharCode				= 3,
	kEndCharCode				= 4,
	kHelpCharCode				= 5,
	kBellCharCode				= 7,
	kBackspaceCharCode			= 8,
	kTabCharCode				= 9,
	kLineFeedCharCode			= 10,
	kVerticalTabCharCode		= 11,
	kPageUpCharCode				= 11,
	kFormFeedCharCode			= 12,
	kPageDownCharCode			= 12,
	kReturnCharCode				= 13,
	kFunctionKeyCharCode		= 16,
	kEscapeCharCode				= 27,
	kClearCharCode				= 27,
	kLeftArrowCharCode			= 28,
	kRightArrowCharCode			= 29,
	kUpArrowCharCode			= 30,
	kDownArrowCharCode			= 31,
	kDeleteCharCode				= 127,
	kNonBreakingSpaceCharCode	= 202
};


struct EventRecord {
	EventKind 						what;
	UInt32 							message;
	UInt32 							when;
	Point 							where;
	EventModifiers 					modifiers;
};
typedef struct EventRecord				EventRecord;

+++ end various snippets +++

Now, this is designed for 8 bit characters, so it's not 1:1 adaptable.  
However, it should illustrate the important points:

In each event, you have:

* the character

* the keycode (I *think* this is approximately what our half-cooked mode
  gives, that is, *not* the raw scancodes)

* the list of modifier keys used

* if it's a keypress, a key release, or autorepeat (I guess the latter  
might be a problem to detect for us)

(Also a timestamp and a mouse position and mouse button state, which I  
think are less critical for us.)

Obviously, this doesn't fit into a single char; you want some sort of  
packet format for this.

Important advantages:

1. It's easy to detect modifier keys. (The only way to do that right now  
that I know is via ioctl(), or by interpreting raw key codes.)

2. It is easy to use fully cooked keys for data, and keycodes for special  
keys. (Today, you'd have to look at keycodes or scancodes and emulate the  
rest of the keyboard driver in user mode to do that.)

Now, if we could also switch that on and off via escape sequences, we  
could export it over telnet.

Here's one suggestion for a packet format for this:

* a leadin sequence, $98 or $1B $58 (SOS, Start Of String)
* An encoding of the modifier keys
* An encoding of the (non-modifier) keycodes used to create this event  
(usually one, but may be more with combining keys)
* A sequence of UTF-8 characters generated in this event
* a delimiter, $9C or $1B $5C (ST, String Terminator)

Restriction: SOS and ST may not occur inside the packet.

This way, we can still have the console answer to device inquiry escape  
codes.

Oh, and we need some way of determining what's what in that packet.



Or if we decide we can't avoid using SOS and ST, then we ditch the idea of  
using ECMA-48 compatible sequences. I'm not sure it makes all that large a  
difference.

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