On Mon, Apr 01, 2002 at 07:48:57PM +0400, Valeriy E. Ushakov wrote:
> On Mon, Apr 01, 2002 at 17:19:33 +0200, Juergen Hannken-Illjes wrote:
> 
> > First, I was talking about the way keystrokes get mapped to keysyms
> > that get sent to the tty.
> 
> My point is that you send bytes to the tty, not keysyms.  To
> reiterate: what are the prospective clients of this kbd codeset API
> other than the kernel itself?

Unicode support in the future?

> > Here we need a way to distinguish the key-to-char-mapping depending
> > on your favorite locale.
> 
> A program "behind" the tty, i.e. not accessing ws events only see
> bytes anyway.  Why we need to do a layer of keycode->keysym->locale->byte
> transaltion where keycode->byte would be sufficient in most cases?
> 
> I can think of scenario where you run applications in different
> locales for the same language that differ only in the used codeset
> (e.g. ru_RU.KOI8-R vs. ru_RU.ISO8859-5) on different wsscreens sharing
> a single wskbd layout.  Do we really want to support such scenario?

Why not?

> > This mapping could even be UTF-8 giving full 16-bit unicode over
> > 8-bit ttys.
> 
> UTF-8 terminal needs to be "fully" UTF-8, i.e. you apply UTF-8 to the
> whole stream of data between app and the terminal.  E.g. CSI should be
> UTF-8 encoded too.  At least that seems to be the consenus and afaict
> that's the way UTF-8 support works in xterm.

What do you mean `CSI should be UTF-8 encoded too.'?


> > With Lennart Augustssons changes it is impossible to modify the
> > current keyboard map, so this needs to be changed anyway.
> 
> Did his changes brake anything?

The keysym to name translation in wsconsctl is now ambigous.

	$ wsconsctl map
	...
	keycode 26 = udiaeresis Cyrillic_e
	...

This should read `keycode 26 = udiaeresis Udiaeresis'.

> 
> 
> SY, Uwe
> -- 
> uwe@ptc.spbu.ru                         |       Zu Grunde kommen
> http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen

-- 
Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)