On Mon, Apr 01, 2002 at 18:02:36 +0200, Juergen Hannken-Illjes wrote:

> > 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?

Unicode support needs more of an overhaul that wscons can
realistically take.  There is Jun-Yong's uwscons project that tries to
address it (including font handling etc).  For wscons can we please
stick to a simple terminal model?  Lack of an easily localizable
console is hurting NetBSD acceptance in non latin-1 world *now* and
pies in the skies ain't gonna help it.


> > > 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?

Because it might be useful perhaps to just few persons on earth and
those are already using Linux or FreeBSD b/c currently NetBSD doesn't
easily support even a single one locales they need in console.

This sort of problems are better discussed and addresses within
uwscons framework.


> > > 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.'?

CSI in its 8-bit form is 0x9B.  For UTF-8 terminal that should be
passed around in it's UT8-8 encoded form as 0xC2 0x9B

IIRC, Section 2.8 of Unicode standard (3.0 book) discusses this.


> > > 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'.

Lennart's adding few names just exposed the inherent problem in wscons
design, I think.  IMO, keysyms were introduced w/out a clear design of
how they are going to be used.  It's by sheer numerology that it works
for latin-1.

I don't think we either want or need the whole XKB in the kernel just
to get *simple* terminal emulation working.  99.(9)% of users don't
need much besides that from their console.

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